missionNameSpace

[iceman77 19]

If I set a variable to the missionNameSpace in a client script, is it accessible in a server side script? Something is telling me this is one of the reasons namespaces and set / get - variable are so great. On the other hand, for myself, it goes against MP logic. I don't have too much experience using namespaces and set/get - variable. Is this legit? Thanks.

Client Script

if (isDedicated) exitWith {};
waitUntil {!(isNull player)}:

// ----- Client code

missionNameSpace setvariable ["MNSVARIABLE","SOMETHING1"];

Server Script

if (!(isServer)) exitWith {};

_myValue = missionNameSpace getvariable ["MNSVARIABLE",""];

switch _myValue do {
case "SOMETHING1":{/* CODE */};
case "SOMETHING2":{/* CODE */};
case "SOMETHING3":{/* CODE */};	
default {/* CODE */};
};

[dreadedentity 278]

No, setVariable only supports the third parameter (public) if it's attached to an object. If you want to use any of the namespaces or actually anything other than an object, you have to add the "public" part yourself. I tried... lol

On the server

"GLOBAL_setVariable" addPublicVariableEventHandler
{
missionNamespace setVariable (_this select 1);
};

On client

GLOBAL_setVariable = ["MY_VARIABLE", value];
publicVariable "GLOBAL_setVariable";

Also, your syntax for getVariable is incorrect, it should be:

_myValue = missionNamespace getVariable "MY_VARIABLE";

:p

[Heeeere's johnny! 51]

Also, your syntax for getVariable is incorrect, it should be:

_myValue = missionNamespace getVariable "MY_VARIABLE";

:p

I disagree.

_myValue = missionNameSpace getvariable ["MNSVARIABLE",""];

is correct as the first value is the variable you want to get and the second one is the default value returned if the variable does not exist. See the Alternative Syntax of that very BIKI article you linked yourself. :p

[dreadedentity 278]

I disagree.

missionNamespace getVariable ["MY_VARIABLE", ""]

is correct as the first value is the variable you want to get and the second one is the default value returned if the variable does not exist. See the Alternative Syntax of that very BIKI article you linked yourself. :p

I see. I hadn't known about that until today, that's very useful. I've been having to check if it's nil with:

if (isNil {missionNamespace getVariable "MY_VARIABLE"}) then
{
_myVar = default_value;
}else
{
_myVar = missionNamespace getVariable "MY_VARIABLE";
};

[iceman77 19]

Thanks guys. However, the syntax for getvariable is correct. It's an array variant that sets a default value of the variable if the variable is nil in the name space.

---------- Post added at 23:48 ---------- Previous post was at 23:24 ----------

Okay so still good old PVs... but why the heck doesn't namespaces support public parameter with setVariable?

[dreadedentity 278]

Could be the way the game was coded would mean huge modifications to base files to get it to work, or maybe the developers just thought it shouldn't be like that lol

[Heeeere's johnny! 51]

To my point of view, the missionNamespace is just another way to store (clientside) global variables as according to the BIKI, this

missionNamespace setVariable ["YourString",3];

is the same as this

YourString = 3;

So I'm wondering if there's any deeper sense in this than being able to create global variables using format'ed names without having to do this call compile "some code" stuff.

for "_i" from 0 to 10 do
{
   missionNamespace setVariable [format ["myNumber_%1", _i], _i];

   //rather than
   call compile format ["myNumber_%1 = %1;", _i];
};

Especially since "missionNamespace" was introduced in ArmA 2 while "publicVariable" already existed in OFP.

[cuel 25]

Yeah that works. I used it last night actually to get 20 named civvies to do stuff in a mission.

Furthermore using that method is a lot faster than call compile.

[dreadedentity 278]

To my point of view, the missionNamespace is just another way to store (clientside) global variables as according to the BIKI

...

Especially since "missionNamespace" was introduced in ArmA 2 while "publicVariable" already existed in OFP.

Exactly, it's to perfect way to dynamically create variables.

Well in just about all games, your client queries the server for data, which is uncompromised and quickly detected and shut down if compromised. It's not useful at all to be able to receive data from other clients, who's environments honestly should be actively thought of as compromised and hostile.