This addon allows a virtually infinite amount of event handlers to be used together from different addons. The event handlers are executed for the matching class and all inheriting classes. The event handler init line also contains the extended event handler class to look for, so you can have a custom inheritance for custom units.

Normally event handlers can only be added in configs, and trying to add a new event handler caused all previous event handlers to be overwritten. This addon allows that limitation to be overcome. This is mostly useful for having addons that can add different functionality, for example in OFP addons that had their own event handlers wouldn't inherit default event handlers, such as a custom unit with EHs being used with ECP or FFUR wouldn't have the ECP or FFUR effects.

The fired event handler init line contains the extended event handler class to look for, so you can have a custom inheritance for custom units. The event handlers are executed for the matching class and all inheriting classes.

There is an example addon included to demonstrate how to assign new fired event handlers and the event handler inheritance. The example also has a quickly called function that is able to capture information on the shot in the same game state cycle before the shot is updated and moves away from it's starting position and changes it's status. The example pbo should not be installed except for testing.

Note to addon makers: Before XEH 1.1, you had to make sure to add a ";" at the end of your extended init line to separate it from other extended inits. This is no longer necessary - the Extended Init EH will separate them automatically, so ending without one won't cause a problem.

One can do the same thing for the other XEH event types. For example, to add a "GetIn" event handler that works only on the the vehicle XYZ_BRDM2, but not on the XYZ_BRDM2_ATGM variant you would do something like this:

Note that within that innermost XEH class, you have to put a string value with the same name as the desired event handler. In the above example it was "getin". For the "fired" event handler, you would use

Normally, when a player respawns into a new unit (object), the init event handler is not executed again. However, with XEH 1.8, you can make an XEH init event handler be rerun when the new unit spawns. To do so, declare your init EH as a "composite EH class" (described above). Then, add a property to it called "onRespawn" and set it to true (the number 1).

The example above will cause all classes that are descendants of class "Man" to have the function "My_Respawn_InitEH" called both when the unit is created and after a player has respawned into a new unit.

IMPORTANT: This feature will only work on the player's unit - AI units that respawn won't have their XEH init EH:s re-executed. (If someone can figure out a trick to identify playable units in a MP mission, this limitation could be removed)

Two new event handler types can be used to execute things at a later stage, when all XEH init EH:s have run *and* all mission.sqm init lines have been processed by ArmA. It happens just before the mission's "init.sqf" is executed.

The other event handler, InitPost type mimics the mission editor init lines in that it will be run once on *every* unit and vehicle in the mission. You write the InitPost EH just like you would the normal XEH init, fired etc handlers. That means you have to wrap the handler in the desired vehicle/unit class for which you want the InitPost EH applied. As an example, you could use this to set a per-unit variable that's needed for your addon. It needs to be done for all units that are derived from the CAManBase class. Here's how it would look:

Furthermore, one can limit a certain init EH to just clients or just servers by placing it in a @serverInit@ or @clientInit@ entry within one of the Init EH classes (ie within @Extended_PreInit_EventHandlers@, @Extended_Init_EventHandlers@ or @Extended_PostInit_EventHandlers@)

Note how both handler entries are named "ab_myinit". In previous versions of Extended Eventhandlers, both code snippets would be executed for instances of class B in a mission - both the variables A and B would be set. (Internally, when XEH processed the Init event handlers for B, it would first execute _ab_myinit_ from class A and then the one from class B.)

In order to have XEH behave more consistent with the object-oriented way of thinking, the _ab_myinit_ definition in class B will override (replace) the one made in class A. Should the addon author want both of them to be executed for class B, he or she should name the second one something different from the one present in A.

Fixed: XEH Exclude classes were not reset each iteration, making exclude settings active for all classes following a class with exclude settings, and effectively therefore missing certain eventhandlers.