[zdoom 2.8.1] multiple internal dehacked lumps

[TimeOfDeath666]

Is there a way for me to specify which internal dehacked lump gets loaded in zdoom 2.8.1? The deh settings in the miscellaneous options menu didn't seem to do anything for that.

I was playing a 9 year old wad with two internal dehacked lumps in zdoom 2.8.1 and noticed that data from both lumps was being loaded, instead of only using the last lump (which was the original intent). I've never noticed this before and traced the change back to zdoom 2.4.0 where versions prior to that only seemed to load the last lump.

[Graf Zahl]

The change was orignally made to process all Dehacked lumps if multiple files are loaded, I guess this special case was never considered.

Of course with 2.8.1 your only option is to load a WAD editor and delete the unwanted one.

 

[scifista42]

I've been thinking about making a wad containing multiple DEHACKED lumps: One with custom monsters, one with custom weapons, one with custom non-interactive decorations, and one with strings for map names on the automap. The DEHACKED lumps would be intended to all take effect together, but designed such that deleting any one of them wouldn't break the others in their respective functions. The wad's textfile would contain these instructions: "If you want to play this wad with stock monsters instead of custom ones, or with a gameplay mod that affects monsters, open the wad in an editor and delete the first DEHACKED lump. If you want to play this wad with stock weapons instead of custom ones, or with a gameplay mod that affects weapons, open the wad in an editor and delete the second DEHACKED lump."

 

I thought it'd be a nice way of letting people play the game as they want - the maps would be designed with custom content in mind, therefore the custom content would be included within the wad itself rather than loadable separately, but there'd be a relatively easy way of disabling the custom content by deleting one or more of the DEHACKEDs. But if the engine only loaded the last DEHACKED lump in a wad, this wouldn't be possible.

Edited April 6, 2017 by scifista42

[kb1]

It's a shame that you cannot have multiple DeHackEd patches, possibly distributed in multiple wads, each with a DeHackEd lump, as well as the resources used by that DeHacked lump. You know, one wad for custom monsters, one for decorations, etc. But that's what DECORATE/ZScript is for, right? Come to think of it, I don't think there's any technical reason why the loading of multiple DeHackEd patches wouldn't work, with careful coding. I guess ZDoom is the only port that does it, though.

 

You can always bundle several DeHackEd files with your wad (or near dups of your wad), providing every combination of the three options you describe. That's 8 for all combinations of 3 options, which wouldn't be so bad for a smallish wad. But, adding any more options could quickly become an unwieldy solution.

Edited April 6, 2017 by kb1
accuracy

[RjY]

16 hours ago, Graf Zahl said:

The change was orignally made to process all Dehacked lumps if multiple files are loaded

Even PrBoom+ does this now -- IIRC, it was requested by Freedoom to support their dehacked in IWAD.

[kb1]

14 hours ago, RjY said:

Even PrBoom+ does this now -- IIRC, it was requested by Freedoom to support their dehacked in IWAD.

I guess, compatibility-wise, this is ok - it's synonymous with merging multiple dehacked patches, and then applying them to the vanilla .exe. Or even, applying multiple patches to the same .exe. Of course, not all patches will work this way. With text strings, I think dehacked.exe actually searched the .exe to find the text to replace. Obviously, this could not be done more than once for the same text string, as the original text would have been replaced already. Source ports may or may not decide to bypass this issue.

 

Now would be a good time to resurrect the Doom Standards Committee :)

[RjY]

10 minutes ago, kb1 said:

I guess, compatibility-wise, this is ok - it's synonymous with merging multiple dehacked patches, and then applying them to the vanilla .exe. Or even, applying multiple patches to the same .exe. Of course, not all patches will work this way. With text strings, I think dehacked.exe actually searched the .exe to find the text to replace. Obviously, this could not be done more than once for the same text string, as the original text would have been replaced already. Source ports may or may not decide to bypass this issue.

Indeed, there was the notable case of All Hell Breaks Loose, which actually swaps two strings. Dehacked must have matched the string against the original from the exe not the replacement, or swaps wouldn't work. This was a long-standing bug in the Boom dehacked parser which matched BOSS in sprnames[] and rewrote it to BOS2 -- so now there are two BOS2 entries -- then tried to match BOS2, thus finding the first one it had just replaced instead of the second one, and set it back to BOSS. Final outcome, nothing changed.

 

10 minutes ago, kb1 said:

Now would be a good time to resurrect the Doom Standards Committee :)

Haha it wouldn't last five minutes :p

[kb1]

12 minutes ago, RjY said:

Indeed, there was the notable case of All Hell Breaks Loose, which actually swaps two strings. Dehacked must have matched the string against the original from the exe not the replacement, or swaps wouldn't work. This was a long-standing bug in the Boom dehacked parser which matched BOSS in sprnames[] and rewrote it to BOS2 -- so now there are two BOS2 entries -- then tried to match BOS2, thus finding the first one it had just replaced instead of the second one, and set it back to BOSS. Final outcome, nothing changed.

 

Haha it wouldn't last five minutes :p

Heh - I wasn't sure anyone would get what I was trying to type :) All Hell Breaks Loose: I wanted to like that green devil guy, but, meh. I'll have to try that dehacked patch - should be on a list of mandatory testing!

 

Committee: Yeah, right now we have lots of committees of one. Seems like that's as good as it gets.