Arma 3: Server Side Scripting

The server has a separate Virtual Machine (VM) running administration scripts. This VM is completely independent on the game scripting environment and is designed to automate some administration tasks related to player administration and cheat detection. The basic way how scripts are executed is via event handlers reacting to some typical events, server admin can also execute individual commands using a chat command #exec.

Event handlers are defined in the server.cfg file.

Event Handlers

Event Name	Description	Handler Parameters
doubleIdDetected	2nd user with the same ID detected	user id
onUserConnected	user has connected	user id
onUserDisconnected	user has disconnected	user id
onHackedData	modification of signed pbo detected	user id, file name
onDifferentData	signed pbo detected with a valid signature, but a different version than a server has (very strict test, use sparingly, no longer supported in Arma 2 OA 95232)	user id, file name
onUnsignedData	unsigned data detected	user id, file name
onUserKicked	if a user is kicked	user id, kick type ID, reason
regularCheck	called time by time for each user, test index is growing, example: 0 checkFile _this	user id, test index
onPlayerJoinAttempt 2.16	Called repeatedly while a new player is trying to join the server. Must return either "ACCEPT", "DELAY" or "REFUSE". On "ACCEPT" the player is let through into the server. On "REFUSE" the server is kicked, there can be a kick message appended by sending "REFUSE_You were kicked because..". On "DELAY" the player stays in the loading screen and is not let into the server.	userId: String - The DirectPlay ID of the connecting player, see getPlayerID waitTime: Scalar - The time in second since when the players connection attempt has started. How long the player has been waiting in loading screen.

Commands

Specific Commands

Command Syntax	Category	Description
users	User	List users, each user is described as an array in format [id, name]
kick userId reason	User	Kick off given user id from the server, with an optional text
ban userId reason	User	Add given user id into the ban list, with an optional text
unkick userId	User	Remove a kick from the server's list
unban userId	User	Remove a ban from the server's list
clearKicks	User	Clear all existing kicks from the server's list
clearBans	User	Clear all existing bans from the server's list
numberOfFiles userId	File	number of addons files used for given player - can be used to determine suitable values for checkFile
level checkFile [userId, fileIndex]	File	See Addon Signature for a file with given index on given user computer, level determines test depth (0 = default, 1 = deep. Note: deep can be very slow)
level checkExe userId	File	Start the integrity check of game executable for given user. Level defines how exhaustive the test should be
lock	Game	Lock/unlock the session

Shared Commands

• !
• +
• -
• :
• abs
• acos
• append
• apply
• arrayIntersect
• asin
• assert
• atan
• atg
• breakOut
• call
• case
• ceil
• comment
• compile
• compileFinal
• cos
• count
• count
• deg
• deleteAt
• deleteRange
• diag_log
• disableSerialization
• do
• echo
• else
• exitWith
• exp
• false
• find
• findIf
• finite
• floor
• forEach
• for
• if
• in
• isFinal
• joinString
• ln
• log
• nil
• not
• parseNumber
• parseSimpleArray
• pi
• private
• pushBack
• pushBackUnique
• rad
• random
• resize
• reverse
• round
• scriptName
• select
• selectMax
• selectMin
• selectRandom
• selectRandomWeighted
• set
• sin
• sort
• splitString
• sqrt
• str
• switch
• tan
• tg
• then
• throw
• toArray
• toLower
• toLowerANSI
• toString
• toUpper
• toUpperANSI
• true
• try
• typeName
• waitUntil
• while
• with

Since 2.16

• missionNamespace
• uiNamespace
• getUserInfo
• callExtension
• setVariable (Namespace variant only)
• getVariable (Namespace variant only)

Interaction with mission scripts

Since the new commands added in 2.16 it is possible to interface with mission scripts that are not limited to the server scripts command set.

There are two main approaches for this detailed below.
One major thing to keep in mind is that both these approaches depend on mission scripts being present. Which is not the case when a server is freshly started and didn't load a mission yet. So you need to account for the handlers not being present.

CallExtension with callbacks

callExtension being available offers the option to communicate through the Extension. As extension callbacks are executed in mission scripts.
When the extension receives a request, it can trigger a callback to send information to be handled inside a mission script.

Here is an example of a (pseudocode) extension utilizing this pattern for a "onPlayerJoinAttempt" event.
Extension code:

bool goodToGo = true;
bool goodToKick = false;
string kickReason = "";

RvExtensionArgs(string output, string method, string[] args)
{
	if (method == "joinRequest")
	{
		if (goodToGo)
		{
			goodToGo = false; // Only once
			output.Append("ACCEPT");
			return;
		}

		if (goodToKick)
		{
			goodToKick = false; // Only once
			output.Append("REFUSE");
			output.Append(kickReason);
			return;
		}

		// Tell our script handler about this
		callback("ext", "joinRequest", args[0]);

		output.Append("DELAY"); // Wait till our script tells us what to do
	}

	if (method == "go")
		goodToGo = true;

	if (method == "kick")
	{
		goodToKick = true;
		if (args.Length >= 1)
			kickReason = args[0];
	}
}

The server config side looks like this

onPlayerJoinAttempt = " if (missionNamespace getVariable ['ext_ready', false]) then { ('extension' callExtension ['joinRequest', _this]) select 0 } else { 'ACCEPT' } ";

Notice how we specifically check for a missionNamespace variable to indicate whether the actual callback handler is ready.

Then we have this mission script:

addMissionEventHandler ["ExtensionCallback", { 'extension' callExtension ["go", []]; }]; ext_ready = true;

This doesn't actually implement any logic for handling player joins, but you can see how you could pass data through the callback and handle it accordingly.

Calling missionNamespace functions

Since getVariable has become available, and call has already been available previously, this means we can now get functions from missionNamespace and execute them from our server scripts environment.

Example:

Server config:

onPlayerJoinAttempt = " call (missionNamespace getVariable ['PlayerJoinHandler', {'ACCEPT'}]) ";

Mission script:

PlayerJoinHandler = { params ["_playerId"]; "ACCEPT" // return };

Note a major thing here, we call a function from server-side script, that uses params, even though params is a command that is not available to server side scripts.
This is because we are executing a normal script function, inside the server side scripting environment. The function was compiled in normal environment so it knew the script commands, they were compiled into the script function and thus they now work.
But we are still executing in server environment. Meaning if we execute things like compile the command itself will execute inside the server environment, and we wouldn't be able to compile a script containing params because the server environment would not know the script command.

This also applies in the opposite direction. Mission scripts cannot use server side scripting commands. But if the mission script compile's a new script, we could be using server commands like "kick" or "ban".

Care must be taken with scripting like this, it is best to do as little logic as possible in script functions that are accessed this way. There might be many bugs here that likely will not get fixed. The basics work, so keep it basic.