Native XEH guide

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

Introduction

When you create your addon to use extended event handlers, you move the event handlers away from the CfgVehicles vehicle configuration into a separate set of class Extended_XXX_EventHandlers configuration statements which are then used by the XEH system to call your event handlers.

As an example, we'll create a very simple addon that is based on the normal blufor NATO rifleman. This addon, which we name using our example OFPEC tag "TAG", has the following config:

/*
 * TAG_MyAddon - the original addon with a simple init event handler.
 *
 */
class CfgPatches
{
	class TAG_MyAddon
	{
		units[] = {"TAG_B_Soldier_F"};
		weapons[]={};
		requiredAddons[] = {"A3_Characters_F"};
		requiredVersion = 1.0;
	};
};

class CfgVehicles
{
	class B_Soldier_base_F;
	class B_Soldier_F: B_Soldier_base_F
	{
		class Eventhandlers;
	};
	
	class TAG_B_Soldier_F: B_Soldier_F
	{
		displayName = "TAG soldier (happy)";
		
		class Eventhandlers: Eventhandlers
		{
			init = "(_this select 0) setVariable ['TAG_isHappy', true]";
		};
	};
};

As you can see from the configuration, this is a happy soldier. If you were to use this addon together with some other community addons that add new functionality by way of the CBA extended event handlers, you will notice that these new features might not work. Why is that?

What happens here is that TAG_B_Soldier_F will replace the init event handler that it inherits from the parent B_Soldier_F class with the author's own init event handler. Consequently, that will remove the XEH init event handler for the new unit, which will break compatibility with the third-party addon.

How do we solve this? Why, by making the addon use the extended event handlers system, of course. :-)

This is done by removing the event handlers definition in the CfgVehicles >> TAG_B_Soldier_F class and placing it in a Extended_<name of event>_Eventhandlers section instead, outside of CfgVehicles. Another change that is needed is to add a dependency on CBA via cba_xeh. For the init event handler in this case, the result is as follows:

/*
 * TAG_MyAddonX, XEH compatible variant
 *
 */
class CfgPatches
{
	class TAG_MyAddonX
	{
		units[] = {"TAG_B_Soldier_F"};
		weapons[]={};
		requiredAddons[] = {"A3_Characters_F", "cba_xeh"};  // Added: dependency on CBA's XEH
		requiredVersion = 1.0;
	};
};

class CfgVehicles
{
	class B_Soldier_base_F;
	class B_Soldier_F: B_Soldier_base_F
	{
		class Eventhandlers;
	};
	
	class TAG_B_Soldier_F: B_Soldier_F
	{
		displayName = "TAG soldier";
	};
};

// The init event handler is moved here
class Extended_Init_Eventhandlers
{
    class TAG_B_Soldier_F
    {
        TAG_MyAddon_init = "(_this select 0) setVariable ['TAG_isHappy', true]";
    };
};

With that config, the TAG_MyAddon addon is now compatible with other addons that use the extended event handler system. Note that this new variant of the addon will have an added dependency on @CBA_A3.

I want my addon/mod to be standalone. How do I make it work with XEH?

For some addons or mods, it might not be desirable to add a dependency to CBA due to the added complexity or for reasons of backwards compatibility with how the addon is used.

How then, can the author still offer XEH compatibility to his or her addon for those that wish to use the addon along with other mods that need XEH?

For this use case, the addon author can create an extra, optional addon which, when loaded, will change the original addon's units and vehicles to be XEH compatible. This is described in the following tutorial: [Creating an XEH adapter addon](XEH adapter guide).