Scripting Overview

Overview

Scripting ALiVE

This page is for mission makers who write their own SQF and want to drive ALiVE from it. It covers what you can call, when it's safe to call it, where it runs and what goes wrong.

The Script Snippets page has complete examples you can paste into a mission, and each one was run on a dedicated server before it went up. The Event Reference lists every event ALiVE raises and how to listen for it. This page explains the calls both of them use.

Script snippets →Event Reference →

In short

Four things to know

1. Every ALiVE module is an Eden logic, and you drive it with [handler, "operation", args] call ALiVE_fnc_<Module>. The first element is the module's handler hash for some modules and the module object itself for others.
2. Almost everything lives on the server, so write your scripts for initServer.sqf or guard them with isServer.
3. Wait for ALiVE_REQUIRE_INITIALISED before you touch any ALiVE global.
4. Read ALiVE data with ALiVE_fnc_hashGet; a missing key gives nil unless you pass a default.

The basics

How ALiVE is put together

ALiVE is a set of modules, and each one is an Eden logic (a Module_F object).

Handlers

Some modules keep their state in a handler, a CBA hash: the AI commander and the profile system do. Others, such as Military Logistics and Combat Support, keep it on the module object and take that object as their first argument. Either way you call the module's class function with it, an operation name and arguments, for example [_opcom, "addObjective", [...]] call ALiVE_fnc_OPCOM.

Commanders

Every running AI commander keeps its handler in the global array OPCOM_instances. ALiVE adds it when the commander is created and removes it when the commander stops. To find the one you want, match by side with [_x, "side", ""] or by faction with [_x, "factions", []].

OPCOM_instances lives on the server only and doesn't exist until the first commander is made, so in a mission that might have none read it with missionNamespace getVariable ["OPCOM_instances", []]. On a client, read ALiVE_OPCOM_factionsPublic instead: one [enemySides, factions] entry per commander, published each time a commander is added or removed.

Virtual AI and other globals

The virtual AI system is a single instance on the server. ALIVE_profileHandler holds every profile, and ALiVE_profileSystem holds the settings and the spatial grid.

You may meet a few other globals. Some of them only exist when a particular module is placed:

• ALIVE_eventLog
• ALIVE_sectorGrid
• ALIVE_battlefieldAnalysis
• ALIVE_clusterHandler, only with Civilian Population
• ALIVE_globalForcePool, only with Military Logistics
• NEO_radioLogic, only with Combat Support

Data

Hashes: how ALiVE stores things

ALiVE keeps its data in CBA hashes. A hash is an array ["#CBA_HASH#", keys, values, default]; you read it with [_hash, "key"] call ALiVE_fnc_hashGet and write it with [_hash, "key", _value] call ALiVE_fnc_hashSet.

Ask hashGet for a key that has never been set and you get nil back. Pass a third argument to get a default instead, like this (a default that's an array comes back as a copy):

[_hash, "key", 0] call ALiVE_fnc_hashGet

hashGet refuses bad input. If the hash is nil, isn't an array or is shorter than 3 entries, it logs 'retrieved wrong input' with the name of the caller and returns nil. hashSet has no such guard, so writing to a global that doesn't exist yet is a script error; wait for the module first.

Some values you get back are the live array, not a copy. The commander's objectives list, for one, is changed in place. Treat whatever hashGet hands you as ALiVE's own data.

Timing

When it's safe to script

The Required module sets ALiVE_REQUIRE_INITIALISED to true and publishes it once the placement, CQB, AI commander and Player Options modules you've placed have started. Other modules can still be starting then.

The start-up flag

Lead any script that touches ALiVE with waitUntil {!isNil "ALiVE_REQUIRE_INITIALISED"};. It works on the server and on clients.

Ready signals

Some parts of ALiVE have a ready signal of their own. Wait on the one you need:

• Virtual AI: ALIVE_profileSystemInit is set on the server only and isn't published, so only server scripts can wait on it. It goes nil again when the module is destroyed.
• Commanders: wait until !isNil "OPCOM_instances" && {count OPCOM_instances > 0} and [_x, "startupComplete", false] call ALiVE_fnc_hashGet is true. The array doesn't exist until the first commander is made, so count OPCOM_instances on its own is a script error before then. ALiVE uses the same check before it pauses a commander, and it ignores addTask until the commander's TACOM FSM is running.
• Force pool: ALIVE_globalForcePool exists once a Military Logistics module has initialised.
• Combat Support: wait until !isNil "NEO_radioLogic" and NEO_radioLogic getVariable ["init", false] is true. On the server NEO_radioLogic appears as soon as the module starts, before its assets are set up, so its name alone isn't enough.
• Your saved values: ALiVE_sys_data_mission_data exists once a Data module has initialised.
• Player persistence, on a client: the player has been restored when player getVariable ["alive_sys_player_playerloaded", false] is true. ALiVE's Stratis showcase mission waits on it with a 20 s timeout.
• Start-up progress: while ALiVE starts, it publishes ALIVE_INIT_PROGRESS (0 to 1) and ALIVE_INIT_WAITING (the class names of modules still starting) each tick.

Locality

Where things run

The server runs almost all of ALiVE, including everything in the list at the end of this section.

Calls passed to the server

Some functions forward themselves to the server when you call them on a client. ALiVE_fnc_OPCOMjoinNearestGroup, ALiVE_fnc_OPCOMJoinObjective and the force-strength helpers use remoteExec. ALiVE_fnc_pauseModule and ALiVE_fnc_unPauseModule go to the server over ALiVE_fnc_BUS.

Server-only state

Queries such as ALIVE_fnc_getNearProfiles read state that only the server has. In an Eden trigger, tick Server Only; otherwise the condition runs on every machine and throws script errors on clients instead of giving an answer.

ALiVE_fnc_setData and ALiVE_fnc_getData work anywhere the hash exists. The store lives in the server's copy and the server writes it out, so set values from the server.

Functions that sleep

Functions that sleep say so in their header. ALiVE_fnc_OPCOMjoinNearestGroup is marked 'Use with spawn!', and ALiVE_fnc_createProfileVehicleAssignment waits for the profile handler, so spawn it.

CfgRemoteExec

A mission that limits remote execution with CfgRemoteExec must allow the functions players' machines send to the server, or the matching tablet or menu action does nothing. Among them are ALIVE_fnc_combatSupportCmdrArtyRequest, ALiVE_fnc_ATOKernel, ALiVE_fnc_rallyPoint, ALiVE_fnc_aidCrate, ALiVE_fnc_fobRequest and ALIVE_fnc_civSetHostility. One goes the other way: the server sends ALiVE_fnc_OPCOMIntelMarkers to players' machines to draw an AI Commander's Intel Markers, so allow it for clients (allowedTargets = 1) with jip = 1, or players who join later won't see them.

What lives on the server

These parts of ALiVE live on the server. Script them from there:

• profiles, and spawning and despawning them
• commanders and objectives
• the event log
• logistics and the force pool
• Combat Support assets
• writing the mission-data store to disk

Virtual AI

Virtual units (profiles)

A profile is a hash that describes either a group (entity) or a vehicle (vehicle).

Finding profiles

Look a profile up by ID with [ALIVE_profileHandler, "getProfile", _id] call ALIVE_fnc_profileHandler. A spawned unit or vehicle carries its ID in its profileID variable.

The handler keeps per-side lists in profilesBySide, a hash keyed EAST, WEST, GUER and CIV. registerProfile adds both group and vehicle IDs to them, so a side's list includes its vehicles.

ALIVE_fnc_getNearProfiles takes [position, radius, selector]. The selector is [side, type, objectType, filterCode], and every part of it is optional. objectType matches the vehicle kind ALiVE recorded, for example "Helicopter".

Creating profiles

Create profiles from a CfgGroups class with [groupClass, position, direction, spawnGoodPosition, faction] call ALIVE_fnc_createProfilesFromGroupConfig. The fourth flag is true by default, which lets ALiVE pick a good spot nearby when the group spawns; pass false to pin it to the exact position. The faction is the fifth argument, even though the parameter is called _prefix.

[] call ALiVE_fnc_createProfilesFromUnitsRuntime turns live units into profiles after the mission has started. It skips players, anything already profiled, Combat Support assets and anything flagged ALIVE_profileIgnore or ALIVE_Convoy. It deletes the live objects and returns [groupProfiles, vehicleProfiles].

Waypoints and routes

To give a profile a waypoint, make one with [pos, radius, type] call ALIVE_fnc_createProfileWaypoint and add it with [_profile, "addWaypoint", _wp] call ALIVE_fnc_profileEntity; insertWaypoint puts it at the front instead, and on a spawned group it becomes the waypoint the group heads for. Pathfinding is on by default, and while it's on the waypoint waits in pendingWaypointPaths until a path is found. To re-task a group, call [_profile, "clearWaypoints"] call ALIVE_fnc_profileEntity first: it also cancels routes still waiting there, so an old route can't arrive after your new orders.

With the Virtual AI System's Route Memory on, ground routes steer round sectors where a side has taken losses. [nil, "deposit", [position, side, weight]] call ALiVE_fnc_pathfinderRouteMemory on the server adds that danger yourself: a weight of 1 is what a destroyed group adds, half as much goes on the 8 sectors round it, and it halves every 2 hours of simulation time (ALiVE_pathfinding_routeMemoryHalfLife, 7200 s, set in init.sqf to change it). It does nothing while Route Memory is off, and the danger isn't saved.

Keeping units out

To keep a group or vehicle out of the virtual system for good, use setVariable ["ALIVE_profileIgnore", true, true] on the group, and on any lone vehicle. Combat Support sets the same flag on its own assets.

To keep a group profile out of virtual combat for a while, run [_profile, "simProtectUntil", time + 900] call ALIVE_fnc_hashSet on the server. Until then it starts no simulated fight and no other profile picks it as a target; once players are near enough for it to spawn, it fights as usual. ALiVE does this for 15 minutes on the attack waves of several C2ISTAR tasks so they reach the players.

Where profiles spawn

Profiles spawn around players, connected UAVs, Zeus curators (if that's enabled) and any object you put in ALiVE_SpawnSources. The profile system resets that list to [] when it starts, and ALiVE adds and removes its own kill box logics in it after that. Add your object with pushBackUnique and take it out with ALiVE_SpawnSources - [_obj] when you delete it, since nothing prunes it for you; never overwrite the array.

Give a spawn source ALiVE_spawnSourceRadius (in metres) and profiles spawn around it at that distance instead of the normal one. With the Virtual AI System's Kill Box Markers on, a map marker whose text starts KILLBOX does the same: KILLBOX 2000 or KILLBOX 2km, up to 5000 m, and only while a player is within 10 km of it.

The player's own group is one profile marked active and isPlayer, so ALiVE never despawns it. Player persistence saves only the player unit, not the AI in the group.

Who destroyed a vehicle

ALiVE_profileKilledBy is a server HashMap of who destroyed each vehicle profile: the key is the profile ID and the value [byPlayer, killerSide, killerVehicleName, time], with the side "" when nobody is known. Read it with getOrDefault, not hashGet, and read it soon after the loss: once it holds 200 entries, those older than 15 minutes are dropped.

Profile fields

Each field sits at a fixed position inside the profile's values array. Positions 2 to 6 are the same for every profile; 13, 16 and 30 are for group (entity) profiles only, as a vehicle profile keeps fuel, damage and isSPE there. Read them like this:

• _profile select 2 select 2 is the position
• _profile select 2 select 3 is the side
• _profile select 2 select 4 is the profileID
• _profile select 2 select 5 is the type (entity or vehicle)
• _profile select 2 select 6 is the objectType
• _profile select 2 select 13 is the group
• _profile select 2 select 16 is the waypoints
• _profile select 2 select 30 is isPlayer

AI commanders

Commanders and objectives

Objectives

Add an objective with [_opcomOrSide, "addObjective", [id, position, size, "MIL"|"CIV", priority]] call ALiVE_fnc_OPCOM. The first element can be a handler, a side string or a faction string. ALiVE resolves a string through findOPCOMByAllegiance, which takes the first commander that matches, so with two commanders on one side pass a faction or the handler. If it finds nothing, it logs 'didn't find an OPCOM' and returns nil. The later arguments have defaults. Dev builds from late April to late September 2026 ignored a side or faction string and added nothing.

The FSMs read the first 10 keys of an objective hash by position, so those keys must never be reordered. Read them by name instead: objectiveID, center, size, objectiveType, priority, opcom_state, clusterID and opcomID.

[_objective, _side, 300, false] call ALiVE_fnc_isHeldObjective tells you whether an objective is still held and not overrun right now: fewer than 3 hostile units or profiles within 300 m, and either a section profile still registered or, with no section yet, the side's own or an allied unit or profile within the radius. It doesn't check who owns the objective, so pass the side of the commander whose objectives list it came from, [_opcom, "side", ""] call ALiVE_fnc_hashGet. Pass false as the last argument: it defaults to true, which instead requires the commander to have marked the objective reserve and, with no section yet, takes that mark on trust. A side other than WEST, EAST or GUER logs a line and returns false. Capture and defend events don't fire when an objective quietly changes hands, so poll this if you need ownership; the Event Reference has a worked example.

Orders

For a one-off order, use [_opcom, "addTask", ["recon"|"capture"|"defend"|"reserve", position, profileIDs]] call ALiVE_fnc_OPCOM. It makes an internal objective named <opcomID>_manual_<n> and puts the order at the back of the TACOM queue. An unsupported operation, a bad position or a commander whose TACOM isn't running gets a log line and nothing else.

For a timed order, use [_opcom, "addTimedTask", ["sad"|"ambush", position, profileIDs, seconds]] call ALiVE_fnc_OPCOM. The groups search and destroy, or lie in wait and open fire when an enemy comes within 80 m, and after the seconds (600 by default) the commander gets them back. It returns the internal objective, doesn't wait for TACOM, and does nothing without at least one profile ID or for any other type.

Commander state

A commander's starting force size is the handler's startForceStrength array, built as [infantry, motorised, mechanised, armoured, air, sea, artillery, AAA]. ALiVE saves it every session, and Military Logistics reads it when it sizes reinforcements. The increment and decrement helpers take "Infantry", "Motorized", "Mechanized", "Armored", "Air", "Sea", "Artillery" or "AAA" and match that order, so they're safe for all 8. With Start From Ship on, the array also counts the groups still aboard (handler key shipAboard), so the current strength stays below it until they're ashore.

The handler also holds the commander's Eden settings by name, for example recruiters, insTypes, drugLabs, securityPatrols, flanking, followPlayers, prepTasks, shipStart, shipWaveSize and shipWaveGap. Read them with [_opcom, "key", default] call ALiVE_fnc_hashGet once startupComplete is true, and treat them as read-only, since some are only looked at when the commander is created.

A commander given a Custom Name puts it in ALiVE_commanderCallsigns, a published HashMap keyed by side text ("WEST", "EAST", "GUER"); the first named commander of a side keeps the entry. Read it with getOrDefault, not hashGet. Messages sent through ALIVE_fnc_radioBroadcast as from HQ now open with "This is <name>." when the side has one, your own included.

Asymmetric commanders share the same objective pipeline. Read their state on the server with ALiVE_fnc_OPCOMAsymmetricState; there's no snippet for it yet.

Players joining in

Players can join the fight. [player, "attacking"] spawn ALiVE_fnc_OPCOMjoinNearestGroup teleports the player's group to the nearest group on that kind of order, and [player, "attacking"] call ALiVE_fnc_OPCOMJoinObjective opens the map with the commander's objectives marked, and once you click one moves your group to the commander's group there: beside it on foot, or into its vehicle. There is no parachute drop.

Logistics

Support and logistics

Force pool

The force pool is a hash keyed by faction class, so you read and write it with hashGet and hashSet. Military Logistics reads it with a default of 0, and player resupply draws on it. A resupply request a player cancels after its units are made, but before they arrive, puts what it cost back in the pool.

Military Logistics picks the ammunition truck it sends on a resupply run from the faction's own vehicles: from its entries in ALIVE_factionDefaultSupports and ALIVE_factionDefaultTransport, else from any of its cars, unarmed before armed, and only then the side's stock ammo truck. The choice is made once per faction, so set those hashes for a modded faction before its first resupply.

Compositions

ALIVE_fnc_spawnRandomPopulatedComposition takes [position, type, category, faction, size, infantry, motorised, mechanised, armoured, specOps]. It drops a composition and profiles the groups you ask for around it. Category and size can each be a string or an array, and ALiVE matches them as part of the class name.

Combat Support

Add Combat Support assets by script with ["CAS"|"TRANSPORT"|"ARTY", settings] call ALiVE_fnc_combatSupportAdd, and remove them with [side, type, callsign] call ALiVE_fnc_combatSupportRemove, where the type can also be "GROUND" for a ground transport asset. ALiVE takes the side from the vehicle class, upper-cases the callsign and flags the asset ALIVE_CombatSupport and ALIVE_profileIgnore. The settings depend on the type:

• CAS takes [pos, dir, class, callsign, code, height]
• TRANSPORT takes [pos, dir, class, callsign, code, height, slingloading, containerCount]
• ARTY takes [pos, class, callsign, unitCount, rounds, code]

Each asset can have its own replacement time and limit in ALiVE_CS_respawnReg, a server HashMap made when Combat Support starts. The key is the kind and the upper-case callsign, such as "CAS|PHANTOM 1" (kinds CAS, TRANS, GROUND, ARTY), and the value is [seconds, limit]: -1 in either slot uses the module's own value, and a limit of 0 means it's never replaced. So after adding an asset you can give it its own, for example ALiVE_CS_respawnReg set ["CAS|PHANTOM 1", [300, 2]].

Players and C2ISTAR

Player orders, intel and tasks

Player objectives

Players can hand a commander objectives from the C2ISTAR tablet, or with a map marker whose text starts obj take or obj hold; deleting the marker removes the objective, and obj recon, obj sad or obj ambush sends one group instead. Allow Player Objectives is now on by default, including on a module made by script, so set it to No to keep players out of the commander. The tablet's permission, cooldown and cap apply to markers too.

A player's take or hold objective carries a playerIntent key, read with [_objective, "playerIntent", ""] call ALiVE_fnc_hashGet. Take is an attack until only the side's own forces are on it, and then the key goes back to ""; hold is an attack while only the enemy is there and a defence otherwise. addObjective returns the objective hash, so a script can set the key on an objective it adds.

Known enemy

["report", "WEST", [positions]] call ALIVE_fnc_taskKnownEnemy, from any machine, tells that side's commanders about the enemy groups within 150 m of each position, and they count as seen for 30 minutes. That's what C2ISTAR's Tasks Only Against Known Enemy goes by. On the server, [_opcom, "knownEnemy"] call ALiVE_fnc_OPCOM returns what a commander knows as [profileIDs, positions].

Air requests

To file an air request for a player from a server script, use [_atoModule, "playerRequest", [_unit, "CAS", _pos]] call ALiVE_fnc_ATOKernel. Any of the mission's Air Component Commander modules will do as the first element: the request goes to the first running one that flies that type for the unit's side, else for an allied side, and the side hears the answer on the radio like any player request. It returns true when the request was filed.

Targets and tasks

[unit, roleKey, arg, name] call ALiVE_fnc_giveTargetPapers on the server gives a unit a Wallet (ID), and a player who takes it, from the body or from a prisoner, is told who the unit was. The role is a stringtable key such as "STR_ALIVE_TARGETID_HVT", and arg fills its %1. It works once per unit object, so a profile that despawns and spawns again needs another call. C2ISTAR's task targets and the insurgents' recruiters get theirs this way.

C2ISTAR deletes a finished task's records straight away. To learn how one ended, read ALiVE_c2istar_finishedTasks on the server, a HashMap of task ID to "Succeeded", "Failed" or "Canceled". With the module's Tablet Intel Log on, ["add", [sideText, faction, kind, position, title, detail, source]] call ALIVE_fnc_intelLog writes your own row to that side's log; a client's call goes to the server.

You can request C2ISTAR tasks from script with [side, faction, type, targets, requesterID, strategic] call ALiVE_fnc_taskRequest. That's the entry point, though it has no snippet yet either.

Rally points and FOBs

Rally points and FOBs

Rally points

Rally points are kept by the server in ALiVE_rallyPoints, each row starting [object, name, side, kind, ownerGroup]. Add, remove, list and travel with ALiVE_fnc_rallyPoint: ["add", [object, name, side, kind, ownerGroup]] (the last two optional; with an owner group, only its members see the point), ["remove", [object]], ["list", [unit]] and ["travel", [unit, destination, force]]. A client's add or remove is passed to the server, and travel runs where the unit is local.

With the Rally Points module's Leader Rally Points on, ["deploy", [unit]] puts down the squad leader's own rally point in front of him, ["pickup", [unit]] takes it away and ["rename", [unit, name]] renames it while he stands within 5 m of it. Deploy returns false with enemies near, during the cooldown or in a vehicle, and replaces the squad's earlier point. The squad's current point is group getVariable ["ALiVE_rallyDeployed", objNull].

Set _obj setVariable ["ALiVE_rallyOverrun", 120] on a rally point's object and the server takes it off the list once enemies have been within the module's Enemy Radius for that many seconds; the object itself stays. Points the module finds by sync or class use its Placed Rally Point Overrun Time, and any other point, a script's included, is never overrun without the flag. It needs a Rally Points module placed and doesn't apply to an "ANY" point.

FOBs

The Player FOBs module's logic is in ALiVE_sup_fob, and on the server its FOBs are ready when ALiVE_sup_fob getVariable ["startupComplete", false] is true. Every machine has ALiVE_FOB_registryMirror, one row per FOB as [id, side, name, pos, status, tier, supply, supplyCap, buildRange, deployedBy, type]. [ALiVE_sup_fob, "mayManage", [unit, deployerUID]] call ALiVE_fnc_FOB tells you whether a player may dismantle, recycle or rename a FOB under Who Can Dismantle; admins always may. Changes go through the server with ALiVE_fnc_fobRequest, never a direct call from a client.

Insurgency

Towns, roadblocks and IEDs

Town hostility

ALIVE_fnc_updateSectorHostility takes [position, sides, value] and adds the value to the hostility of every settlement cluster in that sector, for each side. It does nothing until both the sector grid and the cluster handler exist.

Roadblocks

Civilian Placement's roadblocks use the compositions picked in Eden. If that picker is empty, they fall back to the global ALiVE_compositions_roadblocks, then to the CheckpointsBarricades category.

[position, radius, "roadblock"] call ALIVE_fnc_addDismantleAction on the server lets players take apart a composition you spawned. After 5 s it sets a traffic cone beside it with a 15 s hold action that shows only when no enemy is within 60 m, and finishing it removes the composition and its saved copy through ALiVE_fnc_removeComposition. The third argument is the word players see, such as "fortifications".

Aid crates

["handover", [container, "WEST", objNull]] call ALiVE_fnc_aidCrate on the server hands a crate of food and water to the town within 200 m of it, if it holds at least 10 of the Civilian Population module's water and ration items. That town's hostility towards the side eases, and the call returns "delivered" or why it didn't: "toofew", "notown", "cooldown", "disabled" or "gone". Each town takes one per ALiVE_amb_civ_population_AidCrateCooldown (1800 s).

Bombers and car bombs

With the IED module placed, two of its functions can be called on the server. [[position, size, faction], [victims], true] call ALIVE_fnc_createBomber sends a suicide bomber from near the position after the first player in the victims list (false sends him after someone in that player's group) and returns him. [fromPosition, victimPlayer, faction] call ALIVE_fnc_createDrivenVBIED puts a car bomb on a road within 300 m of the position and drives it at the player, returning the driver or objNull.

Persistence

Saving your own data

Your own values

["key", value] call ALiVE_fnc_setData and ["key"] call ALiVE_fnc_getData write and read a per-mission hash that rides along with ALiVE's own save. setData returns false and stores nothing if the key isn't a string or the value's string form is 10000 characters or longer.

The hash only exists when a Data module is placed. Without one, setData is a script error and getData returns nil. Your values are saved and loaded whenever the Data module is saving, whether or not Save Mission Time is on; that setting only decides whether the date comes back. The server writes them when an admin uses Save Server or Server Exit, and on each autosave.

Saving on demand

To save the mission at a moment of your choosing, run "now" call ALiVE_fnc_AUTOSAVE_PNS on the server, from a trigger before a planned restart for example. It saves everything the Data module's Autosave does, your setData values included, and leaves a timed autosave running. The save itself comes about 8 seconds after the call, once players have been told ALiVE is about to save, so run it a little before the restart. It needs Database Source on Local; on anything else, or on a client, it logs why and does nothing.

Player saves

With the Player Options module's Persist By set to Slot, a player's saved kit, position and health follow the playable unit's Eden variable name, so whoever takes that slot gets them; a slot with no variable name falls back to the player and logs it, so name every playable unit. [unit] call ALiVE_fnc_playerKey returns the key a unit is saved under. With ACE loaded and Save Health on, the save also carries the player's ACE medical state.

Events

Events

The Event Reference lists every event and the data it carries. Register a listener on the server with [ALiVE_eventLog, "addListener", [_listenerHash, [types]]] call ALiVE_fnc_eventLog. The listener hash needs a class key holding the name of your own function, and ALiVE calls it as [_listenerHash, "handleEvent", _event] call yourFunction in a scheduled thread. The name is looked up once, when addListener runs, so define the function first: a listener added before it exists never hears anything. addListener returns an ID; remove the listener again with [ALiVE_eventLog, "removeListener", _listenerID].

The event log doesn't need the Required module, because the profile system creates it if it's missing. You can also raise an event yourself:

[ALiVE_eventLog, "addEvent", ([type, data, from] call ALIVE_fnc_event)] call ALIVE_fnc_eventLog

Pausing

Pausing modules

ALiVE_fnc_pauseModule takes a list of module class names, such as ALIVE_SYS_PROFILE and ALIVE_MIL_OPCOM. It matches them against the type of every placed module, ignoring case, and calls that module's own pause operation. ALiVE_fnc_unPauseModule reverses it.

Pausing a commander waits until its FSM is up before it takes, so call it after start-up.

Mission settings

Settings a mission can set in init.sqf

Some of ALiVE's behaviour reads a mission variable that has no module setting. Set these in init.sqf (or initServer.sqf for the server-only ones) before the modules start, and ALiVE uses your value instead of its default.

Classes go in as plain strings, for example ALiVE_PLACEMENT_CUSTOM_UNITBLACKLIST = ["B_Soldier_AT_F"];. The _CUSTOM_ lists are added to ALiVE's own, so you only name the extra classes.

Blacklists

• ALiVE_PLACEMENT_CUSTOM_UNITBLACKLIST, _VEHICLEBLACKLIST, _GROUPBLACKLIST: soldiers, vehicles and groups ALiVE never places. The unit list also keeps those classes out of the ambient civilians.
• ALiVE_MIL_CQB_CUSTOM_UNITBLACKLIST, ALiVE_MIL_CQB_CUSTOM_STRATEGICHOUSES, ALiVE_MIL_CQB_CUSTOM_STRATEGICPLATFORMS: soldiers CQB never uses, and extra buildings it treats as strategic.
• ALiVE_PR_CUSTOM_BLACKLIST, ALiVE_PR_CUSTOM_WHITELIST: vehicles taken off, or added to, the Player Resupply tablet. The whitelist also takes plain supply objects such as boxes and sacks, listed under Combat Supplies, and the tablet hides the placement vehicle blacklist too.
• ALIVE_Building_Blacklist: building classes no garrison may use, on top of each placement module's Garrison Building Blacklist.
• Garrison Area Blacklist: to keep garrisons out of one patch of ground rather than a building type, list area marker names in that placement-module setting. It's not an init.sqf variable.
• ALiVE_CivPop_excludeClassPatterns: parts of class names that are never made into civilians. Unlike the lists above, yours replaces the default ["RADOME_Spawner"], so include it if you still want it.

Commanders and air

• ALiVE_OPCOM_defenceHold: seconds a commander must hold an objective before it builds defences there (600).
• ALiVE_ATO_runwayLockTimeout: seconds an aircraft that hasn't yet left a runway may keep it held (180).
• ALiVE_ATO_patrolHeight: metres the Air Component Commander's fighters fly and loiter at on CAP and DCA patrols (1500). It's read each time an order goes out, so a server script can also change it while the mission runs.
• ALiVE_CS_scriptFireClasses, ALiVE_artyScriptFireClasses: gun classes whose rounds ALiVE fires by script straight away, for Combat Support and for the AI commander's artillery, instead of waiting on a crew that never fires, such as a launcher that ignores artillery orders. ALiVE adds a class itself the first time it has to, so you only need to name one that fails from the start.

C2ISTAR

• ALIVE_COP_LAYER_ENEMIES, _BFT, _OBJECTIVES, _ASYMMETRIC set to false: hide that layer of the C2ISTAR picture. The other ALIVE_COP_* values, such as ALIVE_COP_CLUSTER_RADIUS (200), tune how it's drawn.
• ALiVE_c2istar_surrenderChance: the chance an enemy gives up. C2ISTAR sets it from its own setting, and a server script can change it while the mission runs; 0 turns it off.
• These C2ISTAR settings work like ALiVE_c2istar_surrenderChance: the module sets them when it starts, so change them from a server script afterwards with missionNamespace setVariable [name, value, true]. ALiVE_c2istar_fieldLieChance (0 to 100, how often a prisoner questioned in the field lies, 0), ALIVE_civicHoldDuration (seconds players hold the area after a Hearts and Minds task's action, 120; 0 turns it off), ALIVE_aidAirliftChance (share of Aid Delivery tasks flown in by helicopter, 0), ALiVE_c2istar_hvtManhuntChance (share of HVT tasks that start as a manhunt, 0) and ALiVE_c2istar_tasksKnownOnly (tasks only against enemy the side knows of, false).
• ALiVE_accessPoint on any object (this setVariable ["ALiVE_accessPoint", true, true] in its init): a player within 10 m, or within the number of metres you give instead of true (up to 50), gets the C2ISTAR, Combat Support and Player Combat Logistics menus as if carrying the access items. For HQ-only commanding, set the modules' access items to something nobody carries. C2ISTAR's Command Point Classes do the same for every object of a class, published as ALiVE_accessPointClasses and ALiVE_accessPointRadius (10 m, up to 200); an object's own ALiVE_accessPoint, false included, overrides them.

Civilians

• ALiVE_CivPop_onEachSpawn: code run as [_unit, _agentID] for every civilian that spawns. The Civilian Population module's On Each Spawn field fills it when that isn't empty.
• ALiVE_advciv_blacklist set true on a civilian (_civ setVariable ["ALiVE_advciv_blacklist", true, true]): Advanced Civilians leave that one alone, and players get no orders menu on it.

Headless clients

• ALiVE_ignore_HC set true on a unit (broadcast): ALiVE moves whole groups to headless clients and leaves a group alone only when every living unit in it is flagged, so flag them all or give the unit its own group. [true] spawn ALiVE_fnc_AI_Distributor on the server starts moving AI once ALiVE has started; [false] stops it. With ACE's headless transfer on, ALiVE stands down and passes the flag on as ACE's blacklist.

Other mods

Other mods

• ALiVE's logistics registry now tracks ACEX Fortify objects without any mission code.
• Combat Support sets VCOM_NOAI on the driver of its CAS, transport and artillery assets, and on every crew member of a ground transport asset. Nothing else in ALiVE reads or sets VCOM or NOAI variables.
• ACE captive handling can feed civilian hostility through ALIVE_fnc_updateSectorHostility, which needs the Civilian Population module.

From ALiVE 2

Changed since the ALiVE 2 wiki

Code copied from the old wiki may need these changes.

Worth knowing

Before you build on this

• Everything here describes the current development build and can change between builds; the Script Snippets page records the build each snippet was last run on.
• If a call on this page doesn't behave as described, raise it on the issue tracker with your RPT.

Changelog

Updates to this page

• 2026-10-27
  Checked against the current code and brought up to date: player objectives and map markers, timed SAD and ambush orders, known-enemy reports, ALiVE_accessPoint command posts, rally point and FOB calls, aid crates, IED bombers, spawn source radius, route memory and new init.sqf settings, plus fixes to isHeldObjective, the force-strength helpers, event listeners and headless clients.