WeaponPickup hook
Scripts types: Both
Called when weapon is picked up. The weapon itself and the player picking it up should be passed in.
The weapon id can be retrieved using CBasePlayerWeapon.m_iId, so it should not be passed in separately.
Yes please ! I want that to ! But please pleas PLEASE, introduce event cancellation options to ALL new events handles you design.(nullifying the effect)
HookReturnCode onItemPickup(CBasePlayer@ pPlayer, CBasePlayerItem item, bool& cancelEvent){ cancelEvent = true; // <<-- this prevents the player from picking up the object // maybe add: // item.IsAmmo(), item.IsWeapon() // pPlayer.HasWeaponFor( ammo ); // pPlayer.HasAmmoFor( weapon ); }
I'd rather return HOOK_CONTINUE to handle cancellation.
AFAIK, the return value only cancels the execution of other hooks. Or am i completely mistaken ? In my tests i was never able to influence the outcome of an event, only deny the execution of hooks behind me in the queue.
And if i am right with this, doesn't that mean, the outcome of the Event processing is pretty much non-deterministic ? (your hook may be suppressed from other hooks, depending on the execution order of the queue)
But as for the non-determinism problem: this problem may always exist, no matter which Event / Hook system is used. The only solution i can think about, would be a "Pre-Event" trigger combined with the actual Event-trigger. Like this:
1.) onPreEvent() { //option to set the cancelled status for the event }
2.) // the actual engine code for the event (spawning the player, picking up the item, etc)
3.) onEvent() { //only gets called, when the event was NOT cancelled in an optional onPreEvent() hook //can NOT be cancelled in this stage anymore //engine event-code has fully run: like the player being fully spawned / dead-animations played // (what's not the case atm) }
//EDIT: but yes, it doesn't matter at all, how the "event cancelling" mechanism is implemented. Either by return value, OR by "out" parameter OR with an Event object: eventData.setCancelled(true)