Multiplayer Scripting

This page aims to explain notions and specificities of Multiplayer Scripting and its differences with Singleplayer Scripting.

It features three parts:

1. #Notions and general knowledge
2. #Structuring Multiplayer code
3. Testing locally

Notions and general knowledge

The basics

• In Multiplayer, players are connected to a server.
  • The server is a machine that distributes information among clients, such as unit positions, vehicle speeds, etc.
  • The server can be either a dedicated machine, or hosted by a player; in the latter it means the server can have a player unit.
• A machine connected to a server is called a client.
  • Clients can join a mission after it started: they are considered "JIP" and scripting should be adapted to them. See the #Join In Progress chapter for more information.

Note

In Singleplayer, the game acts as a player-hosted server (isServer returns true).

Warning

Some Multiplayer commands do not work in Singleplayer, such as netId!

The other way around, some Singleplayer commands do not work in Multiplayer (e.g setAccTime).

Locality

Definitions

• LOCAL is an attribute for the machine where the command/script/function is executed or the AI calculated.
  • to check if an argument is local, use the local command
• REMOTE means non local - on another machine. All player-controlled soldiers are remote units to a dedicated server, for example.
  • to check if an argument is remote, simply use not local _myObject
• commands arguments and effects can be either local or global:

Note

See also:

• Scripting Commands: Local Effect
• Scripting Commands: Global Effect
• Scripting Commands: Server Execution
• Functions: Local Effect
• Functions: Global Effect
• Functions: Server Execution

Different machines and how to target them

Note

• For obvious reasons, a server cannot be JIP.
• Use didJIP to determine if a client joined during the game.

For an extended version for all games, click

Note

Before Operation Flashpoint v1.99 and the backport of isServer, the server could be identified by placing a Game Logic in the editor (that would always remain local to the server), then using the following: local myLogic.

• If you want to know if the current machine is a server (Dedicated Server or Player Server), use isServer.
• If you want to know if the current machine has a player (Player Server included), use hasInterface.

Note

Arma 3: Since Arma 3, a server-only init file is available: initServer.sqf (see Event Scripts)

Note

Arma 3: BIS_fnc_getNetMode can be used to have a string value representing the local machine status ("DedicatedServer", "Server", "HeadlessClient", "Client", "SinglePlayer" ).

This function doesn't make the JIP distinction and should be used along didJIP.

General information about locality

• about player:
  • a player's unit is always local to the (human) player's machine
  • a dedicated server doesn't have a player unit (isNull player returns true)
  • to know if a certain unit is a player, use isPlayer
• groups and AI:
  • an AI group with a player-leader will be local to the player's computer
  • a subordinate player being in a player-lead group will remain local to its computer (see bulletpoint #1)
• objects:
  • a driven vehicle is always local to the machine of its driver (not the commander's, not the gunner's)
  • terrain objects (buildings, vegetation, roads etc.) are local everywhere (local nearestBuilding player returns true on every client)
  • editor-placed objects and empty vehicles are local to the server
  • editor-placed triggers are created on every machine unless specified otherwise ("Server Only" Eden Editor option ticked)
  • units created with createUnit will be local to the computer that issued the command
  • objects and vehicles created with createVehicle will be local to the computer that issued the command

Locality changes

• if the player-leader dies, the AI is transferred to the machine where the new leader is local (server in case of AI, client in case of another player)
• joining AI units will change locality to the new leader's computer
• locality will change from server to client when a player gets in an empty vehicle
• locality can also change in the event of a Team Switch or usage of selectPlayer

Note

Arma 3: Since Arma 3 the "Local" Event Handler triggers when an object's locality is changed.

Code examples

Network ID

Network IDs identify machines and network objects. They can be used to target proper machines with remote execution; see the #Remote Execution chapter for more information.

Warning

A machine ID (ownerID) is not to be confused with an object's network ID (netId).

Machine network ID

Every machine, including the server, has a network ID.

A server always has an ID of 2, every new client has the next number (the first client will be number 3, second client number 4, etc.)

• To get the current machine's ID, use clientOwner.
• To get the machine ID of an object's owner, use owner object (MP only).
• To get the machine ID of a group's owner, use groupOwner object (MP only).

Note

0 and 1 are special values:

• 0 means everyone (including the server)
• 1 means current machine but is not implemented and should not be used.

Object network ID

Every object synchronised through the network has a network ID, shortened to netId.

• To get an object's netId, use netId (MP only). SP & MP variant: BIS_fnc_netId
• To get an object from a netId, use objectFromNetId (MP only). SP & MP variant: BIS_fnc_objectFromNetId
• To get a group from a netId, use groupFromNetId (MP only). SP & MP variant: BIS_fnc_groupFromNetId

Sending information across network

Remote Execution

Since Arma 3 v1.50, remoteExec and remoteExecCall efficient engine network commands are available:

"Message to everyone, including JIP players!" remoteExec ["hint", 0, true];

See Arma 3: Remote Execution for more information.

Arma 3 alpha introduced BIS_fnc_MP (obsolete since Arma 3 v1.50, use the above version):

["Message to everyone, including JIP  players!", "hint", true, true] call BIS_fnc_MP;  // obsolete since Arma 3 v1.50, use remoteExec or remoteExecCall

Arma 2 introduced the Arma 2: Multiplayer Framework (not present in Arma 3):

// having the Functions module placed in the editor
waitUntil { not isNil "BIS_MPF_InitDone"; };
[nil, nil, rHINT, "Message to everyone!"] call RE;

PublicVariable commands

PublicVariable commands allow to send global variables to specified machines.

• Network reception is guaranteed
• Short variable names should be used for network performance
• These commands shouldn't be used intensely for the same reason

How it works

The server has the variable ABC_Score to broadcast:

ABC_Score = 5;                // sets the value
publicVariable "ABC_Score"    // publishes the variable (do not forget the quotes!)

This sends the variable name and value to the clients.

• If the variable is not yet declared on their machine, it will declare it as well.
• If the variable already exists, the value is overridden by the server's value.
• If the variable changes again on the server, it has to be manually publicVariable'd once again!
• A JIP player will synchronise server's publicVariable'd variables before executing init.sqf. See Initialisation Order for more information.
  • A JIP player will not synchronise publicVariableClient-received variables after he disconnects/reconnects. Only server-known public variables sent with publicVariable will be synchronised.

setVariable command

Available since Arma 2, the public version of the setVariable command (alternative syntax) allows you to store a variable into an object and spread this variable across the network.

Note

Arma 3: In Arma 3 it is possible to broadcast the nil value, thus deleting the variable from the target.

Player connection events

The following commands will execute given code when a player is connecting or disconnecting. This code will run for players connecting in the lobby and for JIP players!

• "PlayerConnected" mission Event Handler
• "PlayerDisconnected" mission Event Handler

Note

Before Arma 3 v1.58, use BIS_fnc_addStackedEventHandler for onPlayerConnected/onPlayerDisconnected.

Client state

A client state is the client's connection state. It can be obtained with getClientState and getClientStateNumber commands on both server and clients.

Join In Progress (Armed Assault v1.00)

Join In Progress (JIP) is the ability for a player to connect while a game is running, unlike in Operation Flashpoint where one had to wait for the game to be over.

It was introduced in on Xbox and Armed Assault on PC.

A player that joined in progress will be referred to as JIP player.

Note

To disable JIP on a server:

• the server admin can disable playable slots on the role selection screen
• the mission designer can disable AI within mission config However, JIP remains available if respawn is enabled in the mission.

JIP Synchronisation

A JIP player will have a lot of information synchronised (publicVariable'd and setVariable server variables for example) by the game before accessing the mission itself; see below:

Warning

All the initialisation fields code get executed again for each and every JIP connecting player.

This means that code with global effect Global Effect (such as setDamage) WILL be re-executed (depending on locality)!

Related Commands

• remoteExec
• remoteExecCall
• didJIP
• didJIPOwner
• exportJIPMessages
• isRemoteExecutedJIP

See also

• Headless Client
• Initialisation Order
• Arma 3: Remote Execution

Structuring Multiplayer code

Responsibilities

• The server initialises and works with variables
• A connecting or connected player-client gets the mission data from the server
• Once an objective is reached, the server tells the players via remoteExec/remoteExecCall, publicVariable or setVariable
• Players can get their client-side UI code triggered by the server See this earlier chapter to know how to target specific machines.

Server

The Server must be considered as the one ruler of the mission. He is the game's referee and all the decisions should come from it. All the values on the server should be considered as true.

Consider the server as a powerful machine where you can put all the mission conditions and heavy scripting on. In case of a very heavy mission, the server can be assisted by Headless Clients (this involves a per-mission specific design).

Server-side code must gather or wait all the variables (potentially from client-side scripts and publicVariableServer) and take and broadcast its decisions accordingly using publicVariable.

Server-side code should ideally not make any reference to a player variable considering a server can potentially be dedicated, unless you want to force this mission to be player-hosted (such as Arma 2's campaign).

Note

Use allPlayers, BIS_fnc_listPlayers, playableUnits (and switchableUnits for SP compatibility) to refer to players.

Client

The Client must be considered as an average machine that can leave the game at any moment. No mission-vital code must be executed on its side and no decisions must be taken client-side.

Again, one must expect that any client can disconnect at any moment.

The client executes all the (local) UI code (Post Process Effects, Dialogs, etc.)

The player's machine should not deal with a great piece of code.

Important

Do not forget that a server can be a player, and therefore should execute player code in that case.

The proper way to check for player-side condition is

if (hasInterface) then { /* (...) */ };

Note that the following example is incorrect:

if (isServer) then
{
    // ...
}
else // WRONG: a server CAN be a player
{
    // ...
};

Code writing

The usual four steps of coding are the following:

• Think it well
  • If you cannot figure out how to write your code, say what you want to do out loud or write it down in your language, then replace it by code little by little.
• Make it work
  • use the -showScriptErrors startup parameter to see your code errors.
• Make it readable
  • name your variables properly, as if you had to give it to someone that should get it without the need of explaining
• Optimise then
  • use more performance-friendly commands, reduce your search radius and loop frequencies once everything works.

See Code Optimisation#Rules for advices and more information.

See also

• Event Scripts
• Code Optimisation

Local Multiplayer Testing

To ensure all cases, your mission should ideally work properly:

• in Singleplayer
• in Player-hosted Multiplayer
• in a Dedicated Server-hosted game

The following chapters explain how to mimic multiple clients on one computer. Of course, nothing prevents you from inviting friends to play your mission and report bugs!

Dedicated Server

To properly test MP scripting locality issues, it is recommended to run a dedicated server and connect with two clients. In order to do so:

• In your server executable's server.cfg:

loopback = true;    // force LAN-only server
kickDuplicate = 0;    // disable duplicate Arma kick

// needed in case of Headless Client test only
headlessClients[]    = { "127.0.0.1" };
localClient[]        = { "127.0.0.1" };

• Run the game twice from Steam and connect each (with -showScriptErrors flag)
  • If you use one screen for the first client and the other screen for the second client, use -noPause -window launcher options. This will not pause render if the window doesn't have focus.

Important

Be sure to disable BattlEye or it will close any additional instances.

• Try your mission and check for script errors:
  • on client's screens and RPT files
  • in your server's RPT files

Player-Hosted Server

While this method covers less cases than the #Dedicated Server Test method above, this method is faster:

• Open the Arma 3: Launcher and disable BattlEye
• Select the mods that the host will use (if any)
• Launch the game using the Play/Play with Mods button
• Select the mods that clients will use
• Launch the game again using the Play/Play with Mods button
• In the first game instance (server), host the mission either through local hosting or with Eden Editor MP mission type launch
• In the second game instance (client), join the session using the MP tab LAN section and entering the mission hosted by the server

See Also

• Arma 3: Dedicated Server
• server config