Larian Banner: Baldur's Gate Patch 9
Previous Thread
Next Thread
Print Thread
Joined: Dec 2016
Location: United States
member
OP Offline
member
Joined: Dec 2016
Location: United States
I've been thinking of ways to save on save time/load time/memory usage in Epic Encounters, as it has a notable impact on these due to its massive scripted components.

One thought is to how the game is storing the local variables of functions. Since these variables are only ever initialized on script initialization, I am lead to infer that they are stored until the script is unloaded--not deallocated when the function execution is completed. If this is true, I would save by using a reusable common set of global variables for generic data manipulation (disgusting). At the very least, I could save by replacing use of local variables with actual data (making it less readable). Along with this, I think that each non-function event is handled (relatively) concurrently, let me know if I'm wrong.

Secondly, I could save by outsourcing each character's scripting to "control" scripts, held by a player (not story scripting, I won't even entertain the notion. Also it would break saves). This would mean that NPCs would only hold information unique to themselves, as well as some functions for interfacing with the control script.

Lastly, I could save by reviewing all global variables that I use for passing data between function calls and replace them with a set of common, reusable variables (because we cannot pass data through them implicitly. Why, we'll never know). Functions that would never impose risk of racing conditions with one-another would share variables.

Any ideas/input would be greatly appreciated, especially insight from Larian on how things work behind the curtain.

Last edited by Ameranth; 04/03/17 02:16 AM.
Joined: Mar 2016
Location: Belgium
T
addict
Offline
addict
T
Joined: Mar 2016
Location: Belgium
Originally Posted by Ameranth

One thought is to how the game is storing the local variables of functions. Since these variables are only ever initialized on script initialization, I am lead to infer that they are stored until the script is unloaded--not deallocated when the function execution is completed.

That is correct: "local" variables are only local in terms of visibility scope, not in terms of storage allocation.

Quote
Along with this, I think that each non-function event is handled (relatively) concurrently, let me know if I'm wrong.

Here are the things as far as I understand/know them:
* time slicing of the execution of behaviour scripts (and Osiris code) happens in terms of frames (I'm not entirely sure yet whether these correspond to rendered frames though)
* Every frame, every active "reaction" of every active behaviour script executes one operation/statement
* If you catch an "event" in a behaviour script, everything this event handler does is executed in the same frame. If it throws events that are caught by other items/characters, those are also executed inline in the same frame (not if the events are caught by Osiris code though, afaik), and before continuing to the next line of the original event.

I don't think the code of multiple event handlers (or the same event handler for multiple object instances) can ever execute in parallel (that would probably break a lot of scripts). However, I'm not aware of any guaranteed ordering, so in that sense they indeed run relatively concurrently.

Quote

Secondly, I could save by outsourcing each character's scripting to "control" scripts, held by a player (not story scripting, I won't even entertain the notion. Also it would break saves). This would mean that NPCs would only hold information unique to themselves, as well as some functions for interfacing with the control script.

Lastly, I could save by reviewing all global variables that I use for passing data between function calls and replace them with a set of common, reusable variables (because we cannot pass data through them implicitly. Why, we'll never know). Functions that would never impose risk of racing conditions with one-another would share variables.

Both of these approaches are indeed possible. Regarding why no implicit parameter passing for functions: my guess is that it's to avoid having to maintain a dynamic stack (and the same probably goes for why the local variables are static).

Joined: Dec 2016
Location: United States
member
OP Offline
member
Joined: Dec 2016
Location: United States
Thank you very much for the information!

Restructuring the mod code will still be a great task, but you've eliminated much of the guesswork that would have been required smile


Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.5