GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

[CacoKnight]

Hello, just registered and first post here, just wanted to report that GZDoom 4.11-dev gives me "unknown checksum" on those 4 map files (.WL6, .SOD, .SD2, .SD3) when I load Wolf3D.ipk3 but with GZDoom 4.10-stable it's all good and they load perfectly.

Can a dev look into this?

Thank you.

[wildweasel]

Wait, do we have Wolf3D support officially, or is this a downloadable TC?

[Kappes Buur]

Loading Wolf3D.ipk3 with

• gzdoom-x64-g4.11pre-279-g22271d146
• gzdoom-x64-g4.11pre-355-gf6c3ce6b1

runs without any problem for me.

[CacoKnight]

They all load Wolf3D.ipk3 without issues, the GAMEMAPS.XXX files are the issue. I tried all the builds now and THE LAST WORKING ONE IS build 279.

354, 355, 357, 364 and 372 all give "WARNING: GAMEMAPS.XXX has an unknown hash HASHVALUE".

[wildweasel]

Do you know what version of the game your gamemaps files are from?

[Rachael]

The Wolf3D.ipk3 project has an old version of 3saster's md5 hashing algorithm. I've tried fixing it on my own but I am not getting the correct result.

Just to clarify, the Wolf3D.ipk3 has scripting code to read the GAMEMAPS.XXX files - GZDoom does not handle this on its own. However, GZDoom did change the ReadLump implementation since 4.8.0 which is why the md5 hashing algorithm is getting bogus results.

[AFADoomer]

This is a recent change... I just updated to current dev build and it's broken, but the previous build I had (from maybe a month ago, at most?) worked fine.

What changed in the ReadLump implementation?

[CacoKnight]

wildweasel wrote:
> Do you know what version of the game your gamemaps files are from?
They are the latest ones, tried from Steam, GOG etc., all have the same hash.

Rachael wrote:
>Just to clarify, the Wolf3D.ipk3 has scripting code to read the GAMEMAPS.XXX files - GZDoom does not handle this on its own. However, GZDoom did change the ReadLump implementation since 4.8.0 which is why the md5 hashing algorithm is getting bogus results.
It actually does, or does now, read my post again, something changed between build 279 and build 354 that makes GZDoom not load those mapfiles for Wolf3D TC.

[Rachael]

Rachael wrote:
>Just to clarify, the Wolf3D.ipk3 has scripting code to read the GAMEMAPS.XXX files - GZDoom does not handle this on its own. However, GZDoom did change the ReadLump implementation since 4.8.0 which is why the md5 hashing algorithm is getting bogus results.
It actually does, or does now, read my post again, something changed between build 279 and build 354 that makes GZDoom not load those mapfiles for Wolf3D TC.

No, it does not. The Wolf3D.ipk3 is what's handling it. GZDoom does not have code to handle the maps on its own.

[Rachael]

This is a recent change... I just updated to current dev build and it's broken, but the previous build I had (from maybe a month ago, at most?) worked fine.

What changed in the ReadLump implementation?

I don't know, but it's obvious this is a bug, so I've moved this to the bugs section and marking it as critical since I think this needs to be addressed before the next release.

[CacoKnight]

No, it does not. The Wolf3D.ipk3 is what's handling it. GZDoom does not have code to handle the maps on its own.

Oh I see, I'm sure there are other things in the code I don't understand. Thanks for taking the time to check it out and test it.

[AFADoomer]

What seems to be happening is that the something underlying the ReadLump call stops parsing the lump when it hits a null character (or maybe there's an error in truncation somewhere?).

If I console.printf the read-in contents of the GAMEMAPS files in older versions, I get the full contents. Now I just get the header and a few characters, then nothing past the first 10-13 bytes... always terminating where there's a 0x00 character in the file.

EDIT: Demo file attached. Reads a simple text file that has a null character at the beginning of the second line. Only prints the first line (first 13 bytes) in current builds, and prints all three lines (66 bytes) in older builds.

[Graf Zahl]

That last post finally gave me something to analyze it.

Next time, please post your bug report in a way that people not familiar with the mod you are having problems with can UNDERSTAND!

The cause here was a change I made to handle broken shader files ending with a 0-byte but I missed that the function doing the truncation was also used for reading lumps into strings for ZScript.

[AFADoomer]

Thanks, Graf! I can confirm that this is *mostly* fixed - except that ReadLump formerly added a null character at the end of the string, and this change does not.

3saster's MD5 hashing script truncates the last read-in letter by default, so this change isn't fully backward compatible with any mod that used that resource, or otherwise expects a null character at the end of the string.

[Graf Zahl]

That last 0 byte should never have been there, it was just a side effect of a very weird way to handle this data in the engine. If you read a lump you want the lump's data, not something that appends another byte of data.