public setVariable and JIP

[tacticalnuggets]

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.

[Sickboy]

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.

[tacticalnuggets]

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.

[.kju [PvPscene]]

EDIT: removed nonsense

[Sickboy]

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.

[tacticalnuggets]

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.

[Sickboy]

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.

[tacticalnuggets]

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.

[Sickboy]

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.

[tacticalnuggets]

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