Advanced XEH

The fired and firedBIS event handlers

Summary: to implent an extended "fired" event handler in XEH, you should use an extended FiredBIS event handler

Background

When the extended event handler system was created back in the days of the first Arma game, a fired event handler was passed the following five parameters by the game engine:

• unit: Object - Object the event handler is assigned to
• weapon: String - Fired weapon
• muzzle: String - Muzzle that was used
• mode: String - Current mode of the fired weapon
• ammo: String - Ammo used

The then-XEH fired event handler system added another item to the parameters passed - the actual projectile object that was just fired. That meant that an Arma XEH fired event was passed an array of the form

[unit, weapon, muzzle, mode, ammo, projectile]

Later, as XEH was ported to Arma II, this parameter form was kept for the XEH fired event. However, in A2, BIS added a magazine parameter that was sent to fired event handlers to include this:

[unit, weapon, muzzle, mode, ammo, magazine, projectile]

As you can see, that collides with the semantics of the XEH fired event handler. For this reason, a new XEH firedBIS event handler was introduced in CBA for Arma 2. An Extended_FiredBIS_Eventhandlers handler will be provided with exactly what the game engine in Arma 2 and Arma 3 gives it.

Pre- and post-init event handlers: meet the specials

In addition to the normal set of game events that XEH can handle, you can create event handlers that run only once per game session. These are the PreInit and PostInit event handlers.

• The PreInit event handlers will run once at a point in time before all the mission units and vehicles have their own init event handlers processed.
• The PostInit event handlers will run once and after all the units and vehicles have had both their init event handlers and the code in the mission editor "init" lines processed.

There is also a special XEH event handler type that runs once on each unit and vehicle after all the above is done. These event handlers are called InitPost event handlers.

• Extended_PreInit_Eventhandlers: runs once per gaming session at an early stage
• Extended_PostInit_Eventhandlers: runs once per gaming session at a later stage, after unit init event handlers and mission editor init lines
• Extended_InitPost_Eventhandlers: runs once per unit/vehicle after the PostInit stage.

Typical uses:

• PreInit - initialization of global variables, compilation of custom functions.
• PostInit - anything general that can or needs to wait for the game session to start.
• InitPost - anything unit-specific that can or needs to wait.

Running handlers on just the client or just the server

Furthermore, one can limit the XEH init event handlers to just clients or just servers by placing it in a serverInit or clientInit entry within one of the init 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...";
    };
};