publicVariable

1.34

  

Click on the images for descriptions

Introduced in

Game:

Operation Flashpoint

Version:

1.34

Description

Description:

Broadcasts missionNamespace variable and its value to all computers. The data is sent consequently and reliably to all clients. Using publicVariable too frequently in a given period of time can cause other parts of the game to experience bandwidth problems.

Variables broadcast with publicVariable during a mission stay persistent for JIP (Join In Progress) clients. Such persistent variables are synced to the JIP client before the first batch of client side Event Scripts are ran.

The following Types of data are supported:

• Number

Since OFP version 1.34:

• Boolean
• Object
• Group

Since ArmA version 1.00:

• String
• Text

Since ArmA version 1.09:

• Array
• Code

Since Arma 3 version 1.26:

• Nothing (nil)

Limitations: Cannot use reserved names, such as "player" or "west" or "side", etc. It is also not possible to transfer references to entities which are local, like scripts, displays, or local objects. Team Member is also not supported.

Syntax

Syntax:

publicVariable varName

Parameters:

varName: String

Return Value:

Nothing

Examples

Example 1:

publicVariable "CTFscoreOne";

Example 2:

myPubVar = [123, "456", true]; publicVariable "myPubVar";

Additional Information

Multiplayer:

-

See also:

MP editing guideaddPublicVariableEventHandlerpublicVariableClientpublicVariableServer

Notes

Only post proven facts here. Report bugs on the feedback tracker. Use the talk page or the forums for discussions.
Add New Note | How To

Notes

Posted on 3 Aug, 2006 23:03

Hoz

This command broadcasts a variable to all clients, but as soon as you change the variable again, you have to use publicVariable again, as it does not automatically synchronise it.

Posted on 12 April, 2008

Icemotoboy

Be sure to place your variable name in quotation marks. This may sound awfully simple, but many times I have forgotten to do this, and it has resulted in no end of headaches for me.

Posted on 2 Feb, 2008

Dr_Eyeball

When initialising a public variable to handle JIP, you will usually first want to check if the public variable has already been (broadcast, received and) set locally. Otherwise you may inadvertantly overwrite the broadcast value with your default value.

To perform this check, use code similar to the following to first check that the variable is nil: if (isNil "PV_abc") then { // set the nil variable with a default value for server and both JIP & 'join at mission start' PV_abc = [7, 8, 9]; }; // else public variable has already been set due to a public variable broadcast.

Posted on 14 July, 2011

kju

To make Dr_Eyeball's note even more clear: For JIP players pV'ed variables are received and set BEFORE the init.sqf. So to avoid the received variables getting overwritten by variable initialization normally done in the init.sqf, you HAVE TO to use the 'if (isNil "PV_abc")' pattern. It says literally: "Only initialize value it has not yet been set. And in a JIP this may already been the cause due to publicVariable use".

Posted on 21 September, 2013

Killzone_Kid

To make Dr_Eyeball's and kju's notes even more clear, public variable is persistent. Once it has been broadcast it will be delivered to all clients, present and future. Therefore it is wise to check if the variable already exists on a client due to it being persistent before initialising its value.

Posted on 23 February, 2014

=MulleDK13

Just to clarify, when players JIP, they get the value of the variable from the last call to publicVariable, not the current value of the variable. Eg. with SomeVar = 5; publicVariable "SomeVar"; SomeVar = 10; Connecting players will receive 5, not the current value of 10.

Bottom Section

Posted on October 19, 2014 - 00:21 (UTC)

DreadedEntity

I'm pretty far down the notes list so I hope this doesn't get buried.

For clarity, after a variable has been publicVariable'd, scripts in all clients can use it as if it had been defined locally.
Variables that have been publicVariable'd do not need to be pre-defined on receiving clients. In fact, this could cause issues with JIP players overwriting a publicVariable value, as mentioned above. (tested in A3 1.32.127785)
Local variables cannot be publicVariable'd. (tested in A3 1.32.127785) (tested by having dedicated server publicVariable a local variable, then trying to hint it on client. Error was "Undefined variable in expression")