GZDoom 4.11.x thinks I have shareware Wolf3D & demo SOD

[JasonUK]

Version 4.10 of GZDoom ran/recognised my WL6/SOD/SD2 & SD3 files as the full paid versions of Wolfenstein 3D/Spear of Destiny but all versions of 4.11.x have so far just recognised them as shareware/demos. The WL6/SOD/SD2 & SD3 files were all taken from v1.4 DosBox versions of these games.

Trying to record GZDoom's loading screen I see that there are red errors for gamemap files having an incorrect hash? I'm not sure what that means or why these were fine for 4.10 but not 4.11 though? Any help/advice would be appreciated.

[Professor Hastig]

From what I heard that mod is depending on undefined behavior that stopped working when the bug got fixed.

[JasonUK]

Thanks for reply. I have other versions of those files from a really old copy of Wolf4SDL I have on my PC but cant remember where I got the gamemaps for that from but they have same issue with 4.11.x.

Any idea where I you can purchase/acquire the non-buggy versions if these files from if even the paid-for DosBox versions (which I bought from gog.com if I remember correctly) are buggy.

[Professor Hastig]

It has nothing to do with the files but with how the mod checks them.

[Gez]

Version 4.10 of GZDoom ran/recognised my WL6/SOD/SD2 & SD3 files as the full paid versions of Wolfenstein 3D/Spear of Destiny but all versions of 4.11.x have so far just recognised them as shareware/demos. The WL6/SOD/SD2 & SD3 files were all taken from v1.4 DosBox versions of these games.

Trying to record GZDoom's loading screen I see that there are red errors for gamemap files having an incorrect hash? I'm not sure what that means or why these were fine for 4.10 but not 4.11 though? Any help/advice would be appreciated.

To make this less confusing because GZDoom does not support any Wolfenstein game, it's about this mod. The issue is a duplicate of this one:
GAMEMAPS.XXX on 4.10-stable vs 4.11-dev
You can read that thread to get an overview of the problem, and why the hashing method stopped working. TL;DR is there was a bug that was fixed but revealed another bug that was also fixed but the hashing code already corrected for the second bug so now it overcorrects and fails.

A new version of the TC should fix this eventually:

Thanks... This was an internal GZDoom fix that unfortunately isn't fully backward compatible with the hashing code I use. I will be pushing a 3.1 release soon to patch this and to resolve a few other issues.

[Professor Hastig]

So the Wads object in ZScript cannot return a lump's length? Well here you get the root cause of the problem...

[Guest]

Many thanks for the replies and explanation. I'll stick with 4.10 until Wolf 3D TC 3.1 comes out and hopefully corrects for the overcorrected bug-fix(es)

[Graf Zahl]

Hopefully, with Wads.GetLumpLength this can be done more robustly.