-nodeh parameter with gzdoom.exe
Moderator: GZDoom Developers
-nodeh parameter with gzdoom.exe
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?
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?
Re: -nodeh parameter with gzdoom.exe
I don't even see it listed here...
Re: -nodeh parameter with gzdoom.exe
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 wrote:I don't even see it listed here...
Re: -nodeh parameter with gzdoom.exe
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.
Re: -nodeh parameter with gzdoom.exe
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.Gez wrote:GZDoom certainly loads deh lumps by default.
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.
Re: -nodeh parameter with gzdoom.exe
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.
Re: -nodeh parameter with gzdoom.exe
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?
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?
Re: -nodeh parameter with gzdoom.exe
Oh, that makes sense then, for things like Freedoom.Korell wrote: The Chocolate Doom Wiki gives the -nodeh parameter description as follows:
-nodeh
Disable automatic loading of Dehacked patches for certain IWAD files.
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.
Re: -nodeh parameter with gzdoom.exe
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.3saster wrote: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.
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.
Re: -nodeh parameter with gzdoom.exe
It's not necessary on choco, but this parameter also works on crispy, prBoom and possibly other ports as well.Gez wrote:Korell wrote: 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.
Re: -nodeh parameter with gzdoom.exe
Still wish this -nodeh parameter was present for GZDoom as it is my preferred source port.
- Redneckerz
- Spotlight Team
- Posts: 1053
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
Re: -nodeh parameter with gzdoom.exe
That parameter, as i read it, will have to rely on the edge cases Gez mentioned.Korell wrote:Still wish this -nodeh parameter was present for GZDoom as it is my preferred source port.
Re: -nodeh parameter with gzdoom.exe
Then it's gotta go to a forum like this one.Korell wrote:Still wish this -nodeh parameter was present for GZDoom as it is my preferred source port.