Let’s talk a bit more about namespaces. Namespaces in Arma are separate variable containers, where variables that are set in one namespace can only be read in the same namespace and cannot be read in another. There are 4 main namespaces in Arma:

  • missionNamespace
  • uiNamespace
  • profileNamespace
  • parsingNamespace

I have already explained the fist three in detail, so a little bit more information on parsingNamespace. This namespace is called “parsing” because it could be used by config parser during engine parsing of config.cpp or description.ext. Arma preprocessor has command called __EXEC that could be used to execute code during parsing phase. A variable set in parsingNamespace would then exist there until the game is restarted. Why would it exist from restart to restart? Because while description.ext is parsed every mission load, main config.cpp is parsed the moment you start Arma.

So, let’s say one would like to set some mission params in description.ext, for example:

__EXEC(missionParam1 = 123) __EXEC(missionParam2 = 456) __EXEC(missionParam3 = 789)

Then he can easily read them inside the mission with various scripts like this (saves on using missionConfigFile command and also pretty straight forward):

_param1 = parsingNamespace getVariable "missionParam1"; _param2 = parsingNamespace getVariable "missionParam2"; _param3 = parsingNamespace getVariable "missionParam3";

Other namespaces available are basically object namespaces. When you set a variable on an object, like obj1 setVariable [“obj1Var”, 123], it will only exist in this object namespace. But there is another namespace available, which is kinda psedo namespace – FSM namespace. Because there are 2 commands in existence, setFSMVariable and getFSMVariable, FSM script can also be used as variable container, as long as FSM script is running of course. And it is not to difficult no make FSM script to run indefinitely, all you need is not to include END state.

fsm_forever

When you start this FSM, you will get reference to the script which is used as anchor for set/get variable. The FSM itself will reach START state and just hang there forever.

fsmNamespace = execFSM "fsm_forever.fsm"; fsmNamespace setFSMVariable ["myFSMVar", 123]; fsmNamespace getFSMVariable "myFSMVar"; //123

And here comes quite interesting part. In the normal namespace you cannot read underscored (private) variables with getVariable but can read normal vars. In FSM it is the opposite, normal (not underscored) vars inside FSM are actually normal missionNamespace vars and you have no access to them via get/set FSMVariable but you can get and set underscored variable inside FSM.

So basically one can use FSM as alternative to missionNamespace for storing and retrieving data. How useful this could be? I’m not quite sure, but anything that is non standard is good when it comes to additional security.

Enjoy,
KK