Advanced XEH - CBATeam/CBA_A3 GitHub Wiki

The fired and firedBIS event handlers

Summary: to implent an extended "fired" event handler in XEH, you should use an Extended_FiredBIS_Eventhandlers 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 to the fired event data:

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

As you can see, that is different from the data the XEH fired event handler receives. For this reason, a new XEH firedBIS event handler was introduced in CBA for Arma 2. A 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. (Event data passed to the handler: [unit] with the unit/vehicle/object, just like a normal init event)

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

One can limit the XEH event handlers to just clients or just servers by placing it in a server*** or client*** entry.

The init events

Here is how to do it for 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...";
    };
};

All the other events

For the other events, the principle is the same - place the server- or clientside-only event handlers for a certain vehicle or unit class inside an "inner class" within the class Extended_<Event name>_Eventhandlers declaration.

As an example, here's how you do it for the engine event handler of class Car:

class Extended_Engine_EventHandlers
{
    class Car
    {
        // This one will be execuded on all machines
        TAG_MyAddon_Car_engine="_this call TAG_MyAddon_Engine"

        /*  In order to have client- or server-only event handlers, put them in an "inner" class
         *  with a unique name
         */
        class TAG_MyAddon_CarEngine
        {
            // Like the normal engine handler above, this one runs on all machines
            engine = "...code here...";

            // serverEngine - runs only on the server
            serverEngine = "...server-only code goes here...";

            // This snippet runs only on client machines
            clientEngine = "...client-only code here...";
        };
    };
};
⚠️ **GitHub.com Fallback** ⚠️