General Questions on DeHackEd

[Ed the Bat]

If DeHackEd already works the way it's supposed to in ZDoom, then brilliant; no problem to address at all.

I had originally been under the impression that only one DeHackEd patch could be loaded at one time, and loading one would prevent any loaded afterwards from working at all. But, to be fair, I could be thinking of an older instance, and things could've certainly changed when I wasn't looking. I don't know the technical aspects well enough to investigate it on my own.

I was mainly concerned because Fraggle said some things that supported my fear that only one DeHackEd would work at once in ZDoom.

You're correct that it breaks some mods. That's actually down to bugs in source ports rather than Freedoom. For example, some source ports load dehacked patches in the wrong order, so that the IWAD DEHACKED lump is applied after patches specified on the command line, or in PWADs. Loading of patches needs to be carefully ordered in order to make sense: I described the required ordering back when we added the patch.

As a workaround, you could use a WAD editing tool to remove the lump from your copy of the IWAD. I know that's a pretty shitty workaround but it's a solution at least. Other than that, file a bug / complain to the authors of your preferred source port, to try to get them to fix their dehacked behavior.

For example, this should do the sensible thing:
code:
doom -iwad (freedoom iwad) -file batman.wad -deh batman.deh

In this scenario, the order should be:
IWAD is loaded
DEHACKED lump inside IWAD is loaded
External dehacked patches are loaded (-deh on command line)
External PWAD(s) are loaded
DEHACKED lumps inside PWADs are loaded

With the current setup in PrBoom+, the ordering is:
IWAD is loaded
External dehacked patches are loaded (-deh on command line)
External PWAD(s) are loaded
DEHACKED lump is loaded, either from PWAD or IWAD (only a single lump is supported)


The Batman Doom example therefore doesn't work because the DEHACKED lump is loaded last, overriding the patch specified on the command line.

Now, if my concerns are incorrect or outdated, then the issue can be put to rest right now. The long and short of it all is: if something in ZDoom isn't working how it 'should' work, then I feel it's at least worthy of investigate. But if everything's in order, then I'm good.

[Gez]

I don't see any mention of ZDoom specifically in Fraggle's post. However, there is a specific mention of PrBoom+ failing it.

[Ed the Bat]

True he didn't mention ZDoom, but I personally had problems in the past trying to load more than one WAD with DeHackEd lumps in them. And ZDoom is at least partially descended from Boom, right?

To be fair there is a technical challenge here due to the way that the Boom Dehacked parser works (see Quasar's post earlier in the thread). The Boom Dehacked parser (used in Prboom, Eternity, etc) doesn't correctly handle the case where a string is changed by one patch and the same string then changed by a different patch (Dehacked works by replacing one string value with another one, and the "string to change from" has been changed from the original).

Personally I think this is just a technical bug that needs to be solved. It's a long-running bug in the way that the Boom-derived ports handle Dehacked string replacements and deserves to be fixed in its own right anyway.

[Gez]

And ZDoom is at least partially descended from Boom, right?

Mostly wrong.

ZDoom has ported some Boom/MBF code, but it's not ultimately derived from it. And ZDoom's DEHACKED code is completely different from Eternity's. I haven't looked at Boom's DEH code, but it's probably different still, given how much of EE's code has been rewritten and reorganized.

ZDoom's DEH support code was written by Randy and is structured around an external data file, [wiki]DEHSUPP[/wiki], as well as based on the SC_MAN scanner originally from Hexen (where it was used to parse the MAPINFO, SNDINFO, etc. lumps). These two things alone make it impossible for ZDoom's DEH support to have been based on the Boom code: different underlying methods and different architectural approach.

And as Worst showed: PrBoom+: fails; MBF: fails; Doom Legacy: fails; Eternity: works; ZDoom: works.

[Ed the Bat]

Hmm, ok. So ZDoom's methods for tackling DeHackEd are pretty independent of the other ports, then? I guess other ports having problems would be no reason for me to be concerned, then.

Now, my memory does get worse as I get older, but I could swear there was a time when trying to load two DeHackEd patches in ZDoom simultaneously simply wouldn't work. But, I know the engine is a constant work in progress, and things grow/get fixed, sometimes without me noticing. As things stand right now, I'm really not seeing the conflicts I used to see. So, I'm fairly sure the issue existed in ZDoom at SOME point in history, but... if it doesn't exist anymore, I'm happy with it.

[Gez]

Things that will always conflict: two DEHACKED patches changing the same actor.

Things that will never conflict: two DEHACKED patches changing the same string.
Two or more DEHACKED patches changing completely different stuff, like one changes strings and the other changes actors and the third changes max ammo amounts or whatever...

[Ed the Bat]

Makes sense to me. So, like most things in life, if two things move towards the same goal, don't be too shocked if they happen to bump into one another.

So then, it looks like ZDoom is already handling DeHackEd in essentially the most ideal fashion possible. Beautiful.

Thanks very much for your input, everyone!

[randi]

I feel I should correct this before it gets repeated elsewhere:

ZDoom's DEH support code was . . . based on the SC_MAN scanner originally from Hexen

ZDoom's Dehacked support predates the Hexen source release, so it couldn't possibly have used routines from Hexen's sc_man.c. Instead, it is it's own specialized line-based parser, as described in the comments in the Dehacked source code. (Too bad Boom's BEX extensions kind of threw Dehacked's conventions out the window, so they had to be shoehorned in.)

[Gez]

Oh, yeah, the FScanner is only used by LoadDehSupp().

[Ed the Bat]

Ok, bit of a tangent here, but I got a quick question. I understand the circumstances that can lead to conflicts when using two DeHackEd patches... but let's pretend something else for a second here.

Let's say I have both a DeHackEd lump and a LANGUAGE lump loaded in a session of ZDoom. Both of them redefine one of the existing strings. Which one, between the DeHackEd and the LANGUAGE, will 'win'? Does one take precedent over the other, or is it dependent on the order they were loaded?

[Gez]

DEHACKED wins. LANGUAGE lumps are actually the very first type of lump that is loaded. There are good technical reasons for why it couldn't work the other way around, first of all being that the strings that may be replaced by DEHACKED must first be known about, and they are in a language file in zdoom.pk3.

Also, MAPINFO, DECORATE, ACS scripts, Strife conversations... may refer to LANGUAGE strings, so they have to be loaded before any of these other things.

[Ed the Bat]

Makes sense to me. So, I guess in terms of Freedoom, going with DeHackEd means they forfeited some compatibility with mods that use LANGUAGE for strings. Of course, that's the kind of thing that can happen with so many different ports out there. But, that's an issue for them to figure out, I suppose. Everything's working as it's expected to, from a technical standpoint.

[NeoSpearBlade]

Sorry for the almost 2-month-old bump but due to this thread's title, I assume I can ask this question.

Apparently, this was already asked years ago (sorta) but it was never answered so I'll ask it again.

Whenever I set a .DEH or .BEX file for the autoload in the .INI file, it never loads it, but when I drag-and-drop it over the executable, it DOES load it.

Why are those file types ignored from the autoload? Or am I doing something wrong?

[Ed the Bat]

Y'know, I've noticed a similar issue with those. I know of some old mods with external .bex and .deh patches, and the .bex contains an Include directive to launch the .deh, but it always loads with an error, saying it couldn't be done. The .deh has to be manually loaded alongside the .bex, which works just fine. I don't know why it can't load the file with the Include directive when it can clearly load the file manually.