Variables – Talk

Global variables: my advice ... declare them all in init.sqf first!!!!!! Sorry for the yelling but this really really threw me. Global variables held different values when I was just declaring them within scopes of other spawned scripts, etc. and it wasn't obvious what was going on. I'm surprised this isn't even mentioned by anyone.. or is it? --Doolittle 19:49, 12 September 2007 (CEST)

Did you read this part: Variables#Scope? ++Str 19:58, 12 September 2007 (CEST)

Yes I did. That's what threw me. "scope does not apply to global variables"... my experience shows it does. --Doolittle 23:24, 12 September 2007 (CEST)

Are you 100% sure? I have yet to see a global variable contradict the expect behaviour. Could you point us to an example mission? UNN 02:10, 13 September 2007 (CEST)

No example mission. Sorry. I just had the experience of using a global var inside one execvm script, and then also calling it from mapclick event and the values wouldn't sync up. When I declared the global in init.sqf then they did sync. I can't quite tell if it's that the global var assignment in one "scope" didn't carry over to the other or what... I'm just saying I noticed something fishy. Maybe I am just mad in the head. :) --Doolittle 05:13, 13 September 2007 (CEST)

Haven't seen the global issue you describe - afaik, the globalness as been as always. Possibly what you are looking at as a problem is more a feature. If you define a 'global' or more correctly a top-most parameter in a spawned thread and then expect that the value will persist properly to another thread that may live at the same time or at a point in the future then of course you're going to have problems and of course you would need to define & probably initialize the variable from mission outset. - but, this is not a flaw in the game design or a bug. - It has always been the case... afaik. --Sy 08:05, 13 September 2007 (CEST)

As Sy said, it could be a case of timing when coordinating multiple scripts? A classic example is MP scripting. A Map click would be captured locally on the client, if you then want to transfer that to the server, there will be a delay. Or say a looping script that runs on both client and server, that waits for some change in state, of an object. The change in state could be not Alive e.t.c Both scripts will detect the change, but the script running on the computer local to that object will always activate first, with a short delay before the other scripts react. Not saying this is something your not aware of. As a relative newcomer to MP scripting myself, I thought it would be worth mentioning, for anyone else who experienced the initial problems I did. Also, in some cases, the Scope rules do not always apply. Arrays within arrays, defined locally, can sometimes be accessed globally. Also depending on how you manipulate global arrays, the changes might not be reflected across all the scripts. As well as changes sometimes showing across all scripts, when you don't want them to. I think you probably are mad in the head. But given the amount of MP scripting I'm doing now, it won't be long before I reach the same state :) UNN 14:05, 13 September 2007 (CEST)

Arrays

(above comment UNN; 13 Sept 07') are a big exception to this complete article. They are references, and therefore certain ways of handling them are dissimilar to regular variables. I would suggest noting this in the article, somewhere at the top. What do you guys think? Besselinksjm 11:27, 19 January 2010 (CET)

Deletion

This article recommends destroying variables using 'nil', when making use of a large number of large variables. Is this also necessary (/recommended) when scoping variables using private? Or reframing the question: are variables inherently destroyed when their scope does no longer exist? Besselinksjm 12:18, 19 January 2010 (CET)

Names of global variables interfere with commands

Since global variables "override" commands very nasty things can be done:

 pi = 3; // Aaaahhhh!
 worldName = "Disneyland";
 true = false;
 isServer = true; // which is now false
 time = -1;
 nil = [] execVM "foo.sqf";
 ...etc...

Maybe this should be noted. --Worldeater 08:30, 11 March 2009 (CET)