Lou Montana/Sandbox – User
Jump to navigation
Jump to search
Template:SideTOC Template:Stub
The basics
- In Multiplayer, players are connected to a server that distributes information among them.
- 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.
- Players can join a game after it started: they are considered "JIP" and scripting should be adapted to them.
Locality
Definitions
- LOCAL is an attribute for the machine where the command/script/function is executed.
- REMOTE means non local. All players are remote units to a dedicated server, for example.
- commands arguments and effects can be either local or global:
Template:EffArg | a local argument means an argument that is processed on the machine where the command is executed |
Template:EffArg | a global argument means any unit, even a remote one |
Template:EffArg | a local effect means that the effect will only happen on the machine where the command is executed |
Template:EffArg | a global effect means that all the computers will receive it |
See Locality in Multiplayer for more information.
Different machines
Machine | Conditions |
---|---|
Dedicated Server | isDedicated
|
Player Server | hasInterface && isServer
|
Client | hasInterface && not isServer
|
JIP Client | hasInterface && didJIP
|
Headless Client | not hasInterface && not isDedicated
|
- 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
.
General information about locality and its changes
- a player's unit is always local to the player's machine.
- 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)
- a driven vehicle is always local to its driver (not the commander, not the gunner)
- editor-placed objects and empty vehicles are local to the server
- 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 where the 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
- a driver gets in an empty vehicle, locality will change from server to player
- locality can also change in the event of a ||Team Switch]] or usage of selectPlayer
Code examples
Code | Argu-ments | Effect | Description |
---|---|---|---|
remoteUnit setDamage 1;
|
Template:EffArg | Template:EffArg | Any unit (local or remote) will die, and all the computers will know |
localUnit addMagazine "30Rnd_556x45_STANAG";
|
Template:EffArg | Template:EffArg | Only a local unit can have its inventory edited with this command, but all the machines will be notified: if a player looks into the localUnit inventory, the added magazine will be there |
remoteUnit setFace "Miller";
|
Template:EffArg | Template:EffArg | Any unit (local or remote) can get its face changed, but the new face will not be propagated through the network. Only the local machine's player will see the effect of the command |
localCamera cameraEffect ["Internal", "Back"];
|
Template:EffArg | Template:EffArg | Only a local camera can be entered, and of course only the local machine will see through this camera |
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
Command | Effect |
---|---|
publicVariable | Set/update a variable value from the local machine to all the other machines (including server) |
publicVariableServer | Set/update a variable value from a client to the server |
publicVariableClient | Set/update a variable value from the local machine (not necessarily the server) to a specific client |
How it works
The server has the variable ABC_Score
to send to everyone, it then uses publicVariable "ABC_Score"
(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 public variables before executing init.sqf. See Initialization 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.
Remote Execution
Arma 2 introduced the (now obsolete) Multiplayer framework, used as follow:
waitUntil{ not isNil "BIS_MPF_InitDone"; }; [nil, nil, rHINT, "Message to everyone!"] call RE;
Arma 3 alpha introduced BIS_fnc_MP:
["Message to everyone, including JIP players!", "hint", true, true] call BIS_fnc_MP;
Arma 3 (> v1.50):
["Message to everyone, including JIP players!", 0, true] remoteExec ["hint"];
See Arma 3 Remote Execution for more information.