Difference between revisions of "Talk:Saves (GTA 4)"

From GTAMods Wiki
Jump to navigation Jump to search
Line 3: Line 3:
 
:-[[User:Samutz|Samutz]] ([[User talk:Samutz|talk]]) 22:01, 8 March 2015 (UTC)
 
:-[[User:Samutz|Samutz]] ([[User talk:Samutz|talk]]) 22:01, 8 March 2015 (UTC)
 
:The Checksum number is strange, but I haven't had a look yet how it's calculated, hope to get it soon. I'm frustrated about the last block (END), which completely differs from your description, Samutz. I have only 12 bytes after the "END\0" string, and it kinda random values, so I guess the game just does not read anything after the END word. Bytes following it are probably a padding to round the file size to the reasonable bounds (/16, /256 or something like that). I did my investigation on a savegame file made on v1.0.3.0 (kinda old, I know, will check on v1.0.7.0 soon). [[User:Seemann|Seemann]] ([[User talk:Seemann|talk]]) 23:53, 9 March 2015 (UTC)
 
:The Checksum number is strange, but I haven't had a look yet how it's calculated, hope to get it soon. I'm frustrated about the last block (END), which completely differs from your description, Samutz. I have only 12 bytes after the "END\0" string, and it kinda random values, so I guess the game just does not read anything after the END word. Bytes following it are probably a padding to round the file size to the reasonable bounds (/16, /256 or something like that). I did my investigation on a savegame file made on v1.0.3.0 (kinda old, I know, will check on v1.0.7.0 soon). [[User:Seemann|Seemann]] ([[User talk:Seemann|talk]]) 23:53, 9 March 2015 (UTC)
 +
:The checksum number is written directly before the END word, it's a sum of all preceeding bytes - 12 (minus twelve). The END is a stop-word, after that the padding bytes follow. That's my assumptions, will check it later. [[User:Seemann|Seemann]] ([[User talk:Seemann|talk]]) 23:59, 9 March 2015 (UTC)

Revision as of 23:59, 9 March 2015

Block 32: Checksum

There's a chance that I'm completely wrong about this and it's not the checksum. However, it is the final block, excluding the END block, and comes after several empty blocks. The calculated checksum of all of the bytes preceding it comes close to the (suspected) stored checksum. In my calculations, I've tried several combinations of including/excluding the block size, BLOCK chars that come just before it, the bytes at the start of file preceding block 1, and the END block bytes.

-Samutz (talk) 22:01, 8 March 2015 (UTC)
The Checksum number is strange, but I haven't had a look yet how it's calculated, hope to get it soon. I'm frustrated about the last block (END), which completely differs from your description, Samutz. I have only 12 bytes after the "END\0" string, and it kinda random values, so I guess the game just does not read anything after the END word. Bytes following it are probably a padding to round the file size to the reasonable bounds (/16, /256 or something like that). I did my investigation on a savegame file made on v1.0.3.0 (kinda old, I know, will check on v1.0.7.0 soon). Seemann (talk) 23:53, 9 March 2015 (UTC)
The checksum number is written directly before the END word, it's a sum of all preceeding bytes - 12 (minus twelve). The END is a stop-word, after that the padding bytes follow. That's my assumptions, will check it later. Seemann (talk) 23:59, 9 March 2015 (UTC)