What IS missionNamespace and datatype Namespace?

[CarlGustaffa 4]

Using the command missionNamespace in a hint format, I'm only getting the datatype Namespace out. Many questions about it, bare with me:

1. What is known about this?

2. What should and shouldn't you be using it for?

3. Any known limitations (size, persistency, JIP)?

4. How does it differ from the old method of using a vars_array to store information?

There is also listed a whole range of new Data Types. Considering Namespace showing up with "Not available", how about those others in the same boat, like orientation and transformation?

[sickboy 13]

With ArmA 2 BI has split the namespaces for UI and misison.

missionNameSpace is basically the access to the scripting space you work in by default.

You can access globalVariables with setVariable and getVariable.

While you can execute lines of code, by using "with".

MyGlobal = [1, 2, 3];
publicVariable "MyGlobal";
_a = MyGlobal;

or like:

missionNameSpace setVariable ["MyGlobal", [1, 2, 3]];
publicVariable "MyGlobal";
_a = missionNameSpace getVariable "MyGlobal";

All one and the same thing, and can be freely mixed.

It is especially useful to replace dynamic variable assignments like

call compile format["%1 = _something", _variableName];

->

missionNameSpace setVariable [_variableName, _something];

It is said to be a lot quicker than call compile.

"with" example (though never used it)

with missionNameSpace do {
   myGlobalVariable = true;
};

Edited May 13, 2010 by Sickboy

[Defunkt 431]

Bit perturbed by all this as I have (it seems unfortunately) come to rely quite heavily on Call Compile "<Some Code>", perhaps MissionNamespace may yet come to the rescue but thus far the point is lost on me.

Call-Compile-Format does two things for me;

1) It allows me to have an object reference to a re-spawned player re-evaluated. When the editor-named object Unit1 is killed for an executing procedure the reference either becomes null or points to the corpse (I am unclear which) and only Call Compile "_unit = Unit1"; yields a new reference to the since re-spawned object.

2) It allows me to construct the right-side of an assignment dynamically, for example Call Compile Format ["_unit = Unit%1", _unit_ndx];

Am I missing something? Can anyone suggest how MissionNamespace might be useful to me? The only purpose I can see is the ability to dynamically construct/select the left-side of an assignment and a reason for doing so eludes me.

[sickboy 13]

Bit perturbed by all this as I have (it seems unfortunately) come to rely quite heavily on Call Compile "<Some Code>", perhaps MissionNamespace may yet come to the rescue but thus far the point is lost on me.

Call-Compile-Format does two things for me;

1) It allows me to have an object reference to a re-spawned player re-evaluated. When the editor-named object Unit1 is killed for an executing procedure the reference either becomes null or points to the corpse (I am unclear which) and only Call Compile "_unit = Unit1"; yields a new reference to the since re-spawned object.

2) It allows me to construct the right-side of an assignment dynamically, for example Call Compile Format ["_unit = Unit%1", _unit_ndx];

Am I missing something? Can anyone suggest how MissionNamespace might be useful to me? The only purpose I can see is the ability to dynamically construct/select the left-side of an assignment and a reason for doing so eludes me.

1) no need for call compile format there, _unit = unit1; is sufficient. There is no difference except that your method is slower because of call compile.

Also, just like 'player' variable always aims to the current player unit, unit1 (if editor named) should too.

2) There is no access to the local variables, so in your case, you can't use the missionNamespace.

The missionNamespace setVariable method is preferred to set global dynamic variables because it simply is faster than call compile.

[xeno 230]

It is said to be a lot quicker than call compile.

missionNamespace setVariable ["my_global_var", 1]

is a little bit slower than

my_global_var = 1

But

missionNamespace setVariable [format ["unit%1", _i], _whatever]

is 4 to 5 times faster (at least during my tests) than

call compile format ["unit%1 = _whatever", _i]

Specially if you have a lot of loops with call compile formats and global variables it helps a lot.

As an example, I'm using it to create global vars at mission start from paramsArray (class Params in description.ext) on the fly:

for "_i" from 0 to (count paramsArray - 1) do {
   missionNamespace setVariable [configName ((missionConfigFile >> "Params") select _i), paramsArray select _i];
};

Fast and nice way if you have about 60 params in description.ext.

As another example...

norrins revive uses many many call compile formats (probably responsible for some connection errors with revive), many of them run in a loop iterating over all revive units.

The version in Dom is completely rewritten to use missionNamespace instead (beside some other fixed errors revive had :))

Xeno

Edited May 14, 2010 by Xeno

[CarlGustaffa 4]

Thanks, this will prove helpful.

[galzohar 31]

_unit=unit1 will make the _unit variable to continue pointing at the dead unit after unit1 respawns. Using call compile format will refer to the newly respawned unit instead, and unfortunately I haven't found a prettier way to keep track of a respawning unit.

[sickboy 13]

Hmm, it shouldn't require you to use call compile format?

_unit = unit1;

or

call compile "_unit = unit1"; // _unit = call compile "unit1";
// format["_unit = unit%1",_i]; 

is equal.

The essence is that you update the local _unit variable to point to the new object now residing in the global variable unit1.

[Defunkt 431]

I didn't look much further after arriving at the Call Compile solution but my testing found that Unit1 referred to the object as it existed when the procedure began execution and never ceased to refer to the same object even once dead. Pretty sure after death _unit = Unit1 will still reference the corpse but Call/Compile works because the global unit name is re-evaluated as part of setting up the environment afresh (which I guess is why Call/Compile is costly).

Edited May 15, 2010 by Defunkt

[xeno 230]

A reference to a unit (or better object) has nothing to do with call compile.

Once the player respawns the var name is transfered over to the new player object (using selectPlayer is an exception).

So after respawn the var name references the new player unit and not the dead body anymore (while other variables may still point to the dead body when they don't get updated).

But yes, you have to update variables and call compile is not needed for it :)

Xeno

Edited May 15, 2010 by Xeno

[galzohar 31]

Except if the variable name is a string variable in itself (so that the script can work for unit1, unit2 etc and not just unit1), I still don't see a way to work around the call compile. As far as I can tell, if you have a pointer to the unit itself you still need to get the vehicleVarName of the unit and use call compile if you want to keep getting the updated variable value rather than the dead unit.

[sickboy 13]

In the string case, at least missionNameSpace is recommended over call compile.

[xeno 230]

Once again.

You don't need any call compile format bla for this.

To get the string name of a unit simply use str(unit) if you really need it, though knowing how the units are named there is no need for it.

(Edit: and even using str(unit) with missionNamespace is much faster than call compile)

Try the following:

Place a unit in the editor, give it the var name unit1.

Now log the following into the rpt:

diag_log (missionNamespace getVariable "unit1")

diag_log (missionNamespace getVariable format ["unit%1",1])

The result is unit1, means the object reference.

No call compile needed for that.

Xeno

Edited May 15, 2010 by Xeno

[Defunkt 431]

Excellent, thanks, I hadn't clocked the use of GetVariable with MissionNamespace, time to revise all my Call/Compiles...

[galzohar 31]

OK, I think I understand it now. Thanks.