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)