This guide is outdated. Please refer to this guide instead!

Introduction

The extended event handler system was created by Solus for Arma 1 and 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 visual effecs and medical systems.

Supported event types

The full list of events in Arma 3 can be seen here

The following event types can have extended event handlers:

• AnimChanged
• AnimStateChanged
• AnimDone
• ContainerClosed
• ContainerOpened
• ControlsShifted
• Dammaged
• Engine
• EpeContact
• EpeContactEnd
• EpeContactStart
• Explosion
• Fired(*)
• FiredNear
• Fuel
• Gear
• GetIn
• GetOut
• HandleHeal
• Hit
• HitPart
• IncomingMissile
• InventoryClosed
• InventoryOpened
• Killed
• LandedTouchDown
• LandedStopped
• Local
• Respawn
• Put
• Take
• SoundPlayed
• WeaponAssembled
• WeaponDisassembled

(*) For historical reasons, the XEH fired event handler is special. One has to use a XEH FiredBIS event handler to process a normal fired event.

Unsupported events

• HandleDamage
• MPHit
• MPKilled
• MPRespawn

HOWTO guides:

• [Create a "native" XEH addon](Native XEH guide)
• [Create a XEH adapter addon](XEH adapter guide)
• [Enable "opportunistic" XEH compatibility](Opportunistic XEH guide)
• [Advanced XEH use](Advanced XEH) (Pre- and post-init event handlers, client/server event handlers)
• Per-mission and per-campaign event handlers

TODO: the text below based on older documentation from the early days of XEH.

Extending the fired event handlers.

The extended fired event handler has several different parts:

First the extended init EH is run for all units to add together and compile all of the inherited fired event handlers and use setVariable to attach those to the unit.

The extended fired event handler is added to a base class called Extended_Fired_EventHandlers. When a unit fires and sets off the event handler the shot is immediately captured in the same game state cycle. Then the compiled extended fired events are called by using getVariable to retrieve them from the unit.

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.

It allows more fired events to be used together, for example a script that makes shots affected by wind and a tracer script could be used together.

Examples

There are two example Extended Init addons included to demonstrate how to assign new event handlers and the event handler inheritance. The example pbos should not be installed except for testing.

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.

The addon "SightAdjustment_AutoInit.pbo" is an addon that makes gmJamez' "GMJ_SightAdjustment" addon compatible with XEH.

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.

New features

New in 1.3: Limiting certain event handler to a specific vehicle class

The example addon "SLX_Advanced_Init_Example" shows how to create an XEH init EH that will only be used on units that are of the class SoldierWB, ie the West "Rifleman". Units that inherit from "SoldierWB", eg the Grenadier, won't run the init EH.

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:

...
class Extended_GetIn_Eventhandlers
{
    class XYZ_BRDM2
    {
        class XYZ_BRDM2_GetIn
        {
            scope = 0;
            getin = "[] exec '\xyz_brdm2\getin.sqf'";
        };
    };
};


class Vehicles
{
    ...
    class XYZ_BRDM2: BRDM2
    {
        ...
    };
    class XYZ_BRDM2_ATGM: XYZ_BRDM2
    {
        ...
    };
};

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

...
class Extended_Fired_Eventhandlers
{
    class SoldierEB
    {
        class XYZ_SoldierEB_fired
        {
            scope=0;
            // We wish to make a SoldierEB-specific *Fired* EH, so the
            // property name should be "fired"
            //
            fired = "_this call XYZ_SoldierEB_fired";
        };
    };
};
...

New in 1.5: Excluding certain descendant vehicle types

With XEH 1.5, you can exclude one or more subtypes of a vehicle from getting a certain XEH event handler. To do this, you add a directive, exclude, in an inner, "composite" XEH class (introduced in 1.3).

Here's an example of how to exclude the west pilot class from running the basic Man class XEH init event handler. Instead, there's a special init for the pilot ("SoldierWPilot"). Note that all subclasses of "SoldierWPilot" will be excluded from using the basic class Man XEH init too.

/*
 *   Init XEH exclusion example 1
 */
class CfgPatches
{
   class xeh_exclusion_example1
   {
       units[]={};
       weapons[]={};
       requiredVersion=0.1;
       requiredAddons[]={"Extended_Eventhandlers"};
   };
};

class Extended_Init_Eventhandlers
{
    class Man
    {
        // To use the exclude directive, we'll have to make this an
        // "inner" (composite) XEH init EH class
        class XEH_Exclusion1_Man
        {
            exclude="SoldierWPilot";
            init = "[] execVM '\xeh_exclusion_example1\init_man.sqf'";
        };
    };

    class SoldierWPilot
    {
        xeh_init = "[] execVM '\xeh_exclusion_example1\init_west_pilot.sqf'";
    };
};

In the second example, we'll exclude both the standard west and east pilots and add unique init EH:S to them and the BIS Camel pilot. To do so, use the exclude[] directive in array form:

/*
 *   Init XEH exclusion example 2
 */
class CfgPatches
{
   class xeh_exclusion_example2
   {
       units[]={};
       weapons[]={};
       requiredVersion=0.1;
       requiredAddons[]={"Extended_Eventhandlers"};
   };
};

class Extended_Init_Eventhandlers
{
    class Man
    {
        // To use the exclude directive, we'll have to make this an
        // "inner" (composite) XEH init EH class
        class XEH_Exclusion2_Man
        {
            exclude[] = {"SoldierWPilot", "SoldierEPilot"};
            init = "[] execVM '\xeh_exclusion_example2\init_man.sqf'";
        };
    };

    // All descendants of SoldierEPilot will use this XEH init EH
    class SoldierEPilot
    {
        xeh_init = "[] execVM '\xeh_exclusion_example2\init_east_pilot.sqf'";
    };

    // Using scope=0, only SoldierWPilot will get this particular XEH init
    class SoldierWPilot
    {
        class XEH_OnlyWPilot
        {
            scope = 0;
            init = "[] execVM '\xeh_exclusion_example2\init_west_pilot.sqf'";
        };
    };

    // Here, we add an event handler for the BIS Camel Pilot (which is a
    // descendant of "SoldierWPilot". It won't run "init_west_pilot.sqf" though
    // since we used "scope=0" above.
    class BISCamelPilot
    {
        xeh_init="[] execVM'\xeh_exclusion_example2\init_west_camel_pilot.sqf'";
    };
};

You can do the same thing with the other XEH event types (fired, hit and so on).

New in 1.8: making XEH init event handlers run when a unit respawns

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).

Here's an example that shows how to do it:

#define false 0
#define true  1

class Extended_Init_Eventhandlers
{
    class Man
    {
        class SLX_XEH_RespawnInitMan
        {
            onRespawn = true;                    // Run this even after respawn
            init      = "_this call My_Respawn_InitEH";
        };
    };
};

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.

Note that unless you have "onRespawn=true" like above, XEH will use the default ArmA behaviour which is to NOT run the init EH when a unit respawns.

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)

New in 1.9: version stringtable and "pre-init EH" code

You can get a string with the version of Extended_Eventhandlers using the "localize" command. Here's an example function which will return the version as a decimal number or "0" if XEH isn't installed:

/*
    Return the version of Extended_Eventhandlers, or 0 if the addon
    isn't installed.
*/
_fXEHversion = {
    private ["_str", "_cfg", "_ver"];
    _cfg=(configFile/"CfgPatches"/"Extended_Eventhandlers"/"SLX_XE##Version");
    _ver=0;

    _str=localize "STR_SLX_XEH_VERSION";
    if !(_str == "") then {
        _ver=call compile _str;
    } else {
        // XEH version 1.8 and earlier lacks the stringtable version
        if (isNumber _cfg) then {
            _ver=getNumber _cfg;
        };
    };
    _ver
};

Another addition is a way to put code that you want to run only once in a new class, Extended_PreInit_EventHandlers. Anything in that class will be called early and before any of the normal extended init event handlers have run.

Here's an example: let's say there's an addon with the following XEH init:

// Addon: SLX_MyAddon (old)
class Extended_Init_EventHandlers
{
    class Man
    {
        SLX_Man_init="_this call compile preprocessFileLineNumbers '\SLX_MyAddon\init.sqf'";
    };
};

Using the "pre-init" system, that can be rewritten as:

// Addon: SLX_MyAddon (new)
class Extended_PreInit_EventHandlers
{
    // The name "SLX_MyAddon_init" needs to be unique
    SLX_MyAddon_init="SLX_fInit=compile preprocessFileLineNumbers '\SLX_MyAddon\init.sqf'";
};
class Extended_Init_EventHandlers
{
    class Man
    {
        // Call the function we loaded in the PreInit class
        SLX_Man_init="_this call SLX_fInit";
    };
};

Warning: if you write your addon using this new "pre-init" system, keep in mind that it won't work with XEH versions older than 1.9.

New in 1.91: PostInit and InitPost

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 PostInit handler mirrors the pre-init event handler introduced in 1.9 and will make a code snippet run once per mission. Example:

class Extended_PostInit_EventHandlers
{
    // Run "late_init.sqf" just before the mission's init.sqf and after
    // all other init EH:s and mission editor init lines have been processed
    SLX_MyAddon_postinit="[] execVM 'SLX_MyAddon\late_init.sqf";
};

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:

class Extended_InitPost_EventHandlers
{
    class CAManBase
    {
        // Make sure everyone is happy when the mission starts
        SLX_MyAddon_init="_this setVariable ['slx_myaddon_ishappy', true]";
    };
};

New in 2.00: Support for ArmA II, serverInit and clientInit entries

XEH is now useable in ArmA II and adds support for a new ArmA II event - the "firedNear" event.

###. Running init EHs on just the client or just the server

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)

Example:

class Extended_PreInit_EventHandlers
{
    // This one will be run once on ALL machines
    SLX_MyAddon_PreInit="SLX_myFunc=compile preprocessFileLineNumbers '\myaddon\myfunc.sqf'"

    /*  In order to have client- or server-only pre-init snippets, stick them into a class within
     *  Extended_PreInit_EventHandlers. The class itself can be called anything, but try to
     *  think of a unique name. 
     */
    class SLX_MyAddon_PreInits
    {
        // Like the normal preinit above, this one runs on all machines
        init = "...code here...";

        // This code will be executed once and only on the server
        serverInit = "...server-only code goes here...";

        // This snippet runs once and only on client machines
        clientInit = "...client-only code here...";
    };
};

New in 2.04: mission and campaign XEH event handlers.

XEH is no longer limited to just addons - mission makers can create extended event handlers that appear in specific missions or a campaign by adding an extended event handler class in the mission or campaign 'description.ext' file. As an example, if you put the following code in a mission description.ext and place a USMC rifleman in the mission editor, the player will sideChat information on the fired event every time you fire the rifle:

class Extended_Fired_Eventhandlers
{
    class USMC_Soldier
    {
        kls_test_fired="(_this select 0)sideChat str(_this)";
    };
};

New in 3.02: OO-like event handler overridance in child classes.

Consider CfgVehicle classes A and B where B is a descendant of A:

class CfgVehicles
{
    ...
    class A
    {
        ...
    };

    class B: A
    {
        ...
    };
};

Now, imagine the following extended init event handler definitions exist for both A and B:

class Extended_Init_EventHandlers
{
    class A
    {
        ab_myinit = "A=true";
    };

    class B
    {
        ab_myinit = "B=true"; // Same name as in class A, so we'll replace that one
    };
};

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.

New in 3.03: Extended_FiredBIS_Eventhandlers and support for addons that do not support XEH

As of 3.03, a mechanism was added that allows non-XEH Compatible classes to work with eXtended EventHandlers regardless. There are two limitations;

• It stops working if some script executes removeAllEventHandlers _unit;
• It only works if ** a) At least one XEH compatible class is available in the mission ** or b) If the SLX_XEH_Logic module has been placed in the mission

Also, due to the new Fired Eventhandler parameters introduced in ArmA 2 patch 1.08, and OA patch 1.55, a new Fired Eventhandler XEH class was added. Named: Extended_FiredBIS_Eventhandlers. The fired Eventhandlers in this class are 100% native and equal to that of the official FiredEventhandler (in config, or by script command; addEventhandler).

The difference is: Extended_Fired_Eventhandlers has: [unit, weapon, muzzle, mode, ammo, projectile, magazine] Extended_FiredBIS_Eventhandlers has: [unit, weapon, muzzle, mode, ammo, magazine, projectile]

The addition of FiredBIS is required to keep XEH Fired eventhandler (backward)compatibility in tact; XEH used _this select 5 as projectile entry since ArmA 1.

New in 3.05: excluding a class from XEH

If you don't want a specific unit or vehicle to be part of the extended event handler system, add a property named @SLX_XEH_DISABLE@ to the vehicle class like this:

class CfgVehicles
{
    class ABC_MyVehicle
    {
        SLX_XEH_DISABLE = 1;  // Disable XEH for this vehicle
        ...
        ...
        ...
    };
};

New in 3.06: disabling XEH's debug message logging

Normally, when a mission starts, XEH will print debug log messages to the .RPT file. You can disable this by creating a new addon with the following config:

class CfgPatches
{
    class Disable_XEH_Logging
    {
        units[] = {};
        weapons[] = {};
        requiredVersion = 0.1;
        requiredAddons[] = {};
    };
};

Load that addon along with XEH and the debug log messages will disappear.

New in 3.10: configuring function caching and re-compilation

One can enable or disable the XEH function caching either globally in the addon's config or on a per-mission basis using global variables:

class CfgSettings
{
   class CBA
   {
      caching = 1; // 0 = disabled, 1 = enabled (enabled is the default)
   };
};

Using global variables:

• CBA_RECOMPILE: if defined, all caching is disabled
• CBA_FUNC_RECOMPILE : if defined, functions caching is disabled.
• CBA_COMPILE_RECOMPILE: If defined, compile preProcess caching is disabled.
• SLX_XEH_RECOMPILE: If defined, XEH caching is disabled.

Example:

// description.ext

// Disable XEH caching
class Extended_PreInit_EventHandler
{
    Disable_XEH_cache = "SLX_XEH_RECOMPILE=false";
};

XEH Change log

1.0.0.186 (July 31, 2012) Added: SLX_MACHINE index 14; game. Currently 1 for A2/OA, and 2 for TOH. Added: determineProductVersion function. Fixed: Extended_EventHandlers backwards compatibility version information. Fixed: Removed duplicate delayless FSM:s. Fixed: level, timeout and game missing from SLX_XEH_MACHINE log entry Improved: determineGame function made better by Xeno.

1.0.0.178 (April 14, 2012) New: cba_extended_eventhandlers becomes cba_xeh, new versioning system. Changed: When PostInit times out on a client machine, probably due to no player object available (e.g spawned as seagul), continue PostInit regardless. (21982) Changed: Replaced usage of large object arrays with object variables. (27476,#26367) Fixed: Spawned units do not get their eventhandlers properly ran. (28648)

3.33 (December 9, 2011) Added: Player Object info to PostInit log entry. (25925) Added: Cache mem usage logging for debugging purposes. Changed: Addon script path macros now contain leading . For missions, use script_macros_mission.hpp Fixed: EXPLODE_ macros shouldn't contain private due to flexible usage - like using it in scopes. added EXPLODE_#_PVT variants. (25665) Fixed: BIS_OO_grpLogic due to early spawning of the BIS Functions Manager. (26194) Prepared: v1.60 changes. No need to delay for respawn check, nor for setVariable on man-based units in MP. Changes are auto-enabled if v1.60 is detected (somewhat reliable).

3.32 (October 19, 2011) Added: todo's for removing delays. (25590) Changed: Split TRACE formatting to PFORMAT (Pretty Format) macros. Changed: PostInit finished rpt entry prettyfied. Changed: don't log VehicleCrewInit unless XEH was built in debug mode. Fixed: May not use _forEachIndex due to A2 Original compatibility. (25282)

3.31 (October 4, 2011) Added: _CFG variants for Config stuff, e.g custom Eventhandlers (onLoad...) that might fire before XEH preInit. Fixed: missing macro "COMPILE_FILE_CFG". Fixed: TRACE_9 macro. Fixed: corrected docs for the EXPLODE_n macros. Changed: Removed duplicated SLX_XEH_COMPILE check code from all code that only gets executed after XEH preInit.

3.30 (September 27, 2011) Added: Prepared global code body call benchmark. Changed: Made SESSION_ID and COMPILE function more robust. Changed: Made cache aware of cache state. Changed: Added second cache layer. Changed: various cleanups. (24906) Changed: IS_ macros (IS_ARRAY etc) check for nil. (24906) Fixed: SLX_XEH_INIT_MEN error. (24904) Fixed: EXPLODE Macros (used by e.g PARAMS macros) cause recursive private assignment. (24907) Fixed: Support Monitor updated EH Fixed: EXPLODE_5 macro. Fixed: Player Eventhandlers added n+1 each respawn. (24931)

3.20 (September 13, 2011) Added: missing AnimStateChanged EH and animDone function. Added: cba_extended_eventhandlers cfgpatches. Changed: various caching system cleanups and fixes. Changed: always recompile init_pre. Changed: always recompile cache function. Fixed: FiredEH_Player, GetInManEH_Player, GetOutManEH_Player functions missing. Fixed: isRespawn difference. (23887) Improved: Stored Extended_###EH strings only once.

3.10 (Aug 28, 2011) Added: XEH cache for Init and InitPost event handlers. Added: Unique session ID since start of game. Changed: MultiLevel cache enable/disable methods:

1. Config: CfgSettings >> "CBA" >> "caching": functions, xeh and compile. 0 = disabled, 1 = enabled.
2. Global variables:

• CBA_RECOMPILE: If defined, all caching is disabled.
• CBA_FUNC_RECOMPILE: If defined, functions caching is disabled.
• CBA_COMPILE_RECOMPILE: If defined, compile preProc caching is disabled.
• SLX_XEH_RECOMPILE: If defined, xeh caching is disabled. Changed: Converted BIS handlers to COMPILE_FILE2 (and execVM -> spawn compile). Fixed: XEH Cache when switching between machine types. Fixed: error with cache disabled. Fixed: nil call silently ignored. Improved: Remove empty code bodies from XEH "Other" events. Improved: player handler handling simplified. Improved: general code rework (23850)

3.08 (Aug 21, 2011) Changed: compile scripts into uiNameSpace for caching purposes.

3.07 (July 8, 2011) Added: XEH support for the PMC DLC units. (16684) Changed: Improved XEH initialization for man-based units in both single- and multiplayer. Changed: Improved XEH delayed initialization for man-based units in MP. Changed: Improved XEH crew man init. Changed: Improved XEH initialization behaviour on servers and in singleplayer. Changed: XEH system inits should be first in line. Fixed: XEH initialized twice for crew units when JIPing. Fixed: Double initPlayable call. Fixed: PostInit not waiting for player object in single player, and player not being first unit on map. Fixed: getVariable array usage is not allowed due to casual ArmA 2 support. (17470) Fixed: PostInit didn't initialize when player is not a man, but animal. (19667)

3.06 (Dec 20, 2010) Added: A mechanism for disabling XEH's debug message logging: If a CfgPatches class with the name "Disable_XEH_Logging" exists, XEH_DisableLogging is set to true and logging stops. (15637) Changed: CBA LoadingScreen Disabled. New solution for credits soon. Changed: Improved XEH SupportMonitor implementation; speeds up script processing at initialization. Changed: Improved XEH InitOthers for all non man-based objects. Changed: Improved XEH PostInit/SupportMonitor initialization by detecting null-objects and aborting processing on them. Fixed: Event handler excludes bleed through to other classes. Fixed: Possible loop on non XEH supported units. Fixed: Eventhandler duplication on respawn of non-XEH compatible unit. Fixed: Unneeded SupportMonitor check on crew units. Fixed: SLX_XEH_DISABLED wasn't respected by SupportMonitor.

3.05 (Nov 26, 2010) Added: Support for excluding class from XEH via a @SLX_XEH_DISABLED@ property set for that class. 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. Fixed: XEH didn't exclude server/client eventhandlers if exclusion was specified. It only excluded the normal eventhandlers.

3.04 (Nov 23, 2010) Added: RPT Warning when XEH is initializing late, probably indicating there are no XEH-compatible units in the mission at start. Remedy; place SLX_XEH_Logic module. Changed: Do not add empty code strings, and warn if in debug mode. Changed: Respawn handlers. Changed: No loading screen for main menu intro. Fixed: XEH's broken on AAV and AH6X_EP1. (#15143) Fixed: JIP players were considered respawning and therefore didn't have the correct EH initializations. (#15328)

3.03 (Nov 09, 2010) Added: Support for the new BIS Fired Eventhandler parameters, which can be accessed from the new Extended_FiredBIS_Eventhandlers class. Fixed: OnRespawn handling.

3.02 (Jul 23, 2010) Fixed: High command missions would give the player control over all groups in the mission instead of just his assigned HC hiearchy. Fixed: event handler definitions now behave in an OO way in that you can override a specific handler from a (CfgVehicle wise) "parent" class. (Eg if CfgVehicles/B is a child of CfgVehicles/A and there exists XEH handlers for both A and B with the same name (code string entry or class entry name) the one in B will override (replace) the one in A. (#12108)

3.01 (Jul 07, 2010) Fixed: the old "game crashes when resuming a saved game" issue with class Static that was fixed way back in v1.7 had reappeared.

3.00 (Jul 05, 2010) New: Extended Eventhandlers is now compatible with, and targeted for a merged A2+Arrowhead installation, aka a "Combined Operations" installation. Compatibility with pure Arrowhead installations is achieved with the extra "CBA_OA" bridge addons.

2.07 (Jul 05, 2010) Last (barring any issues) ArmA II-only release of XEH (for CBA 0.4.2) Fixed: XEH now lists a minimal set of addons it requires, instead of what was probably a close to maximal set of dependencies.

2.06 (Mar 09, 2010) Changed: pre-init handlers are now called in a more controlled fashion. Fixed: The BIS flag pole inits were inherited causing redundant setFlagTexture calls. Fixed: several small fix and tweaks.

2.05 (Jan 22, 2010) Fixed: XEH init event handlers would run twice on respawn on dedicated 1.05 servers (#7432) Fixed: XEH init EH's set to run on respawn will now work on unnamed, playable units. (#8080)

2.04 (Nov 10, 2009) Added: per-mission and per-campaign extended event handlers can be added through the (mission or campaign) 'description.ext' file. (#2915)

2.03 (Aug 07, 2009) Fixed: Steam ArmA2: Addon 'Extended_EventHandlers' requires addon 'CA_Editor'. (#2987) Fixed: XEH disables pop-up targets. (#2935) Fixed: XEH init event handlers are re-run after respawn by default. (#3396) Added: The respawn monitor is able to make use of the @playableUnits@ command to track all playable units, not just the player. (#2647)

2.02 (Jul 13, 2009) Added: support for AnimStateChanged event handlers. (#2808)

2.01 (Jul 08, 2009) Fixed: performance drop issue. (#2663) Fixed: keep the stock BIS event handlers for the A10, Su34, camp fires, burning barrels, cruise missile, flag poles, popup targets, certain buildings, graves. (#2674) Fixed: restore the default EH:s for Team Razor units. (#2665)

2.00 (Jun 25, 2009) New: XEH ported to ArmA II with the help of Sickboy. Added: support for the new "firedNear" event Added: @serverInit@ and @clientInit@ can be used along with or instead of the normal @init@ snippet to limit initialisation to certain types of machines.

1.93 (Feb 16, 2009) Fixed: empty vehicles created after the mission started did not get their InitPost handlers called.

1.92 (Feb 09, 2009) Changed: Some optimizations made (eg use pre-compiled XEH init functions).

1.91 (Dec 20, 2008) (Unofficial, for use with the ACE mod) Added: New "post-init" feature that can be used to have a script run once at the end of mission initialisation, after all init EH:s and mission init lines have executed, but before the mission's init.{sqs,sqf} is processed. Added: There's also a per-unit, "InitPost" XEH framework which lets you run scripts at the end of mission init. Unlike the PostInit event handlers described above, these snippets run once for every unit in the mission. (The name of this framework may change in the future to avoid confusion with "PostInit")

1.9 (Sep 21, 2008) Fixed: before, vehicle crews would not have their XEH init EH:s run until just after the mission started. Now they are run before mission start. Added: A stringtable with the version of XEH in STR_SLX_XEH_VERSION and STR_SLX_XE##VERSION for use with the "localize" command. Added: a way to have run-once, "pre-init" code run using the new Extended_PreInit_EventHandlers class.

1.8 (Sep 7, 2008) Fixed: game logics inside vehicles would cause a performance drop due to a infinite recursion in the code that handles initialisation of vehicle crews. Thanks to UNN for the bug report! Added: you can make XEH init event handlers execute when players respawn by using an inner XEH class and the "onRespawn" boolean property.

1.7 (Mar 16, 2008) Fixed: Removed XEH from class Static, which stops ArmA from crashing to desktop when resuming saved games.

1.6 (Mar 15, 2008) Fixed: The "exclude" property will apply to the specified class(es) and all subclasses thereof.

1.5 (Mar 15, 2008) Added: Composite ("inner") XEH classes can have an extra property, "exclude" which is either a string or an array of strings with the class name(s) of vehicles that should not get a particular XEH event handler.

1.4 (Mar 15, 2008) Added: "Static" class vehicles can now have XEH event handlers. Added: A respawn monitor that restores non-init XEH event handlers after the player respawns. Many thanks to Sickboy, LoyalGuard, ViperMaul for the initial research and suggestions!

1.3 (Feb 9, 2008) Added: The ability to use "nested" XEH classes with a "scope" feature to limit certain event handlers to objects of specific classes.

1.2 (Jan 29, 2008) Fixed: SightAdjustment_AutoInit. Fixed: Extended Dammaged EventHandler.

1.1 (Jan 26, 2008) Fixed: XEH can now handle extended event handlers that are missing a trailing semicolon. Fixed: the example addons now require the Extended_Eventhandlers addon instead of the two older ones. Also, the debug sideChats are now guaranteed to be seen when previewing a mission with the example addons loaded. Fixed: XEH init EH:s are now actually being called on units inside vehicles.

1.0 Initial Release (Dec 31, 2007) Combined Extended Init, Fired, and Other event handlers. Thanks to Killswitch for combining them and adding the other extended event handlers! Added signature and bikey.

Init EH Change log:

1.26 Fixed signature files, bikey, and .pbos.

1.25 Fixed signature files and added bikey.

1.2 Added signature file. Fixed a bug that caused crashes on some missions. Thanks to LCD344! Changed ExecVM to Call Compile. Thanks to UNN!

1.1 Fixed people in vehicles having no inits. Included SightAdjustment example "bridge" addon that allows the GMJ_SightAdjustment addon to be used with other extended init event handler addons.

1.0 Initial Release

Fired EH Change log

1.0 @ 12-09-07 Initial release

References

XEH for ArmA II is part of the Community Base Addons project:

http://dev-heaven.net/projects/show/cca

The old XEH, for Armed Assault (ArmA) is hosted here:

http://dev-heaven.net/projects/show/xeh

BI forums: http://forums.bistudio.com/

gmJamez Sight adjustment addon thread: http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=60ba6482bbaa47a50e83f8ae5674bdd8;act=ST;f=70;t=65706