I thought that all 'VARS' were 'local' variables that exist throughout the function only. (Like auto variables in C)
They're like "static" variables in C: if you give them a value during one invocation, they will still have the value during the next invocation. I don't know how it works when saving/restoring a game.
But still 'function local', having no connection to the other event's variables of that name, correct ?
Correct.
Must be that the BURNING status is stored with the object itself, because I see no other way it could be re-initialized by the script after a load.
I don't know how Osiris internally handles item statuses. OTOH, saving and loading does not suddenly remove a poisoned status from a character either, so it would seem logical for all statuses to be stored as part of every object, since they were not necessarily set by the OnInit event of a script.
Looking through the script and trying to understand it, in the case of the Torch, it does not seem to matter at all if local or static or 'script global', the variable seems to be nothing more than a 'target dump' for a potentially existing global variable.
Yes. And in that case, you don't even need a local variable. The script author could just have used "_" as an anonymous variable, like in Osiris scripts.
Note that there are two different variables in play here: the local/static _IsStatusOn ones, and then the global one that is accessed using the string constant name parameter of SetVar/GetVar ("IsStatusOn").
The former just refers to the local/static variable of the same name declared in the VARS block of the current function.
The latter will (attempt to) access a variable in the global VARS block with the name %IsStatusOn.
My bad, sorry for being so stupid, should have figured that out myself.
It's easy to miss such details when you start out with these scripts, happened to me also several times.
Does it only return FALSE because the variable is not found in global space or does it also set the local (static) _IsStatusOn to 'null' ?
I don't know if it sets the result in case the variable does not exist, but I would not count on it. Even in case it does so today, that is definitely the kind of thing that may well be "implementation defined" or "undefined behaviour". I come from a compiler development background, and this is a very recognisable situation
Also, can globals (%xyz) be accessed in 'parallel' scripts that do not #include them or must there be some 'connection' ?
The connection is that the scripts must be associated with the same game object. They do not have to include each other. The variables are not part of a script (otherwise you would have one global variable shared by all game objects that use that script), but part of a game object.
So put together, all that variable querying and setting is only for additional scripts that might get attached to an item and have that variable ? It serves no purpose if only Torch.itemScript is attached ?
It serves the purpose that (the rest of) this script can be used both for items that do have additional scripts with these variables and for items that don't have them. It's basically introspection to help make the script more generic.
Do you also happen to know, what the 'data "Flags" "Torch"' in stat entries means ?
Could it have something to do with only items with it receiving the events handled in BurningItem.itemScript at all ? (Only found the events there)
All root templates that have the Torch.itemScript seem to use Stats with this flag.
I don't know, sorry. I never delved into the stats files. In general it does seem like several things have been implemented specifically for certain use cases because (possibly at that time) the generic scripting framework did not support the required functionality. I've seen some comments dating back to the early 2000s in some Osiris scripts, so there is probably quite a bit of cruft left
BTW, your videos with the moving wagons are quite impressive !!
Thanks
The character and item scripts in that mod contain lots of comments, so you can also have a look at the code to learn more about how that part of the scripting system works.
