Variables – Talk

From Bohemia Interactive Community
Jump to navigation Jump to search
No edit summary
No edit summary
Line 8: Line 8:


:::: 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 <u>not</u> a flaw in the game design or a bug. - It has always been the case... afaik. --[[User:Sy|Sy]] 08:05, 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 <u>not</u> a flaw in the game design or a bug. - It has always been the case... afaik. --[[User:Sy|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 :) [[User:UNN|UNN]] 14:05, 13 September 2007 (CEST)

Revision as of 13:05, 13 September 2007

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)
Retrieved from "https://community.bistudio.com/wiki?title=Talk:Variables&oldid=37861"