Page MenuHomeFeedback Tracker

Receiver of remoteExec from headless client will see remoteExecutedOwner == 0
Closed, ResolvedPublic


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


Won't Fix
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

We encountered the same issue. Would be nice, if this gets fixed.

BIS_fnc_KK added a comment.EditedAug 26 2022, 11:15 PM

After looking into it, I can tell you that this is not a bug, this has been done deliberately in the code to have HC stand out for some reason. On top, changing this behaviour may break not only engine handling but existing missions where people might have used this peculiarity to identify HCs. In short is a won't fix. If you really need to have owner of the headless client, send it via param with callback.

BIS_fnc_KK removed BIS_fnc_KK as the assignee of this task.Aug 26 2022, 11:16 PM
BIS_fnc_KK closed this task as Resolved.
BIS_fnc_KK changed Resolution from Open to Won't Fix.
BIS_fnc_KK added a subscriber: BIS_fnc_KK.
Asmo added a subscriber: Asmo.Nov 12 2022, 10:45 AM

This has to be mentioned in biki page of remoteExecutedOwner command!