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 true?
• 3- The only context that I can see, is when some global should "hold" two possible and simultaneous values at the same time: one set within the quest context and another for the rest (of which I would question the real usefulness or "gain" because of the above point 1). Am I right? Because for all other instances (one Global = one shared value for all), and from what I understand here, I really 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...).

Can anyone enlighten us about this? --HawkFest (talk) 2013-04-16T11:25:55 (EDT)