remoteExec

1.50

Hover & click on the images for description

Description

Description:

Asks the server to execute the given function or script command on the given target machine(s).

• Functions are executed in the scheduled environment; suspension is allowed.
• Script commands are executed in the unscheduled environment; suspension is not allowed.
  

Read Arma 3: Remote Execution for more information about remote execution, security features and JIP techniques.

ⓘ

Just like remoteExecCall, remoteExec can be used in SP; the behaviour is the same as in MP.

ⓘ

The direct execution of call or spawn via remoteExec (or remoteExecCall) should be avoided to prevent issues in cases where the remote execution of call or spawn is blocked by CfgRemoteExec. Instead it is recommended to create a function which is then excecuted by remoteExec (or remoteExecCall).

ⓘ

remoteExec executions are queued and are therefore executed in the same order on remote clients:

"Message 1" remoteExec ["systemChat"];
"Message 2" remoteExec ["systemChat"];

will result in

Message 1
Message 2

on all clients.

Groups:

Multiplayer

Syntax

Syntax:

params remoteExec [functionName, targets, JIP]

Parameters:

params: Anything - The parameter(s) for the function / command specified in the functionName parameter.

functionName: String - Function or command name.
While any function or command can be used here, only those allowed by CfgRemoteExec will actually be executed.

targets (Optional, default: 0):

• Number (See also Machine network ID) -
  • 0: The function / command will be executed globally, i.e. on the server and every connected client, including the machine where remoteExec originated.
  • 2: The function / command will only be executed on the server.
  • Other number: The function / command will be executed on the machine where clientOwner matches the given number.
  • Negative number: The effect is inverted: -2 means every client but not the server, -12 means the server and every client, except for the client where clientOwner returns 12.
• Object - The function / command will be executed where the given object is local.
• String - Interpreted as an Identifier (variable name). The function / command will be executed where the object or group identified by the variable with the provided name is local.
• Side - The function / command will be executed on machines where the player is on the specified side.
• Group - The function / command will be executed on machines where the player is in the specified group.
• Array - Array of any combination of the types listed above.

JIP (Optional, default: false):

• Boolean - If true, a unique JIP ID is generated and the remoteExec statement is added to the JIP queue from which it will be executed for every JIP.
• String -
  • If the string is empty, it is interpreted as false.
  • If the string is in format "Number:Number" (e.g. "0:0"), it is interpreted as a netId (see below).
  • Else the string is treated as a custom JIP ID and the remoteExec statement is added to the JIP queue, replacing statements that have the same JIP ID.
• Object, Group or netId - The persistent execution of the remoteExec statement is attached to the given object or group.
  When the object / group is deleted, the remoteExec statement is automatically removed from the JIP queue.

The JIP parameter can only be used if the targets parameter is 0 or a negative number.
See also Example 3 on how to remove statements from the JIP queue.

Return Value:

• nil - In case of error.
• String - In case of success.
  • If the JIP parameter was false or an empty string, the return value is "".
  • If the JIP parameter was true or a custom JIP ID, the JIP ID is returned.
  • If the JIP parameter was an Object, a Group or a netId, the (corresponding) netId is returned.

Alternative Syntax

Syntax:

remoteExec [functionName, targets, JIP]

Parameters:

functionName: String - See the main syntax above for more details.

targets (Optional, default: 0): Number, Object, String, Side, Group or Array - See the main syntax above for more details.

JIP (Optional, default: false): Boolean, String, Object, Group or netId - See the main syntax above for more details.

Return Value:

nil or String - See the main syntax above for more details.

Examples

Example 1:

Execute hint "Example 1"; on various machines: "Example 1" remoteExec ["hint"]; // Executed on all machines. "Example 1" remoteExec ["hint", 3]; // Executed only on the first connected client. "Example 1" remoteExec ["hint", -2]; // Executed everywhere except on the server.

Example 2:

Execute hint "Example 2"; on various machines and add it to the JIP queue: _result = "Example 2" remoteExec ["hint", -2, true]; // _result is a unique JIP ID, e.g. "3_1". _result = "Example 2" remoteExec ["hint", -2, "My_JIP_ID"]; // _result is "My_JIP_ID". _result = "Example 2" remoteExec ["hint", 0, MyObject]; // _result is the unique netId of MyObject, e.g. "2:3". Note that if there already was a statement with the JIP ID "My_JIP_ID" in the JIP queue, that statement has now been overwritten.

Example 3:

Remove statements from the JIP queue: remoteExec ["", "My_JIP_ID"]; // The persistent statement with the JIP ID "My_JIP_ID" is removed from the JIP queue. remoteExec ["", MyObject]; // The persistent statement attached to MyObject is removed from the JIP queue.

Example 4:

Some more complex examples: ["Open", true] remoteExec ["BIS_fnc_arsenal", MyTargetPlayer]; [MyCurator, [[MyObject1, MyObject2], false]] remoteExec ["addCuratorEditableObjects", 2];

Example 5:

A tricky example: Trying to execute player setAmmo [primaryWeapon player, 1]; (on machines where the player is in MyGroup). Consider the following statements: {player setAmmo [primaryWeapon player, 1];} remoteExec ["call", MyGroup]; // Statement 1 [player, [primaryWeapon player, 1]] remoteExec ["setAmmo", MyGroup]; // Statement 2 Both statements look very similar, but only Statement 1 has the intended effect. This is because in Statement 2, the arguments player and primaryWeapon player are not resolved on the target machine(s), but on the machine executing remoteExec.

Additional Information

See also:

remoteExecCall remoteExecutedOwner isRemoteExecuted isRemoteExecutedJIP Arma 3: Remote Execution canSuspend BIS_fnc_MP

Notes

Report bugs on the Feedback Tracker and/or discuss them on the Arma Discord or on the Forums.
Only post proven facts here! Add Note

Posted on December 29, 2015 - 20:28 (UTC)

AgentRev

remoteExec and remoteExecCall are currently filtered by BattlEye's remoteexec.txt, the string analyzed by BE is formatted the same way as the following example's output: format ["%1 %2", functionName, str params] If CfgRemoteExec class Functions is set to mode = 1;, the following remoteexec.txt exclusion can be used to safely allow all whitelisted *_fnc_* functions taking an array as parameter to go through: !="\w+?_fnc_\w+? \[[\S\s]*\]" Any attempt to exploit this exclusion using other RE methods like createUnit will run into "Error Missing ;" without any malicious code being executed. Mod makers should refrain from remote-executing raw commands from clients, as they require individual exclusions, and instead use *_fnc_* functions taking an array as parameter, which are covered by the above exclusion.

Posted on May 25, 2016 - 18:23 (UTC)

Killzone Kid

When adapting mission from dedicated server for SP, if target used in remoteExec is -2 (execute on every client but not server), in SP this will not execute since client is server in SP. To work around, the target could be set using isMultiplayer condition like this: "123" remoteExec ["hint", [0, -2] select isMultiplayer]; This will execute hint on every client in MP on dedicated server (target -2) and will also execute it in SP (target 0).

Posted on May 28, 2016 - 20:51 (UTC)

R3vo

While KK's solution works fine in sp missions and on dedicated servers, it will not work properly for hosted missions.
Solution: [0,0.5] remoteExec ['fadeRadio',[0,-2] select isDedicated,true];
Singleplayer: isDedicated returns false -> code is executed everywhere (0)
Hosted: isDedicated returns false -> code is executed everywhere including host (0)
Dedicated: isDedicated returns true -> code is executed everywhere excluding server(-2)

Posted on Jan 30, 2017 - 18:35 (UTC)

Pierre MGI

[some params] remoteExec ['some command',2,true]; will fail, as you can't use JIP and remoteExec on server only
[some params] remoteExec ['some command',2]; // works

Posted on May 10, 2017 - 20:10 (UTC)

Killzone Kid

To remoteExec: titleText ["Test Message", "PLAIN", 1]; Use [["Test Message", "PLAIN", 1]] remoteExec ["titleText"];

Posted on April 22, 2018 - 15:29 (UTC)

KC Grimes

It seems that only global functions can be executed, as opposed to local. <params> remoteExec ["fnc_someScriptedFunction", targets, JIP]; //Works
<params> remoteExec ["_fnc_someScriptedFunction", targets, JIP]; //Does not work

Posted on March 5, 2021 - 00:48 (UTC)

7erra

The remoteExec'ed function only has to exist on the target machine. For example: // initPlayerLocal.sqf TAG_fnc_testRemote = { hint "Remote Exec Received"; }; // Execute on dedicated server: [] remoteExec ["TAG_fnc_testRemote", -2]; Will display a hint for every client. This is especially useful for when the server is running a mod that is not required by clients.

Posted on June 26, 2021 - 08:46 (UTC)

1Dragster

Returning an example for scripted commands: // someScriptCommand <params>; <params> remoteExec ["someScriptCommand", targets, JIP]; // <params1> someScriptCommand <params2>; [<params1>, <params2>] remoteExec ["someScriptCommand", targets, JIP];

Leopard20 - c

Posted on Nov 04, 2021 - 11:31 (UTC)

Note that [code] remoteExec ["call"] is unscheduled, even if the current environment is scheduled. For example, the following code will result in an error: [] spawn { [{sleep 1; hint "Hello";}] remoteExec ["call"]; } But it would be valid without remoteExec (see Scheduler): [] spawn { call {sleep 1; hint "Hello";} }