Arma 3: Server Side Scripting

From Bohemia Interactive Community
Jump to navigation Jump to search

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 Arma 3 logo black.png2.18 Called repeatedly while a new player is trying to join the server. Must return either "ACCEPT", "DELAY" or "REFUSE":
  • "ACCEPT": the player is let through into the server.
  • "DELAY": the player stays in the loading screen and is not let into the server.
  • "REFUSE": the player is kicked; a kick message can be appended by sending "REFUSE_You were kicked because reason".
  • 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.
sendChatMessageArma 3 logo black.png2.18 Send a "System" chat message to the specified user
  • userId: String - the DirectPlay ID of the connecting player, see getPlayerID
  • message: String - Text message to be sent (If message starts with $, it will be sent as localized chat message and displayed in the receivers language)


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


Mission Scripts Interaction

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", []]; }]; ExtensionReady = true;

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

Call 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 value };

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 compiles 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.