Talk:UpdateCurrentInstanceGlobal - Quest

Usage and context?

Although it looks quite simple, I wonder about the potential contexts which would make this function actually useful (if not mandatory for whatever reason). Although I don't really understand its usage scope yet in regards to its Wiki article (so please correct me if not to confirm what I'm writing), Here's how I see it :

• 1- I can get and set values on globals from within any script via global properties. No need of a quest to do so. Now, why would a quest require to "cache" some global variable, since we can use properties and work along these? I'm sure there's a legitimate reason, unfortunately I fail to see it at first glance, some explanation is required.
• 2- As for quests, from what I understood in the Wiki, they hold a "copy" (like some cache) of any global declared in their quest text global list. Thus if a global is modified outside some quest script, UpdateCurrentInstanceGlobal would be put into action so as to update that "quest's Globals cache" (the Global in question). Is this a correct assertion?
• 3- For all other instances where (one Global = one shared value for all), and from what I understand here, I don't see the value of putting a global variable into some quest global list, if not for the laziness of declaring global properties in whatever script depending on such quest (but one would have to declare it anyways in the quest's global list and refer to it from "outside scripts" via the quest's prefix and make reservations in the code design for the use of UpdateCurrentInstanceGlobal and...... Not a so "lazy" shortcut in the end...).
• 4- The only context that I can see, is when some global should "hold" two possible values at the same time: one set within the quest's context, and another one for the rest of the game. Consequently, when the quest stops, the original Global is still available and untempered by the mod's quest itself (which is a good thing in terms of mod management : removing a mod having a quest modifying some Global would leave the corresponding vanilla Global untouched). Am I right?

--HawkFest (talk) 2013-04-16T11:25:55 (EDT)

• The fact that globals set up in quests retain their original value could be useful if you are running a quest that needs to base itself off of conditions that exist when it first starts, and continue basing itself off those conditions throughout the quest. Maybe, for instance, if you start the quest on a rainy day, a whole different storyline unfolds, and in order to remain consistent throughout, that same storyline (which relies on the globalVariable at the quest's start) needs to reference that variable at different times as the quest progresses.
• RE: your number 4 - if the quest stops, the global will not be returned to an original value as you seem to suggest. They quest's snapshot of what the global was when the quest started will simply evaporate. (apologies if I'm misunderstanding you there).
• And just a clarification for anyone wondering about broader functionality - you don't ever need to use this function if you are retrieving a Global Variable's value via getValue() in a script or script fragment - that function will always return the true current value of the Global Variable property in question. --Egocarib (talk) 2013-09-21T16:16:20 (EDT)