Mods with dehacked

[ByRntStarOEI]

While I was planning on asking this in my other doom editing topic, I figured it may be better to ask this separately since it's focus is in another area. My question is about mods and how they interact with dehacked patches. So basically playing original or boom compatible maps with dehacked in gzdoom with mods.

 

-Do mods completely overwrite dehacked patches no matter what or does it depend on load order?

 

-Is there a way to prevent custom content from being overwritten by a mod? (For example, using voxel doom works fine with dehacked, but overwrites any custom sprites added to the wad as a replacement. Like a Keen graphic being replaced with a target graphic, but it gets reverted to the voxel Keen as an example)

 

-Is it possible to prevent dehacked patches from being overwritten by mods? (For example, changing the health on a enemy or the function of a thing in your wad by dehacked patches gets change to whatever function the mod has for these. Like running brutal doom reverts the increased health on a dehacked icon of sin back to the normal health as an example.)

 

That's all I have for now.  Let me know if any of my questions are not clear or don't make any sense. Thanks for any help into this matter.

[kalensar]

The short is yes decorate and Zscript can break dehacked patches. Dec and ZSC can make whole new actors and Dehacked achieves its modifying by changing and rewriting the code without making new actors. Its mostly just a symptom that Dehacked is the original way of Modding Doom content from even before Boom Engine was made, and even before ACS was implemented in Hexen,

 

So yeah, when applying mods its best to kind of know if the maps have any dehacked going on and how that can be affected. There are plenty of Maps that use Dehacked that can still have a Mod applied eg Brutal Doom such as Brutal Doom on top of  SunLust, but the big issue would be getting GZDoom to handle Sunlust's shenanigans smoothly to begin with (LOL) 

[Xaser]

The answer is... it's complicated. :P

 

In general, the expectation is that ZScript/DECORATE and DEHACKED don't mix -- but there are some cases where the two work together just fine:

• If the DEHACKED patch just contains strings, it'll work with GZDoom mods just fine. This case is worth mentioning because there are loads of wads out there that use DEH just to update automap map names.
• If the DEHACKED patch strictly only uses the extended state range (e.g. DEHEXTRA or DSDHacked), it'll work with GZDoom mods provided they both don't try and replace the same things -- e.g. my own Vesper is an MBF21 DEHACKED mod that strictly only uses the extended range and only modifies weapons, so it'll work just fine with wads that only modify monsters (even some DEHACKED-based mods, like Valiant).
• Otherwise... it depends. The technical case that causes Big Problems(tm) is when a ZScript/DECORATE actor inherits from an existing actor and the DEHACKED patch modifies that actor's states in some way (this will cause all sorts of chaos) -- and it's very common for oldschool DEHACKED mods to edit the hell out of the state table to do fancy stuff. It's kinda hard to predict, and usually it's easier to just list the cases that do work. :P

 

Unfortunately, there's usually not a way to "fix" these incompatibilities without editing one mod or the other. Either gotta find a patch someone's made, or get your hands dirty and DIY.

[Gez]

Also, modern ZScript-based mods may actually go out of their way to detect if an actor they replace was modified with DEHACKED and then in that case, not replace them anymore to let the dehacked changes take effect. This is done by going through their states and looking for the bDehacked flag.

[Bauul]

I'll also add, and I think this is right, that GZDoom reads mod lumps in the following order:

 

Dehacked

Decorate

ZScript

 

So if you load mods with both Dehacked and Decorate or ZScript, the latter will win out in terms of what gets loaded.

[bofu]

From personal experience: if you're making a Doom wad with new Dehacked actors, it's beneficial to make a separate ZScript or Decorate lump (even if a separate wad) to replace them with equivalents, and not too difficult, especially if you used DecoHack to make your DEHACKED. This will help with compatibility with GZDoom mods. I ended up doing this for the final release of Dominus Diabolicus, and I haven't regretted it.

Edited May 28, 2024 by bofu

[ByRntStarOEI]

I figured that would be the case. It's actually not to big of a deal, I just wanted to see what different options I had, in case I would go the super mod compatible route with my wad (Actually it originally was, until I started playing around with dehacked to do a simple keen change, but then ended up getting carried away messing around with some other actors) Could go the zscript route too, but I was avoiding tinkering around with it for the time being because I know what will happen if I start messing around with it and prefer to keep thing simple at the moment. But this is always something I can look into down the road.

 

 

Now when it comes to textures,sprites,etc. does wad load order determine which is actually loaded? Say you're replacing the original keen with a new graphic in your wad, but then also another mod/wad is loaded that replaces the graphic with a new one. Is the outcome determined by which is loaded first/last or can the use of zscript also come into play?

 

 

Thanks everyone for the info\help. Much appreciated.

 

[Gez]

3 hours ago, ByRntStarOEI said:

Now when it comes to textures,sprites,etc. does wad load order determine which is actually loaded? Say you're replacing the original keen with a new graphic in your wad, but then also another mod/wad is loaded that replaces the graphic with a new one.

Yes, the last one speaking wins.

 

Doom uses a "search from the end" system for retrieving assets, and the files loaded are all put back to back, with the IWAD first, and then the other mods in sequence. So if you load two mods, it'll look for the keen graphics first in mod2, in mod1, and then in IWAD, stopping at the first it finds. So if it finds it in mod2, the versions in mod1 and in the IWAD are never accessed.

 

And likewise, if you have duplicated sprites in the same mod, then it's the one found later in the file that wins; since it searches from the end and will find the one closest to the end first.

 

For textures, it is a bit more complicated because it uses the PWAD and TEXTURE1/TEXTURE2 lumps. This is a common source of problem when loading several resource packs together. If mod2 has textures, then the textures from mod1 will be ignored -- and so will the textures from the IWAD, but usually they're duplicated in mod texture definitions anyway. However, ZDoom-based ports have cumulative loading of texture definition lumps, so they will load all the textures from everything. But other ports don't.

Edited May 29, 2024 by Gez