In Part 1 I talked about private variables. This part will be about 2 kinds of public variables, public local and public local special. Local is because these variables are only available on the machine that runs the script, public is because once defined these variable could be accessed and modified from anywhere as long as this ‘anywhere’ is on the same machine.

Public local variables

You can use standard alphanumeric characters just like with private variables to create your public variable. However you cannot start public variable name with underscore (obviously, as it will be interpreted as private variable) and you cannot start with a number. 123variable is illegal name, variable123 is fine. Also avoid naming your public variables and functions with the same names as ArmA commands or existing BIS library functions. Even though in ArmA 2 it is still possible to mess things up like in the example below, in ArmA 3 this will not be possible anymore for security reasons and the engine will complain and throw an error.

false = true; call = "It's true!"; if (false) then {hint call}; //"It's true!"

If you just go myvar = “somevar”; the myvar variable will initialise in a mission namespace by default and will exist in it until the mission is over and you are back in the lobby. To destroy public local variable while in session you need to assign nil to it, myvar = nil;

When creating a public function you are essentially creating a public local variable and assigning code to it. Because it can be accessed from any script you are running on the same machine it makes it a good choice for when you need to split your project in modules. So instead of creating new script file for new functionality, you can just create another function.

Coming back to namespace. If with private variables the existence of the variable was defined by the scope it was defined in, with public local variables it is the namespace. There are 4 namespaces available for you to fiddle with. Think of them as code partitions.

missionNamespace

Mission namespace is the main default partition that exists from the moment you load the mission to moment the current mission ends. All variables defined in mission namespace will cease to exist when you are back in the lobby. If you want your variables exist longer you can use different namespaces.

uiNamespace and parsingNamespace

These are 2 different namespaces which have similar scope. Public local variables defined in these namespaces will exist from the moment you define them to the moment you shut down ArmA program.

profileNamespace

This namespace will store your variable for a very long time as long as you are using the same gaming profile in game. If you create different profile for yourself or switch to an alternative one, the public local variables you had in the other profile will obviously not exist in the new one. The saving of the profile namespace variables is done automatically but you can force it by using saveProfileNamespace command.

Now, as mentioned before, for the mission namespace you can just create public local variable by simply myvar = “somevar”; because it is default namespace. This means that by default everything you do will be as if you were going:

with missionNamespace do { myvar = "somevar"; }; //is the same as just typing myvar = "somevar";

To operate in other namespaces you can also use with command and do the same.

with uiNamespace do {}; with parsingNamespace do {}; with profileNamespace do {};

Note that your public local variable will not be available in other namespaces. Even if you define the variable with the same name in other namespaces they will not affect each other. It is almost like private variable made private in their scopes. This is different with public local special variables (about it later).

myvar = 123; with uiNamespace do { hint str (isNil "myvar"); //true myvar = 456; }; with profileNamespace do { hint str (isNil "myvar"); //true myvar = 789; }; with uiNamespace do { hint str myvar; //456 }; with profileNamespace do { hint str myvar; //789 }; hint str myvar; //123

You can also set public local variables using setVariable command and read their value with getVariable command. When you use these commands you need to attach them to something, like a namespace for example.

missionNamespace setVariable ["tro","lolol"]; //is the same as with missionNamespace do { tro = "lolol"; }; //and is the same as tro = "lolol";

This means that if you want to read the value of a specific public local variable dynamically depending on the name instead of doing this

var1 = 1; var2 = 2; for "_i" from 1 to 2 do { private "_myvar"; //notice how _myvar needs to be predefined call compile format ["_myvar = var%1;", _i]; diag_log _myvar; };

or you can just go

var1 = 1; var2 = 2; for "_i" from 1 to 2 do { diag_log (missionNamespace getVariable (format ["var%1", _i])); };

You can obviously do this with other namespaces. Few things to mention about setVariable and getVariable commands. The setVariable command will take 3rd argument to indicate whether or not the variable should be global. I will talk about it later, but for now namespace public variables can only be local so it will produce error if you try to make them global. The getVariable command has also alternative syntax where you can assign default value to it in case the variable is undefined when you first use it.

_myrank = profileNamespace getVariable ["MY_RANK", "Private"];

will set _myrank to “Private” if

with profileNamespace do { hint str (isNil "MY_RANK"); //true };

Apart from namespaces you can also attach public variables to objects, vehicles, controls, groups, tasks, locations, team members and sites. There are limitations which will be discussed in the next part. To undefine public local variable using setVariable command use nil as value.

profileNamespace setVariable ["MY_RANK", nil];

Public local special variables

These variables have special values assigned to them by the engine and exist in all namespaces but they are still local to the machine they are on. For example time on one machine can be different from the time on other clients on the network. The player variable is different on every client and on the dedicated server it is simply null. Avoid using these names for your own variables. These variables are also highlighted differently in my syntax highlighter.

true false time enemy friendly sideLogic sideUnknown sideFriendly sideEnemy playerSide east west civilian resistance independent opfor blufor nil objNull grpNull netObjNull locationNull taskNull controlNull displayNull teamMemberNull player

This is it for the Part 2. You my also want to read about case sensitivity in regards to variables. More to come in the Part 3.

Enjoy,
KK