-nodeh parameter with gzdoom.exe

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 ON
[img] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: -nodeh parameter with gzdoom.exe

Re: -nodeh parameter with gzdoom.exe

by Rachael » Wed Mar 11, 2020 4:22 pm

Korell wrote: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.

Re: -nodeh parameter with gzdoom.exe

by Redneckerz » Wed Mar 11, 2020 4:11 pm

Korell wrote: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.

Re: -nodeh parameter with gzdoom.exe

by Korell » Wed Mar 11, 2020 2:23 pm

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

Re: -nodeh parameter with gzdoom.exe

by Phobos867 » Fri Sep 13, 2019 11:20 pm

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.
It's not necessary on choco, but this parameter also works on crispy, prBoom and possibly other ports as well.

Re: -nodeh parameter with gzdoom.exe

by Korell » Wed Sep 04, 2019 1:26 pm

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

Re: -nodeh parameter with gzdoom.exe

by Gez » Wed Sep 04, 2019 1:41 am

Korell wrote: 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.

Re: -nodeh parameter with gzdoom.exe

by Phobos867 » Wed Sep 04, 2019 12:59 am

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?

Re: -nodeh parameter with gzdoom.exe

by 3saster » Tue Sep 03, 2019 4:05 pm

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

by Korell » Tue Sep 03, 2019 3:40 pm

Gez wrote: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.

Re: -nodeh parameter with gzdoom.exe

by Gez » Tue Sep 03, 2019 3:18 pm

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

by Korell » Tue Sep 03, 2019 12:16 pm

Gez wrote: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.

Re: -nodeh parameter with gzdoom.exe

by Gez » Tue Sep 03, 2019 6:31 am

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

-nodeh parameter with gzdoom.exe

by Korell » Tue Sep 03, 2019 6:01 am

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?

Top