Page MenuHomeFeedback Tracker

Receiver of remoteExec from headless client will see remoteExecutedOwner == 0
New, NormalPublic


Consider the following code. Process 1 remoteExecs a function on process 2, which reports the value of remoteExecutedOwner in process 2's UI. Process 2 then remoteExecs back to process 1 to again report the value of remoteExecutedOwner in process 1's UI.

The net result is that process 2 outputs "Receive from P1" and process 1 outputs "Response from P2".

LocalFunction =
    systemchat format ["Response from %1", remoteExecutedOwner];

private _remoteFunction =
    systemchat format ["Receive from %1", remoteExecutedOwner];
    [] remoteExec ["LocalFunction", remoteExecutedOwner];

[[], _remoteFunction] remoteExec ["call", 2];

As shown, the code calls to the server (2).

If this code is run with the target process being the server or another client, remoteExecutedOwner produces the expected values. For example, client 3 calls client 4, client 4 will show "Receive from 3", and client 3 will show "Response from 4".

If this code is run with the target process being a headless client, when the sequence returns to the original caller, remoteExecutedOwner always reports 0. That is, if client 4 is a headless client, client 4 will show "Receive from 3", and client 3 will show "Response from 0".

The expected value is "Response from 4".


Operating System
Windows 7
Steps To Reproduce
  1. Set up a headless client, dedicated server, and client.
  1. Run the above code snippet from the debug console on the client to perform a round trip to the server, which produces the expected result of "Response from 2".
  1. Run the snippet again, but modified such that the "2" at the very end of the code is the clientOwner for the headless client. The result will be "Response from 0"
Additional Information

Permutations that I've tried that also duplicate the problem

  1. Running the server from the editor or as a dedicated server
  1. Connecting clients in order "headless then player" versus "player then headless"

Obviously, this problem prevents clients from knowing who is talking to them, which means that the clients cannot send any information back, clients cannot perform any bookkeeping related to a given headless client, and so on.

A workaround is obvious, which is to have the headless clients identify themselves in each remote call. Not only is that insecure, but it is also invasive to existing code which assumes that it could rely on an accurate value for remoteExecutedOwner.

Event Timeline

JB47394 created this task.May 3 2018, 4:03 PM
JB47394 changed Category from General to Scripting.May 4 2018, 1:41 PM