Hi! I'm back.
I think Maki did that already but didn't make any release yet
Yes, I did, but the software works highly code side, so that'd require changing offsets and etc in code and recompiling. I'm currently working on AIO toolset, so expect fully working wmsetxx.obj converter next week.
About playing with memory...
FF8 memory is static. The game uses hardcoded addresses to work with objects, so if you add more detailed object to the game, you will probably overwrite other stuff or headers or any sensitive variables. Let me explain this further:
World map segments are 0x9000h stored in memory. There are 5 segments (which I found, but I'm sure I missed at least one). So... the smallest world map segment is the one with water. One water only segment is ~0x2dbb leaving 0x6244 bytes of free space. This space CAN be modified, but 0x9000h cannot be exceed. If you exceed the 0x9000 limit and write like x12300 memory to segment 1 address start, then you'd probably crash the game, or just touch the second segment. Changing this without source would be extremely hard.
However!You can allocate memory at the end of process, change by assembler the engine to read bigger variables, and call segments from new hardcoded address, which is the one you allocated.
Wmx.obj file can be normally edited, and it's size can be freely changed. Why? The engine reads only specific segments. If you add new, custom built segment at the end of file, and keep 0x9000h size of it with padding if needed, then nothing would happen. I didn't find a opcode, the engine calls for segment load with specific index, but I'll see if the knowledge of where specific segments are will help me with this. If I found it, then I could recall it to use custom built segments from the end of file. FF8 engine reads files by stream, so they can be real-time edited, repacked and etc. For example, you can extract and edit wmx.obj file, even when on worldmap in-game, then re import file, save it, get back to already running game and moving forward, so it can read next segment at specific position. It's the same as any other stream works. It makes the engine don't load whole file, but only it's part. This way, a programmer can get for example a 2MB data, that is stored in the semi center of 2GB file in matter of milliseconds (with current CPUs).
For wmsetus.obj file, it's more complicated. World map objects like cars, garden, ragnarok does not contain padding, and are loaded and allocated just as the game needs. That means, if you wish to replace ragnarok with much more data, then real-time memory editing would affect other vehicles data (however, this didn't appear in my tests, even when I wrote memory that overwritten other objects data loaded in memory, they still were working. I didn't know which one I was overwriting, so probably that's why I didn't notice the change).
If memory editing in this case is not recommended, then
normal wmsetus.obj hex'edit should work. The engine would just push the other vehicle data for your new object. (Or the engine loads all vehicles, and keeps them in the memory? I don't know, need to test it someday).
Still, if the wmsetus declared size will be exceed (which I don't know at the moment how much does it takes space in the memory) then you still be able to overwrite some other data.
Another example to clarify this:
Just
after world map segments in memory, a
core Squall data is stored. This means, if the last segment in memory would be bigger than 0x9000h, then the game would read for example one triangle's vertex as Squall position, instead of this triangle (as we intended to use it). Still, modifying engine to read more than 9000h data and calling it from the allocated by user data at the end of file is the safest and best way. Still, due to x86-86 (32 bits) compilation, you'd need to make sure you doesn't allocate more than 4GB memory in total.
Why does changing camera logical zoom and flying from esthar to bridge would crash the game? This is the glitch that is made because of "size exceeding" and static memory "bad sides".
This is more detailed exception with memory addresses and related FF8.EXE opcode (thanks to debugger):
First-chance exception at 0x00545F36 in FF8_EN.exe: 0xC0000005: Access violation reading location 0x36382834.This means, that opcode at 0x00545F36 (FF8_EN.exe+145F36 - mov ax,[edi]) tried to read memory at 36382834, but this memory address didn't exist.
Why this happened? The memory exceed it's size limit (probably engine tried to load another texture, but in fact loading this made the engine to overwrite some sensitive parts of memory and in fact ordered the engine to read 36382834 address (which could be just part of texture bytes, or for example changed header, to read for example 255 vertex instead of 10 and completely make the game go insane).
Battle stages - I didn't test memory addresses and sizes yet. Can't write much here.
@Edit:
Just a little back to memory allocation. Making the game allocate memory ADD's null byte at the end of process. This way you can store everything you want, even assembly (sic!). You can still order a process to call specific instruction. You can even add your own code to the game.
