Talk:Saves (GTA 4) - Revision history

Seemann at 08:26, 10 March 2015

2015-03-10T08:26:05Z

Samutz: /* Block 32: Checksum */

2015-03-10T00:30:20Z

‎Block 32: Checksum

Seemann at 23:59, 9 March 2015

2015-03-09T23:59:31Z

Seemann at 23:53, 9 March 2015

2015-03-09T23:53:41Z

Samutz: Created page with "==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 afte..."

2015-03-08T22:01:17Z

Created page with "==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 afte..."

New page

==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.
:-[[User:Samutz|Samutz]] ([[User talk:Samutz|talk]]) 22:01, 8 March 2015 (UTC)

@@ Line 3: / Line 3: @@
 :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)
 :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)

@@ Line 1: / Line 1: @@
 ==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 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)

← Older revision		Revision as of 23:59, 9 March 2015
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)

← Older revision		Revision as of 23:53, 9 March 2015
Line 2:		Line 2:
	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)		:-[[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)