Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Breaking change: GMS230 remove encver, and change ref string behavior.

See original GitHub issue

Like most GMS players suspected, starting from v230.1.20220208, GMS has removed the 2 bytes encver from wz just like KMS did two months ago (#181), But they have not split wz files into small pieces.

OK, it doesnot sound serious, as wcR2 already supports encver auto detection. The next thing is really BREAKING.

After you update the GMS latest version, you happily drag the base.wz into wcr2, wait a second, then check Character.wz, you’ll see the same thing like me:

Skipping some dull debug works, I could tell you that the Character.wz loading failed because it got some duplicated keys at GetDirTree function, the duplicated node names ぞ㘱㜶⤰ and the full path is "Character/Shoes/ぞ㘱㜶⤰", the actual file offset in file is 0xe2f2d.

OK, we opened the wz file with some hex file editor, goto the breaking position, now we must read wz file with your brain 😃

02               // image name is a ref string
B5 87 00 00      //   image name position is at 0x87b5
80 50 49 00 00   // image size is 0x4950
80 c4 5e 1c 00   // image checksum is 0x1c5ec4
b0 ab c2 8f      // image hashed position is 0x8fc2abb0

we move to the string position, the real string position in file is 0x3c + 1 + 0x87b5 = 0x87f2 https://github.com/Kagamia/WzComparerR2/blob/65f576419d2f71c307df24b5bc716ea8622e611c/WzComparerR2.WzLib/Wz_File.cs#L365

04   // utf16, strlen = 4, 
F4 9A 9A 9C 9A 9D 9D 83  // crypted string, decrypted as 5E 30 31 36 36 37 30 29 "ぞ㘱㜶⤰"

This is definitely wrong, but if we offset 1 byte, the things become reasonable:

04    // skip
F4    // ascii, strlen = 12,
9A 9A 9C 9A 9D 9D 83 88 9C DA D9 D2  // decrypted as 30 31 30 37 33 32 33 39 2E 69 6D 67 "01073239.img"

So, in this scenario (encver removed), a referenced string should offset additional 1 byte to align the old wz format. The similar error does not appear in KMS, because KMS has already splited wz files, so each wz file has little possibility to reference other duplicated strings.