As per title the remoteExec command is no longer returning the JIP_ID string.
Potentially devastating for MP missions that use dynamic JIP_IDs especially if people are relying on the string returned from the command to clear items from the JIP que. {F27551}
Simple test
Start a dedicated server with a simple mission that has enableDebugConsole = 2 in its description.ext.
Join server with a client and in the debugConsole type
("hello" remoteExec ["systemchat",0,"myJipID"]) remoteexec ["hint",0];
And execute via server.
Further test (same as example zip)
//initServer.sqf
fnc_test = {
myJIP_ID = "hello" remoteExec [ "systemChat",0,"MyJIPID"];
if ( myJIP_ID == "" ) then {
myJIP_ID = "nothing";
};
publicVariable "myJIP_ID";
};
//initPlayerLocal.sqf
player addAction [ "RE", {
}];
"myJIP_ID" addPublicVariableEventHandler {
hint myJIP_ID;
};
As per description on https://community.bistudio.com/wiki/remoteExec
"Return Value: ... Otherwise this is an unique JIP ID..."
and
"JIP (Optional): ... If true, function generates a unique ID...."
Basically, JIP ID returned only when JIP param is true. TBH I don't remember it returning JIP string under any other condition.
Been a while since i test it last but i could of sworn it originally did.
Full quote..
Nil in case of error. String otherwise. If JIP is not requested this is an empty string. Otherwise this is an unique JIP ID.
No error so its not Nil.
String otherwise. <<<<<
If JIP is not requested this is an empty string. << i am requseting JIP
Otherwise this is an unique JIP ID. <<<< Contradicts first statement, but it is unique im supplying it ??
Quote from remote execution wiki page.
The JIP id is a unique key under which the JIP MP message is being stored in the JIP queue on the server. When you set isPersistent flag to true, the JIP id is auto-generated on the machine the remote execution was initiated. If you set the isPersistent flag to specific string, that string is considered to be the JIP id.
The auto-generated JIP is always unique. If the JIP is manually supplied, the content author needs to make sure it is unique, otherwise he/she will overwrite another MP msg that is currently stored in the queue under the JIP id.
If the JIP is manually supplied, the content author needs to make sure it is unique <<< Again is unique as i supplied it
Its crazy idea if only a generated ID is returned. Makes a whole lot more sense to return ANY ID if JIP is requested so you can look after your own que and delete any that become unneeded.
I agree this is not entirely polished and could do with a few tweaks. However when you provide your own string for JIP ID, this is basically your unique id, which you can use later to manage JIP queue, so returning it, would be just copying input to output (not the worst idea actually). Otherwise you can request random one, which you can then store and use to manage JIP queue.
Aye could do with changing.
This..
_veh = createVehicle ["B_MRAP_01_F", _somePos, [], 0, "CAN_COLLIDE"];
_veh setvariable ["JIP_ID", [_veh] remoteExec ["fnc_doSomething",0,format["veh_%1",netid _veh]]];
Makes a whole lot more sense to me than having to...
_veh = createVehicle ["B_MRAP_01_F", _somePos, [], 0, "CAN_COLLIDE"];
_JIP_ID = format["veh_%1",netid _veh];
_nul = [_veh] remoteExec ["fnc_doSomething",0,_JIP_ID];
_veh setVariable ["JIP_ID", _JIP_ID];
The custom JIP ID should be returned by the remoteExec/Call commands just as well in tomorrow DEV build, please check and report back.
Yep. Excellent, just put it through a little testing using the mission attached to the ticket and remotely removing from JIP que from debugConsole on client. All seems good. Thank you.