The template contains a powerful loadout system, commonly referred to as "XPTLoadouts". This system defines loadouts in the mission in a config file, and ensures that players always receive the correct gear for their role, especially in cases where there are multiple player units in the same role.

Usage

Enabling XPT Loadouts

To enable XPT Loadouts for your mission, you will need to uncomment the line in description.ext that contains the following text:

#define XPT_DEFINE_CUSTOMLOADOUTS 1

This will configure the loadout system to run automatically on mission start, and on player respawn.

Note: When the loadout system is enabled, ALL player roles (excluding Zeus and spectators) must have a loadout defined in config/XPTLoadouts.hpp. Errors will be displayed for player units without a configured loadout.

Exporting loadouts

The loadout system includes an automatic export function, to aid in exporting loadouts from the 3DEN editor to the config/XPTLoadouts.hpp config file. To use this export function, execute the following code in the debug console (from either the 3DEN editor, or while previewing the mission):

[] call XPT_fnc_exportInventory

NOTE: This will automatically copy the exported loadouts to your clipboard. DO NOT copy the output from the debug console into your file, you will end up with duplicated quote marks which will cause you a lot of problems.

This function has the following behaviour:

• When called from the 3DEN editor, the function will export loadouts for all playable units in the mission, and copy the results to your clipboard. To avoid errors however, this function will ignore any duplicate classnames in the playable units list.
  To work around this, and ensure that you are exporting loadouts from the correct units, this function will export loadouts for the currently selected units if you have units selected when running the command. This can be used to ensure that you are exporting loadouts for a specific set of units if you have already placed all of your player units.
• When called in a mission, the function will export the loadout only for the player unit.

LIMITATION: Due to how the loadouts would be set up, when called from the 3DEN editor this function cannot detect custom loadout classes set through the unit's init field. You will need to export these loadouts individually, and change the loadout classname afterwards.

If you want to export loadouts from specific units, you can use the following alternative syntax:

[unit1, unit2, ...] call XPT_fnc_exportInventory

This alternative syntax will export loadouts only from the units passed to the function.

Config Format

Invdividual loadouts are defined in the following format:

class example {
	displayName = "Example Loadout"; // Currently unused, basically just a human-readable name for the loadout
	
	// Weapon definitions all use the following format:
	// {Weapon Classname, Suppressor, Pointer (Laser/Flashlight), Optic, [Primary magazine, ammo count], [Secondary Magazine (GL), ammo count], Bipod}
	// Any empty definitions must be defined as an empty string, or an empty array. Otherwise the loadout will not apply correctly.
	
	primaryWeapon[] = {"arifle_MXC_F", "", "acc_flashlight", "optic_ACO", {"30Rnd_65x39_caseless_mag",30}, {}, ""}; // Primary weapon definition
	secondaryWeapon[] = {"launch_B_Titan_short_F", "", "", "", {"Titan_AP", 1}, {}, ""}; // Secondary weapon (Launcher) definition.
	handgunWeapon[] = {"hgun_ACPC2_F", "", "", "", {"9Rnd_45ACP_Mag", 9}, {}, ""}; // Handgun definition
	binocular = "Binocular";
	
	uniformClass = "U_B_CombatUniform_mcam_tshirt";
	headgearClass = "H_Watchcap_blk";
	facewearClass = "";
	vestClass = "V_Chestrig_khk";
	backpackClass = "B_AssaultPack_mcamo";
	
	// Linked items requires all six definitions to be present. Use empty strings if you do not want to add that item.
	linkedItems[] = {"ItemMap", "ItemGPS", "ItemRadio", "ItemCompass", "ItemWatch", ""}; // Linked items for the unit, must follow the order of: Map, GPS, Radio, Compass, Watch, NVGs.
	
	// When placed in an item array, magazines should also have their ammo count defined
	uniformItems[] = {{"FirstAidKit", 3}, {"30Rnd_65x39_caseless_mag", 4, 30}}; // Items to place in uniform. Includes weapon magazines
	vestItems[] = {{"FirstAidKit", 3}, {"30Rnd_65x39_caseless_mag", 4, 30}}; // Items to place in vest. Includes weapon magazines
	backpackItems[] = {{"FirstAidKit", 3}, {"30Rnd_65x39_caseless_mag", 4, 30}}; // Items to place in backpack. Includes weapon magazines
	
	basicMedUniform[] = {}; // Items to be placed in the uniform only when basic medical is being used
	basicMedVest[] = {}; // Items to be placed in the vest only when basic medical is being used
	basicMedBackpack[] = {}; // Items to be placed in the backpack only when basic medical is being used
	
	advMedUniform[] = {}; // Items to be placed in the uniform only when advanced medical is being used
	advMedVest[] = {}; // Items to be placed in the vest only when advanced medical is being used
	advMedBackpack[] = {}; // Items to be placed in the backpack only when advanced medical is being used
};

The class name at the top of the loadout definition is how the loadout system will identify this loadout. By default, this name should match the classname of the units that will be receiving this loadout upon respawn.

Partial Randomization

The loadout system supports "partial" randomization of loadouts for the following equipment slots:

• uniformClass
• headgearClass
• facewearClass
• vestClass
• backpackClass

To use partial randomization, any of the above equipment definitions can be replaced with an array like so:

uniformClass[] = {"uniform1", "uniform2"};

In this example, when the loadout is applied to a unit, one of the provided loadouts will be selected at random to be applied.
This partial randomization is independent of any other partial randomization elements in the loadout. Thus it is impossible to guarantee that a unit will receive a given vest with a given uniform, as an example. For this, you will need "Full Randomization", as detailed below.

Full Randomization

The loadout system also supports "full" randomization of loadouts. This form of randomization is compatible with all loadout elements, including weapons and inventory items.

The full randomization system is activated when the top-level loadout has "sub-loadouts" defined. Example below:

class example_random
{
	displayName = "Random Loadouts";
	class random_1
	{
		// Loadout info goes here
	};
	class random_2
	{
		// Loadout info goes here
	};
};

In this case, when the example_random loadout is loaded, the loadout system will automatically select either the random_1 loadout, or the random_2 loadout to load instead. Each of these sub-loadouts must be a full loadout definition, as they are treated entirely separately.

Note that full random sub-loadouts can still individually contain partial-randomization equipment entries.

Advanced Usage

Since the loadout system uses the Arma 3 config format, and the loadouts are effectively stored as plaintext, there are some more advanced techniques that can be used to define and use loadouts.

Config Inheritance

Config inheritance can be used to automatically have a loadout carry over certain elements from another loadout. Example:

class rifleman {
	// Loadout goes here
};

class squadleader: rifleman {
	backpackClass = "B_Radiobag_F";
};

In this example, the squadleader loadout will inherit all entries from the rifleman class (weapons, equipment, etc.). Once these values have been loaded, it will then overwrite the backpackClass entry with the new one. This ensures that the squadleader loadout will always be identical to the rifleman loadout, with the addition of a radio backpack.
This kind of config inheritance can be applied between multiple loadouts, and has no limits on how many variables can be inherited or overwritten.

Overwriting default loadouts

By default, XPT Loadouts will look for a loadout that matches the class name of the player unit when the player respawns. This auto-detection can be overridden by setting a variable on the unit.

this setVariable ["XPT_loadout", "myloadout"]

The above code, when placed in a unit's init field in the editor, will cause them to load the "myLoadout" loadout instead of the loadout that matches their classname.

Loadout Groups

XPT Loadouts supports switching all player loadouts to a different "set" of loadouts during the mission. This can be particularly useful, as an example, if your mission has players acquire better gear as an objective, and you want players to respawn with the improved equipment should they die after that point.

Using loadout groups involves the config/XPTLoadoutGroups.hpp file. This file is set up as follows:

// Group name goes here. Multiple groups can be defined to be used during the mission.
class exampleGroup
{
	// Loadouts here should match unit classnames
	class loadout1
	{
		*Loadout information goes here*
	};
	
	class loadout2
	{
		*Loadout information goes here*
	};
};

Multiple loadout groups can be defined within a mission, and multiple loadouts can be defined within a loadout group. When a loadout group is set during the mission, the loadout system will attempt to load loadouts from within the specified group. Should a matching loadout not be found within that group, the loadout system will fall back to using the standard config/XPTLoadouts.hpp definition.

To make use of the groups system during a mission, call the following function on the server (it will have no effect anywhere else):

["myLoadoutGroup"] call XPT_fnc_setLoadoutGroup;

Loadout groups can also make use of config inheritance. See the above section for the general concept of how that works.