* moved the sprite renaming out of the file system entirely into a caller-provided callback.
* renamed several functions to closer match the terms of a file system.
* moved the VM interface out of the implementation.
Parts of this menu suffered badly from lack of screen space to convey the intended information due to the oversized fonts. With the new font this is a lot less problematic (unless using 320x200, of course)
This doesn't really write out any info for the pointer, if the level does not match it just errors out.
This is both for quick detection of badly used level data and for automatic restoring of the pointer from the serializer's working level.
This also removed the temporary workarounds in DAutomap and DLevelScript to restore these pointers when a savegame is loaded.
Calling the old method with a pointer to an array of unspecified length 'dirty' would be an understatement.
Now it uses a TArray to store the single elements
The manager class cannot be scriptified because it provides the internal implementation which may change at some point in the future. It also encapsulates all access to the file level because if that part is not protected, modders could write malware mods.
This was done to ensure it can be properly overridden in scripts without causing problems when called during engine shutdown for the type and symbol objects the VM needs to work and to have the scripted version always run first.
Since the scripted OnDestroy method never calls the native version - the native one is run after the scripted one - this can be simply skipped over during shutdown.
Needless to say, this is simply too volatile and would require constant active maintenance, not to mention a huge amount of work up front to get going.
It also hid a nasty problem with the Destroy method. Due to the way the garbage collector works, Destroy cannot be exposed to scripts as-is. It may be called from scripts but it may not be overridden from scripts because the garbage collector can call this function after all data needed for calling a scripted override has already been destroyed because if that data is also being collected there is no guarantee that proper order of destruction is observed. So for now Destroy is just a normal native method to scripted classes
- always make the top level object randomaccess when opening a JSON file for reading. Some things won't work right if this is opened for sequential access.
The 'unix' identifier isn't defined when '-std' is passed to the compiler (tested with gcc and clang), so use '__unix__' which is well enough documented.
