Difference between revisions of "Talk:UpdateCurrentInstanceGlobal - Quest"
Jump to navigation
Jump to search
Talk:UpdateCurrentInstanceGlobal - Quest (edit)
Revision as of 10:41, 16 April 2013
, 10:41, 16 April 2013→Usage and context?
imported>HawkFest |
imported>HawkFest |
||
| Line 4: | Line 4: | ||
*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. | *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? | *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- | *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 (thus when the quest stops, the original Global is still available and untempered). Am I right?''' | |||
--[[User:HawkFest|HawkFest]] ([[User talk:HawkFest|talk]]) 2013-04-16T11:25:55 (EDT) | --[[User:HawkFest|HawkFest]] ([[User talk:HawkFest|talk]]) 2013-04-16T11:25:55 (EDT) | ||