publicVariable – Talk

"No guarantee" isn't quite right. PV sends stuff out on via TCP, which uses a "guaranteed delivery" packets (as opposed to UDP, which is what most of the MP traffic uses).
The complaints that "it doesn't always work" in multiplayer usually arise from improper or abusive MP coding.
In OFP, mission start is the synchronisation point for MP games. So PVs before mission start are not guaranteed to reach all clients. After that, the clients try to stay synchronized, and that means they make sure they receive the TCP packets in order. Any flood of TCP packets (such as a flurry of PVs, or a bunch of createvehicles) will likely cause Desync (=Backlog of TCP) in an internet environment and hence trouble. Finally, someone with a crappy connection can also cause desynchronization and weird MP effects. But if PublicVariable isn't working in these cases, you have bigger problems than just the variable puking.Dinger 13:09, 1 September 2006 (CEST)

I agree "No guarantee" isn't right. The explanation is however not quite correct. No TCP protocol is used, "reliability" is implemented purelt in UDP using handshaking. Other than that, the explanation of what happens when publicVariable is abuse is roughly correct, just disregard the TCP and imagine "guranteed message send using UDP" instead. --Suma 14:46, 1 September 2006 (CEST)

Come on now. There is no TCP involved OFP: Res. I suppose it's possible they're sent with the guarantee system, they are however OFTEN getting lost. But this is most likely due to the at times poor performance of the guaranteed delivery system. Especially during packetloss. I believe using 'reliable' in the same sentence as pV is very misleading. --Salisan 15:15, 1 September 2006 (CEST)

It has never been my intention to drag OFP through the mud with this pV thing. So please forgive me if I come off as doing so. However, I don't think of myself as an 'abusive' coder nor do I have unreliable equipment. I have at most time used pV for simple tasks and I believe that the UDP handshake works well in most situations. However, I would have to argue that the term "guaranteed" is loose and in some cases misleading itself. CoC_NS was closest to guaranteed as possible. However, it was basically a top-level net-code management system which was designed to ensure another layer of guaranteed delivery. That, IMO is a true "guaranteed" system. I thought pV was fine as is. As I said, it worked for most things and in some situations but 'guaranteed? ... I don't know about that. Did this handshake system envision the amount of boundaries we'd be pushing this engine to? --CrashDome 16:08, 1 September 2006 (CEST)

Ah, okay. That explains it -- so that's why when you have packet disruptions, you often see the same "Guaranteed UDP" message come across more than once (packets are waylaid, retransmit sent, packets resent). As for the boundaries, well, shucks, I look at some of the stuff Bn880 put into CoC_NS, and have wondered "who the heck would ever need to use this?"; then later, I'd find a need. In any case, PV is only part of the "guaranteed UDP" messages sent across, and my point was, when these start being dropped, or start stacking up, many other elements of the game state are failing too. If PV is getting dropped, but everything else is working fine, I suspect something else is the problem Dinger 17:36, 1 September 2006 (CEST)

Am I right in reading this in that arrays (of in this case strings ) are NOT supported ?

Semantics of PV used with objects

What exactly is the effect of publicVariable used in conjunction with an object? I'm curious if publicVariable broadcasts object data like position and direction reliably, especially for objects that derive from the Static class, where setPos et al don't broadcast data across the net. -- Manny 21:23, 8 May 2007 (CEST)

PV does not public the object, it only publics the variable. E.g. if you execute mySoldier = player; publicVariable "mySoldier" on one client, mySoldier will "contain" the player of this client on all other clients and the server as well. --raedor 15:09, 9 May 2007 (CEST)

No need to send variables again when a client joins

It is not necessary to broadcast all variables again when a player joins in progress.

This is what i found out: (arma2 1.05)

Code issued on the server:

var = 1337; PublicVariable "var";

=> Client got variable at mission start

Code issued on the server:

var = 1337; // What happens without PublicVariable

=> Client does not get the variable at mission start

Code issued on the server:

var = 1337 PublicVariable "var"; var = 1339;

=> Client gets var=1337

Yes. JIP get all PV automatically. See the note of Dr.Eyeball how to handle that.

It should be made more clear in the main page about pV. --.kju 11:27, 29 December 2009 (CET)

Removing a note?

Is the note at the bottom (made on October 19 2014) really necessary?

It basically just explains what the wiki page is there to explain (and already does as far as I can see). I don't know if there's a policy on removing notes though, plus I don't want to just go ahead and do it without asking first.

I will say nothing if someone will take all the notes and make a better description out of it then delete them :) --KK