Difference between revisions of "Talk:Saves (GTA 4)"
Jump to navigation
Jump to search
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
==Block 32: Checksum== | ==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. | + | 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. -[[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) | ||
| + | ::I have a few saves where the bytes after END are 12 bytes long as well, the difference is that they were created while using XLiveLess, I believe, as they are located in the XLiveLess save location, rather than the default. That's why I believe they have something to do with GWFL, since XLiveLess disables a bunch of GFWL functions. -[[User:Samutz|Samutz]] ([[User talk:Samutz|talk]]) 00:30, 10 March 2015 (UTC) | ||
| + | :::Yes, XLiveLess might affect. In fact I'm using it. At the moment I only have one savegame file to play with, can you provide me with some more of yours, so we're moving in-tact? [[User:Seemann|Seemann]] ([[User talk:Seemann|talk]]) 08:26, 10 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) | ||
| + | ::So would this be correct for 010? | ||
| + | ::Checksum(CHECKSUM_BYTE, 0, end_of_blocks-4) - 12; // end_of_blocks being the start of END | ||
| + | ::My result still comes up either slightly larger or slightly smaller than the stored checksum, except for one save. -[[User:Samutz|Samutz]] ([[User talk:Samutz|talk]]) 00:30, 10 March 2015 (UTC) | ||
Latest revision as of 08:26, 10 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)
- I have a few saves where the bytes after END are 12 bytes long as well, the difference is that they were created while using XLiveLess, I believe, as they are located in the XLiveLess save location, rather than the default. That's why I believe they have something to do with GWFL, since XLiveLess disables a bunch of GFWL functions. -Samutz (talk) 00:30, 10 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)
