-nodeh parameter with gzdoom.exe

[Korell]

I found out about the D4V mod from a PCGamer article a couple of days ago and decided to check it out. The author says that the command line to use it should use the -nodeh parameter followed by loading their provided DEH file. I think this is to prevent any DEH from being run from other mods/maps being loaded before the D4V mod itself.

Anyway, is the -nodeh parameter available for gzdoom.exe as I've not found any mention of it anywhere for GZDoom? When should it be used, and does the DEH option in the options menu make the command line parameter obsolete?

[Gez]

I don't even see it listed here...

[Korell]

I don't even see it listed here...

That's why I posted, just in case it is a parameter that isn't made aware in any documentation. Looking at the command line parameters for Chocolate Doom, though, it is present. So it may just be that certain ports have this parameter available but GZDoom doesn't. I know that GZDoom has within the Miscellaneous Options a settings for the loading of DEH and BEX lumps, which I think is set to "Never" by default, so that may be why it has no need for a -nodeh parameter.

[Gez]

I think that setting is for loading deh files that are in a zip (and generally named things like modname.deh instead of dehacked.txt like a lump would be). GZDoom certainly loads deh lumps by default.

[Korell]

GZDoom certainly loads deh lumps by default.

Yes, you are right, I just tested it with "Doom The Way id Did" without loading the additional DEH file, and GZDoom just loaded the DEH that is contained within the PWAD itself.

So, is there a way to stop GZDoom from loading DEH lumps?

The Choocolate Doom Wiki gives the -nodeh parameter description as follows:

-nodeh
Disable automatic loading of Dehacked patches for certain IWAD files.

[3saster]

If I remember correctly, only one Dehacked file can be added at once. As such, the last loaded dehacked file is loaded. Thus loading D4V last should work, but this may cause problems with wads that use dehacked for more than just level names, since stuff like custom monsters from the pwad may not work correctly.

[Phobos867]

Hi, Noiser here (creator of D4V).

Dehacked files actually can be merged (afaik) and that breaks compatibilty with D4V. The -nodeh parameter is used to prevent any dehacked lump from being loaded with the D4V one.

It's possible to add this parameter to GZDoom?

[Gez]

The Chocolate Doom Wiki gives the -nodeh parameter description as follows:

-nodeh
Disable automatic loading of Dehacked patches for certain IWAD files.

Oh, that makes sense then, for things like Freedoom.

Choco, by definition, does not normally load embedded DEHACKED lumps because it's not vanilla behavior. You've got to explicitly load external dehacked files with the -deh parameter; there was just an allowance made for Freedoom and perhaps some other IWADs like Hacx.

[Korell]

If I remember correctly, only one Dehacked file can be added at once. As such, the last loaded dehacked file is loaded. Thus loading D4V last should work, but this may cause problems with wads that use dehacked for more than just level names, since stuff like custom monsters from the pwad may not work correctly.

Checking with some PWADs, like Doom 2 The Way id Did, loading them before D4V, in the GZDoom console it shows entries for three sets of DEH files being loaded.
Firstly, D4V.deh, then from within D2TWID.wad, and then from within D4V.wad.
The command line I'm using to launch this is:

START gzdoom.exe -iwad doom2.wad -file D2TWID.WAD D4V.wad MAP07fix\fD2TWID.WAD -nodeh -deh D4V.deh

So the -nodeh is not stopping it from loading the DEHACKED patch from within D2TWID, and it also seems that the D4V DEHACKED patch exists within the PWAD and the DEH file.

[Phobos867]

Choco, by definition, does not normally load embedded DEHACKED lumps because it's not vanilla behavior. You've got to explicitly load external dehacked files with the -deh parameter; there was just an allowance made for Freedoom and perhaps some other IWADs like Hacx.

It's not necessary on choco, but this parameter also works on crispy, prBoom and possibly other ports as well.

[Korell]

Still wish this -nodeh parameter was present for GZDoom as it is my preferred source port.

[Redneckerz]

Still wish this -nodeh parameter was present for GZDoom as it is my preferred source port.

That parameter, as i read it, will have to rely on the edge cases Gez mentioned.

[Rachael]

Still wish this -nodeh parameter was present for GZDoom as it is my preferred source port.

Then it's gotta go to a forum like this one.