Jump to content
Sign in to follow this  
tacticalnuggets

public setVariable and JIP

Recommended Posts

I've heard some information that public setVariable is not working correctly for JIP. Is this true and if so, how exactly is the bug appearing?

For instance:

- JIP trying to getVariable from a variable that was broadcasted from client

- JIP trying to getvariable from a variable that was broadcasted from server

- Client trying to getVariable from a variable that was broadcasted from JIPs

All important info. Also, is this related to JIPs failing to register on clients that are already connected to server (something about JIP being to far away from client player ingame).

My suspicion is if the JIP person fails to register on the client, then the client will not re-broadcast its public setVariables automatically for the JIP. And because the JIP person failed to register, the client can not also obviously get the JIP persons data and public setVariables. The server in this mix, however, does not have any issues, and the JIP client therefor does not have any issues getting public setVariables done by the server.

Please correct me where I am wrong.

Share this post


Link to post
Share on other sites

During JIP the server broadcasts the existing variables, not clients.

AFAIK PV and setVar both are reliable commands.

If issues are being experienced, I think it's an implementation problem, perhaps a testing problem.

Share this post


Link to post
Share on other sites
During JIP the server broadcasts the existing variables, not clients.

AFAIK PV and setVar both are reliable commands.

If issues are being experienced, I think it's an implementation problem, perhaps a testing problem.

These were reported by jaynus, and he described the issue as a result of JIP distance from another player.

Share this post


Link to post
Share on other sites

EDIT: removed nonsense

Edited by .kju [PvPscene]

Share this post


Link to post
Share on other sites
These were reported by jaynus, and he described the issue as a result of JIP distance from another player.

I don't see how distance can be relevant. All network objects in the game are synchronized to all machines, but the accuracy of position and state is lower at distance because of reduced simulation.

That should have no bearing on the initial sync at join, nor should it interfeir with setVariable at all.

Perhaps you can link to the report you're referring at.

Edited by Sickboy

Share this post


Link to post
Share on other sites
There seems to one bug when you setVar public on an entity that was created locally first and then pV'ed:

//server
MyLogic = "Logic" createVehicleLocal [1,1,1];
publicVariable "MyLogic";

MyLogic setVariable["MyVar",1,true];

Now for a JIP MyLogic exists, but the JIP instance did not get setVars of it.

This is because the logic is local and your broadcasting the reference of it. A global object has a sort of "address" that is the same on all the machines and exists. Despite the fact you public variable this reference successfully, it is a reference to nothing on that machine because the logic is local to the server.

Share this post


Link to post
Share on other sites
This is because the logic is local and your broadcasting the reference of it. A global object has a sort of "address" that is the same on all the machines and exists. Despite the fact you public variable this reference successfully, it is a reference to nothing on that machine because the logic is local to the server.
Correct. Btw, a logic is always "local" to the server but exists on all machines, at least when placed in the editor.

In the createVehicleLocal case, the object simply only exists on that machine alone.

PVing it will result in null object reference on all other machines.

Share this post


Link to post
Share on other sites

here are the links sickboy. I have no issues with setVariable and JIP, but they are all on done on the server for me, so my experience is a bit inconclusive.

http://dev-heaven.net/issues/18228

http://dev-heaven.net/issues/19213

http://dev-heaven.net/issues/21979

forgot this as well http://pastebin.com/7wZrqj6n I asked VM when this conversation took place but i have not gotten a reply back yet.

Edited by tacticalnuggets

Share this post


Link to post
Share on other sites

Thanks! As said, initial variable state is maintained and synced by the server to the JIP client, not sent by other clients - would make for some funny results - some clients disconnect and half of the variables would not be accessible by people joining aftwards :P

---------- Post added at 12:33 ---------- Previous post was at 12:29 ----------

I've checked the tickets, they seem to be mostly about units not appearing in allUnits/playableUnits arrays etc.

And I see few words about variables supposedly not synced. I am not sure this is really the case.

A repro mission showing the variables not syncing is missing too.

Share this post


Link to post
Share on other sites
Thanks! As said, initial variable state is maintained and synced by the server to the JIP client, not sent by other clients - would make for some funny results - some clients disconnect and half of the variables would not be accessible by people joining aftwards :P

---------- Post added at 12:33 ---------- Previous post was at 12:29 ----------

I've checked the tickets, they seem to be mostly about units not appearing in allUnits/playableUnits arrays etc.

And I see few words about variables supposedly not synced. I am not sure this is really the case.

A repro mission showing the variables not syncing is missing too.

[9:53:23 AM] jaynus: All of that is still not as bad as the setVariable issues with JIPs though :/

[9:53:31 AM] jaynus: You can have players in your player list that still dont propigate their variables to JIPs

[9:53:39 AM] jaynus: hence why we also had to do a bunch of persistant setVariables for random shit

[9:53:49 AM] jaynus: cause literally just randomly, in the A2 engine, the setVariable just "wont" propigate to a JIP

[9:54:17 AM] ViperMaul: To reduce net traffic, Have you experimented with this from XENO

http://dev-heaven.net/docs/cba/files/network/fnc_setVarNet-sqf.html

[9:54:22 AM] jaynus: yah

[9:54:28 AM | Edited 9:54:33 AM] jaynus: thats what broke ACRE 1.3 / 1.3.1

[9:54:40 AM] jaynus: because of...

[9:54:45 AM] jaynus: [9:54 AM] jaynus:

<<< cause literally just randomly, in the A2 engine, the setVariable just "wont" propigate to a JIP

[9:54:51 AM] jaynus: So for example, inside acre, we do

[9:55:05 AM] jaynus: player setVariable ["acre_sys_core_ts3id", 12345, true];

[9:55:22 AM] jaynus: when we switched it to [player, "acre_sys_core_Ts3id", 12345] call CBA_fnc_setVarNet;

[9:55:24 AM | Edited 9:55:27 AM] jaynus: it broke

[9:55:40 AM] jaynus: Because in all the scenarios that object variables didnt propigate for JIPs correctly, setVarNet never resent it

[9:55:43 AM] jaynus: so JIPs are basically fucked

[9:55:59 AM] jaynus: which made us move back to enforced setvariable[true,true] calls

[9:56:03 AM] jaynus: forcing network propigation every single call

[9:56:14 AM] jaynus: General symptom being:

[9:56:20 AM] jaynus: If you have JIPs, setVarNet is fucked and dont touch it

[9:57:02 AM] ViperMaul: Hmm...

[9:57:10 AM] jaynus: Basically what setVarNet does is

[9:57:22 AM] ViperMaul: It makes me wonder how long a JIP remains classified as a JIP player.

[9:57:25 AM] ViperMaul: You know what I mean?

[9:57:36 AM] jaynus: it checks *locally on your client* if you've already set that variable on the object. if the variables dont match, it propigates it again (setvariable true true) otherwise, it doesnt.

[9:57:47 AM] jaynus: Well, A2 doenst do persistant updating so what you run into is.

[9:57:47 AM] ViperMaul: a JIP player is only a JIP player for the first X seconds right?

[9:58:02 AM] jaynus: 1. Player A is already in game, does setVariable "foo" on themselves

[9:58:11 AM] jaynus: 2. Player B JIPs, and because of random A2 bug, does not propigate the "foo" variable for A

[9:58:26 AM] jaynus: 3. Player A calls "setVarNet" again on "foo", but never does a netowrk propigation because player A sees the variable as already set

[9:58:42 AM] jaynus: End result: PLayer B never gets the variable "foo" because it didnt sync correctly, and A never re-sent it after B joined

[9:59:00 AM] jaynus: Basically a JIP player is a player that JIPed

[9:59:03 AM] jaynus: theres no "sync time on it"

[9:59:13 AM] jaynus: Theres so many bugs surrounded JIPing, that you need to consider a JIP player throughout *everything*

[9:59:32 AM] jaynus: basically, *ALL* actions that were performed prior to a player JIPing, need to be considered to resync on the JIP

[9:59:51 AM] jaynus: Prime examples: building destruction, variable syncing, distant objects disappearing, etc

[10:00:28 AM | Edited 10:00:39 AM] ViperMaul: Can we put in a hack for the "setVarNet" that check for new JIPers and if new then send one normal setVar [true,true]?

[10:00:42 AM] jaynus: Your doubling net traffic for that basically

[10:00:55 AM] jaynus: Because then you'll need to send "Yo player b, did you already get X value for player A?"

[10:01:02 AM] jaynus: "yo player A, NOPE, send it"

[10:01:03 AM] ViperMaul: But you are doing it any way by using setVar[true,true] every 10sec right?

[10:01:13 AM] jaynus: correct

[10:01:14 AM] jaynus: so instead of the above

[10:01:17 AM] jaynus: its just

[10:01:22 AM] jaynus: "PLAYER A SETTING VARIABLE AGAIN K THX"

[10:01:22 AM] jaynus: every 10 seconds

[10:03:06 AM] jaynus: That all make sense?

[10:03:16 AM] jaynus: Basically once your needing to "verify" a sync, its pointless

[10:03:20 AM] jaynus: may as well just force a resync

[10:03:45 AM] jaynus: Then you have the issue of the fact you cant identify a JIP really from remote clients, only the local client knows hes a JIP

[10:03:59 AM] jaynus: so the JIP needs to send "HI IM A JIP"

[10:04:03 AM] jaynus: then you get a massive sync flood

[10:04:13 AM] jaynus: (already exhibitied in red/yellow chains on JIP > 30 players)

[10:04:41 AM] ViperMaul: Exactly, I just read your last msg after typing the following....

This is what I think to be the important question. Perhaps i'm just misreading him, but he is saying public setVariables are not reaching jips in certain situations.

Share this post


Link to post
Share on other sites

JIP clients sometimes not properly initializing is a known problem, but setVariables not working reliably would be new to me.

I'll believe it when I see a repro :)

Share this post


Link to post
Share on other sites

I've just checked it now with the latest beta.

I connected with one client on a dedi server, setPosed the player 10 Km away from the spawn point. Then used a setVariable PV on the player object (debug console).

After that I connected with a second client on the server. Once ingame I checked the setVar of the first client (like already written, the first client was 10 Km away from the spawn point) and the variable stored in the first client object was perfectly available on the JIP client, like it should be.

Also allUnits and playableUnits had references to the JIP client on the first client (the same was true on the second client, but because of the old "players not initialized correctly" bug, available since ArmA 1 :), this may not always be the case).

I've made enough MP stuff in the last 5 years and never had any problems with PVs or setVar PVs, no matter if it were 10 players or 60 players (except when I made an error myself :p)

Xeno

Share this post


Link to post
Share on other sites

I was actually talking with Dwarden who refered me to kju on this one. I use setVariable in 3 cases in bStats (where I also use the broadcast parameter).

1. setVariable on vehicles for vehicle information

2. setVariable on players for player id information

3. setVariable on dynamically created gamelogic with all players score

There are not problems with 1 & 2. However, 3 caused JIP players to not sync with everyone else. Below I will post my gamelogic creation script, and the sync scripts I had to use to make the clients sync. I actually wouldn't have noticed it unless I needed players to access the variables to fill the scoreboard.

// Portion of initServer.sqf

if ((isNil ("SPY_GAMELOGIC"))) then {

_center = createCenter sideLogic;
_group = createGroup _center;
SPY_GAMELOGIC = _group createUnit ["LOGIC", [0, 0, 0], [], 0, "NONE"];
publicVariable "SPY_GAMELOGIC";

};

// updateRequest.sqf

{ 

{

	if ((getPlayerUID _x != "")) then {

		_null = [[], "_null = _this spawn SPY_updateSend;", getPlayerUID _x] spawn JDAM_mpCB;

	};

} forEach units _x;

} forEach allGroups;

// updateSend.sqf

_uid = (getPlayerUID player);

// FORMAT PLAYER SCORE VARIABLE NAME
_playerScoreVar = (format ["SPY_bStats_%1", _uid]);

// REBROADCAST PLAYER SCORE
SPY_GAMELOGIC setVariable [_playerScoreVar, (SPY_GAMELOGIC getVariable _playerScoreVar), true];

// REBROADCAST PLAYER ID
player setVariable ["SPY_PLAYER_ID", (player getVariable "SPY_PLAYER_ID"), true];

I plan on making an example mission for CIT when I get some free time.

Edited by Spyder001

Share this post


Link to post
Share on other sites

What were the problem symptoms before implementing this workaround?

Also, if im reading it correctly, you are sending the same updateSend request for every connected player, this seems to be overkill - can just send the command once and have it executed for every player - no need to run over allGroups/units?

(on a side note, you don't need to send the spawn bit as a string of code, instead you could trigger an event which triggers the code on all player machines. More a matter of optimization :))

It seems the JIP client has access to the script-created logic, and other variables that are set on it, it would seem weird if the player scores would fail, though perhaps it really is related to client set variables and the synchronization of those values to JIP, and distance, but it doesn't match with how I thought the synchronization works.

It would be great to have a clean repro of the issue, with only the minimal objects and scripts involved to reproduce the issue.

(Actually, Xeno's mission would seem to test this and shows the opposite - or well, except the script-created logic :))

Edited by Sickboy

Share this post


Link to post
Share on other sites
What were the problem symptoms before implementing this workaround?

The JIP players could not access the data, it was never broadcast to them. They would only see themselves on the scoreboard.

Also, if im reading it correctly, you are sending the same updateSend request for every connected player, this seems to be overkill - can just send the command once and have it executed for every player - no need to run over allGroups/units?

It sends only to the UID of _x (allGroups/units). I could only send this to the server, and have the server collect and send the information. But it's the same size task, just not distributed on the clients.

Share this post


Link to post
Share on other sites
The JIP players could not access the data, it was never broadcast to them. They would only see themselves on the scoreboard.
Cheers, hopefully the repro will tell the tale.
It sends only to the UID of _x (allGroups/units). I could only send this to the server, and have the server collect and send the information. But it's the same size task, just not distributed on the clients.
When sending data over the network with publicVariable or setVehicleInit, the data is sent to every client.

So if say 20 players are connected, the command is sent 20 times, once for each player, and 20 times received by each player.

Instead, the command could be sent just once, as it is received by all 20 players anyway, and then executed by all the players :)

Still I would argue that since all traffic has to go through the server anyway, having the server alone send the various player scores would seem more efficient (no need to send the command to every player, and no need to have all the players send data to the server it already has anyway). It would also be able to handle the scores of disconnected players, if that has value :)

Just some thoughts, hopefully of some use.

Edited by Sickboy

Share this post


Link to post
Share on other sites

Its possible that certain objects are bugged while some are not. I think that the way synchronization is coded may require detection of a new presence on the machine that pv'd it. Basically speaking, PV's could be stored on the machine it was used locally. Then when a new machine enters that pool, its up to each individual machine to detect it and re-broadcast it. With this set up desync would certainly be more probable! Just as we see desync always being an annoying issue in a2. Perhaps certain informations act just like public variables in this manner, and cause desync when a high player number is reached.

Now, make sure you read what i'm about to say: What if since the addition of public variable eventhandlers this was fixed for regular PV, but the setVariable PV never got fixed for all the objects?

Share this post


Link to post
Share on other sites

We need a repro with demo mission.

Share this post


Link to post
Share on other sites
Thanks! As said, initial variable state is maintained and synced by the server to the JIP client, not sent by other clients - would make for some funny results - some clients disconnect and half of the variables would not be accessible by people joining aftwards

This actually is exactly the case we found in ACRE. All 3 of the tickets are related, and cause funky issues between the three. For example, a player that does not appear in playableUnits because of the range bug, will then never actually sync types of variables (even if they come within range). You need to re-set the variable.

That was the initial bug I found with ACRE, that resulted in my tickets about variable syncing (and also my rejected change in CBA).

We ran into this when I specifically changed our ts3id propagation from being every 10 seconds setVar, to setVarNet. Very funky results occured. That's when I submitted for the CBA change to have an optional timer on setVarNet, and it was rejected - so we have our own setVar wrapper in ACRE now.

Edited by jaynus

Share this post


Link to post
Share on other sites

The patch for CBA setVarNet simply doesnt make sense, because the setVarNet function was specifically designed to only propagate values over the network, if the local value is not equal to the target value. It's like trying to use a hammer to unmount a screw.

It's nice those tickets are all related but none of them contain a clean repro mission that show the exact problem. So nobody can determine if the issue is caused by a million addons or mission scripts, delays/timing, or whatever, or if it truelly is a genuine / clean bug.

If the problem only occurs when the JIP player fails to initialize properly (old bug goes back to A1), then I would suggest we try to get a more reliable repro for that specific bug, and get more attention from it by BIS, so that it hopefully gets fixed, and in turn automatically fixing the JIP setVariable issue.

IMO as workaround it would be better to disconnect (to lobby) players experiencing the JIP bug, than to send data over and over and over, just to workaround the JIP bug problem. As god knows what other problems it causes, beyond setVars not synced.

I suppose all that really needs is a reliable way to determine if the client is in this broken state.

Either from server-side, or from the client-side, where I think server-side might be best, if able to reliably determine the state.

Edited by Sickboy

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×