Moved to modding.
Daniel.
It's not a DM game without people attacking the save files
Re: It's not a DM game without people attacking the save fil
A gently fried snail slice is absolutely delicious with a pat of butter...
Re: It's not a DM game without people attacking the save fil
d'ohDej wrote:The 04 after the "GRIM" keyword is in fact the size of the segment data. That size is encoded as a 32-bit word in little-endian and will be the same on all save files: 04 00 00 00.x000000 47 52 49 4d 04 00 00 00 81 c2 0e 00 78 9c ec 7d 'GRIM........x...'
I'm assuming that the 04 is a version tag or something similar.
The segment data is therefore the next 32-bit word (at offset 8). It is also a size, and also little-endian. It is the size of the uncompressed zlib data. In the example above 81 c2 0e 00 --> 0x0EC281 = 967'297 bytes.
Following that is the zlib data. The first 16-bit word (offset 12) is the zlib data header. It will not change from one save file to the other: always 0x789C (which corresponds to a standard zlib compression). Following that is the compressed data.
I had gotten as far as "segment data size" but somehow I'd ... oh, geeze. I compared it to the size of the file, which it wasn't, and didn't realize that it might be the size of something contained within the file.
Re: It's not a DM game without people attacking the save fil
Hi,
That pattern (TAG word on 4 Bytes + SIZE as a 32-bit integer, little-endian) is typical in the uncompressed data. That's how I deduced that the 04 00 00 00 must also be a size.
Pierre
That pattern (TAG word on 4 Bytes + SIZE as a 32-bit integer, little-endian) is typical in the uncompressed data. That's how I deduced that the 04 00 00 00 must also be a size.
Pierre