Nice work on the store garage structure. This is exactly the sort of thing I'm hoping you'll find with your in-game testing. Well done. These sorts of things are not mistakes though. The best available information was documented accurately. It's only a mistake if it passes quality control. Keep an eye out for opcodes that don't quite match descriptions. Sometimes you find that enable = 1 turns it off, it should really be disable = 1, or even toggle = 1 and the parameter is ignored. Or maybe they fixed the default descriptions to match mobile so there won't be so many surprises.
I'm pretty sure the SA save structure is like thehambone's description in the save and Seemann's description in memory.
Hypothesis (a hunch): All fields are part of an array. (An array may only include 1 record.)
Clues in exe: a variable naming structure such as sysytem.savename, system.wYear, system.wMonth, etc. then a distinct change to time.gamemin, time.weathertimer time.gamehour, etc. I think this breaks things down a little more than I'm really expecting though. ID, System, MIsc, and maybe some odd stuff in the unknown stuff at the end seem like the broader groupings within the block 0 header, records with fields of similar information. Other clues would be separate subroutines that write system info and misc data, or a nesting structure in the code.
My hunch is suggested by the c0de words in the SA mobile saves - extra words with a value of 0xC0DE. My hypothesis is that these words written at the start of each write command. The IPL byte flags are written de c0 00 de c0 01 de c0 00, but pickups are writed c0de+pickup record0, c0de+pickup record1, etc. - which totally shot my previous hypothesis that structures like pickups and markers is a dump of the whole pool at once. I don't yet have enough information to predict where all of the c0de words appear.
The application is that I would like to work with groups of fields in an editor and I'm looking for an inherent structure to organize the information. For example, save compare but ignore all system info, stats, and crane info with one check box for each group. Or making it easier to convert a PC template/wiki to PS2 without the system info - the offsets for the misc record wouldn't need to be adjusted as much. And I'm looking for clues to solve the c0de word riddle.
The offsets and values were mocked,
0x0000 dword block size
0x0000 systeminfo 40? bytes
0x0000 wchar_t save name
0x0034 word SYSTEMTIME wYear
0x0036 word SYSTEMTIME wMonth
0x0038 word SYSTEMTIME wDayOfWeek
0x0060 misc 220? bytes
0x0000 dword unknown
0x0004 enum current island (1=Portland; 2=Staunton; 3=Shoreside Vale)
0x0008 float camera coordinates (x,y,z)
0x00C0 dword sub-block size
0x00C4 sub-block (threads)
Little Boxes: This analogy holds up better than I expected.
Save, Block Size, Block, Header, Sub-block size, Sub-block, Sub-header, Data Pool, Record, Array, Field, Checksum
Ferry, Truck License, Semi-truck, Tractor, Trailer License, Trailer, Tool Rack, Cargo Hold, Box, Box Stack, Thing, Displacement
In this analogy I work for the shipping company in charge of moving your things; all of the containers are ours, that's our specialty. We don't care what your things are but could look it up on the website if we were curious. We figure that if the ship weighs the same at the origin and destination then everything made the journey. We want to put all of your things in boxes. Should we put each thing in it's own box, everything in one box, different boxes based on type, or back in the doriginal boxes?