I am trying to set up set of ~100 global arrays each containing ~100 long string references (using Merzasphor's array functions) once on first reload or new game start. The motivation for doing this only once initially and not every reload (or restart) is that doing it repetitively seems to exhaust the memory allocation for MWSE arrays or strings (I suspect the number of arrays may be limited to ~256 but need more testing to be sure). I've manually tested that the arrays stay in memory between reloads with the same global array pointer remaining valid after initial reload or new game setup. The difficulty I'm having is differentiating first reload (or new game) from subsequent ones. Any known method or ideas how to do it?

What are you needing 100 different arrays for? There might be some other more efficient way to accomplish it.


Anyways, if arrays do persist through subsequent reloads, couldn't you use their validity to test if its the initial load or not?

Create one extra "reload detector" array that has just one element with a value of 1. Then any time a reload is detected, check that array and see if it's first value is still 1. If so, then your arrays are valid, if not then they need to be created.


You can then easily detect new games in any number of ways, with chargenstate or just checking if the players name/class/etc have been set.

Page 171 of SFD has a section "Detecting when the player does a load from saved game"; have you looked at that for useful ideas?

Thanks. I think all these ideas apply to reloading a save game that would include subsequent reloads in a single gaming session.

I'm using an array of arrays to look up the player's region based on position, that I can subsequently use to call the correct changeweather for. The array is read in from a text file generated using tes3cmd on the current load order. Certainly if there is a better way I'd be very happy to simplify this implementation.

Using another array to detect reload is as good idea. Although now that I think of it seems strange that the global array variable doesn't get reset on reload. Do you know, should global variables generally get updated through the save game data or not? That actually has a lot of implications I hadn't thought about. Thanks.

global variables are saved (as float) in the .ess. local script variables are saved in the .ess. Global script variables are saved in the .ess if the global script is run in the session (e.g. autostarted global script) or even in 72hours, I don't remember exactly it should be in MSFD

Thanks Abot. I think I figured out my incorrect thinking on this - my global array of arrays variable was updated from the save game, it just happened to be a save from the same session so that's why it worked to point to the correct memory location! So what I think I could do is save this pointer to a file (xFileWriteLong) on first session load or new game and then retrieve it from there on subsequent one(s).


That still leaves the problem of differentiating the very first load from subsequent ones. Since the mod I'm working on includes parallel running command line interface I can easily have that write a unique text file entry on the initial session (Morrowind.exe) start that I can key off of to differentiate first and subsequent session reloads/restarts. Not a very general purpose method but sufficient for my needs now.


Unfortunately this still leaves the concern if MWSE arrays from the first reload/start may get overwritten eventually in subsequent reloads/restarts. Or if this mod could be gobbling up too much of the limited MWSE memory resources (either arrays or strings).


Using the parallel running command line I could off-load the region search with the main draw back being latency but for in-game weather control it's OK if there's a substantial delay; it's only annoying for my testing where I want to change the current region weather with a hotkey followed by resting an hour to bring out the new weather quickly. Probably I will change this before release to trade-off latency for stability, unless someone else can think of a better way to implement scripted PC region weather changes.

It is very interesting that arrays persists through reloads. I tested a little bit and it seems that they do, but I'm far from confident on whether they're reliable or not.


Shoot me a PM with a little more detail on what you're trying to accomplish though. I may have some ideas that could optimize/simplify the process.

With Greatness7's help I figured out my bug and it had nothing to do with MWSE memory limitation. I was passing the region name string from one script to another through a global long instead of through array and index global longs. When the memory location pointer was small enough it worked OK but once it exceeded the 24bit global precision limit it failed, returning random memory locations including past MWSE string data.