Bug #5157

removeAllEventHandlers 'type' also removes scripted addon eventHandlers

Added by kju over 7 years ago. Updated almost 7 years ago.

Status:Feedback Start date:10/13/2009
Priority:Normal Due date:
Assignee:CoolBox-SBS- % Done:


Target version:thefuture Estimated time:2.00 hours


Please exchange all removeAllEventHandlers 'type' CoolBox.
It causes addons to malfunction that use scripted EH.

Instead you need to save the EH ID once added and remove
only that index later on.


1 339 player removeAllEventHandlers "HandleDamage"; 2 494 player removeAllEventHandlers "HandleDamage";


1 203 player removeAllEventHandlers "HandleDamage";


1 231 player addEventHandler ["Fired", { player removeAllEventHandlers "HandleDamage"; player removeAllEventHandlers "Fired"; } ];



Updated by kju over 7 years ago

This is also true for XEH added EH.
XEH are a community standard of using EH in addons.

In other words the most popular addons are affected.

Updated by BCA_Cat_Toaster over 7 years ago

Is that the reason why all players get an error message because of an allowed addon only i am using (Fire and Smoke for example)? Or has it nothing to do with it?

Updated by kju over 7 years ago

What error message?

It is likely though as the addon should be use EH too.

Updated by CoolBox-SBS- over 7 years ago

  • Status changed from New to Assigned
  • Estimated time set to 2.00

Updated by CoolBox-SBS- over 7 years ago

I've had a look at XEH and whilst clearly its popular, has been around for a while, it seems to have some shortcomings:

(1) as far as I can tell the mechanism only applies to addons and not to maps. Maybe I'm wrong
here, if so, a pointer to an example MAP (not addon) that uses XEH would be v useful
(2) It doesnt seem to support dynamic addition/removal of event handlers
(3) I'm worried about the performance impact of having permanently active event handlers (you'll notice
none of my event handlers persist beyond the spawn armour duration)
(3) Documentation is a rather limited, no idea of the effect of this stuff in MP in particular.
(4) Code is 30KB for this one feature, and opens up whole new realms of unstability and untested
(5) Licence conditions not really compatible with what I'm trying to do with the AAS mode

In short, I'm not personally interested in supporting compatibility with other addons. What works, works. What doesnt doesnt. But anyone who wants to fork a compatible version is welcome.


Updated by CoolBox-SBS- over 7 years ago

  • Status changed from Assigned to Feedback

Updated by kju over 7 years ago

You seem to misunderstand the issue.

Yo do not need to implement XEH.
Instead you need to make your mission compatible to
any addon that uses eventhandlers.

The problem is that you remove all eventhandlers.

Like said above the solution is to remember the index
and remove only your eventhandlers.

Updated by CoolBox-SBS- over 7 years ago

Kju, the problem is that event handler IDs are not UIDs, they are list index numbers in a list of event handlers. Which means that if someone else adds or removes an EH, my EH number could potentially change without me knowing. Therefore I cannot trust that the EH ID that I get when I create will remain the EHID that I try to remove. So unless there is only one party adding/removing event handlers, I risk removing someone elses, or (much worse), failing to remove an event handler which makes my player invulnerable.

Its a pretty disastrous failure mode to having invulnerable players running around because of addons they happen to use accidentally messing with my EHIDs, and I'm not willing to risk that my EHID remains unchanged by luck if its not guaranteed by the language semantics.

See http://community.bistudio.com/wiki/removeEventHandler

<i>"When any handler is removed, all handler indices higher than the deleted one should be decremented."</i>


Updated by Xeno over 7 years ago

CoolBox-SBS-, currently you are disabling every addon that uses Extendend Eventhandlers by using removeAllEventhandlers.

Using the ID is totally safe!

Just do it and use removeEventHandler [type, index], no need to discuss anything here, the A2 engine handles it fairly well. No addon is messing with your IDs, the engine takes care of it.

Updated by CoolBox-SBS- over 7 years ago

I appreciate your input Xeno, but your "just do it" argument does not address the comments in my most recent message.

Updated by CoolBox-SBS- over 7 years ago

ps. sorry kju, xeno, I'm being a jerk. I'm not pissed off with either of u, I'm just frustrated by the poor documentation and semantics of the Arma scripting language. And what I really cant face is another round of running experiments on the system as if it were a black box to figure out what the behaviour should be, and what is safe.

Updated by kju over 7 years ago

Fixed it here. Seems to work as desired both in the editor and on the DS.

Updated by kju about 7 years ago

  • Status changed from Feedback to Assigned

Updated by BCA_Cat_Toaster about 7 years ago

  • Status changed from Assigned to Resolved

Should be fixed in current r322. Thx kju

Updated by CoolBox-SBS- about 7 years ago

  • Status changed from Resolved to Feedback

the displayAddEventHandler was adding multiple copies of the KeyDown event handler. In 329 I reverted it to displaySetEventHandler, until this can be fixed properly.

Updated by BCA_Cat_Toaster about 7 years ago

Any final thoughts about this?

Updated by BCA_Cat_Toaster almost 7 years ago

  • Target version set to thefuture

Also available in: Atom PDF