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.
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.
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.
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:
To operate in other namespaces you can also use with command and do the same.
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).
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.
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
or you can just go
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.
will set _myrank to “Private” if
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.
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