GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by CacoKnight » Mon Oct 02, 2023 2:26 pm

Nice, thank you AFADoomer.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by AFADoomer » Sat Sep 16, 2023 11:45 am

Oh, I agree... Just wanted to highlight that this will break some older mods. No big deal for me, because I'm going to release version 3.1 once GZDoom 4.11 comes out - but I don't know who else used that MD5 hashing tool, or otherwise expects the final null character.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by Graf Zahl » Sat Sep 16, 2023 11:34 am

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.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by AFADoomer » Sat Sep 16, 2023 6:55 am

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.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by Graf Zahl » Fri Sep 15, 2023 11:39 pm

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.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by AFADoomer » Fri Sep 15, 2023 5:25 pm

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.
Attachments
fileread.pk3
Just load a map.
(942 Bytes) Downloaded 56 times

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by CacoKnight » Fri Sep 15, 2023 2:08 am

Rachael wrote: ↑Fri Sep 15, 2023 1:59 am 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.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by Rachael » Fri Sep 15, 2023 2:04 am

AFADoomer wrote: ↑Thu Sep 14, 2023 5:25 pm 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.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by Rachael » Fri Sep 15, 2023 1:59 am

CacoKnight wrote: ↑Thu Sep 14, 2023 5:57 pm 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.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by CacoKnight » Thu Sep 14, 2023 5:57 pm

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.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by AFADoomer » Thu Sep 14, 2023 5:25 pm

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?

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by Rachael » Thu Sep 14, 2023 5:15 pm

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.

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by wildweasel » Thu Sep 14, 2023 4:22 pm

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

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by CacoKnight » Thu Sep 14, 2023 2:25 pm

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".

Re: GAMEMAPS.XXX on 4.10-stable vs 4.11-dev

by Kappes Buur » Thu Sep 14, 2023 12:09 pm

Loading Wolf3D.ipk3 with
  • gzdoom-x64-g4.11pre-279-g22271d146
  • gzdoom-x64-g4.11pre-355-gf6c3ce6b1
runs without any problem for me.

Top