noobish question about complevels' backward compatibility

[liPillON]

Are they backwards compatible?

Meaning that each one is a strict superset (eg: new features only, no changes in previously existing ones) of the previous one?

 

Let's say that I'd like to play some doom, combining:

- a mapset exploiting most boom mapping features and sporting some custom bex monsters

- a weaponset powered by mbf features (eg: minicharge)

 

I would consider the risk of conflicts negligible, since the things modified by both pwads do not overlap.

I would then use prboom/dsda/woof with -complevel 11, loading the weaponset after the mapset.

 

Would this result in unintended map/monster behaviour, due to MBF overriding Boom-specific features?

 

I've checked the wiki without being able to find any explicit compatibility matrix or side-by-side comparison chart.

The only thing I'm sure about is MBF21 being backward-compatible with MBF, since that was one of its design goals.

 

 

NOTE:

I'm aware that different complevels usually imply changes in behaviour due to engine bugs being fixed in later releases.

Let's put those aside for a moment.

 

Edited February 23, 2023 by Delfino Furioso : changed the title to clarify the topic's subject

[thelamp]

33 minutes ago, Delfino Furioso said:

Are they backwards compatible?

Meaning that each one is a strict superset (eg: new features only, no changes in previously existing ones) of the previous one?

no

 

33 minutes ago, Delfino Furioso said:

Let's say that I'd like to play some doom, combining:

- a mapset exploiting most boom mapping features and sporting some custom bex monsters

- a weaponset powered by mbf features (eg: minicharge)

unfortunately dehacked patches are not modular, there's no simple way to "combine" them. you'd have to manually build just 1 patch that has what you want

 

33 minutes ago, Delfino Furioso said:

I would consider the risk of conflicts negligible, since the things modified by both pwads do not overlap.

I would then use prboom/dsda/woof with -complevel 11, loading the weaponset after the mapset.

 

Would this result in unintended map/monster behaviour, due to MBF overriding Boom-specific features?

this simply won't work, even if the dehacked patches don't conflict it's only gonna use 1 of them

 

there are cases where two dehacked patches are loaded but that has to do with one of them being for strings (mapnames and such)

[pantheon]

This MBF21 Spec page seems like a good reference for the different levels and options. I am not as familiar with the specifics of the mod files but if you were going to play a CL9 mapset in CL11, you'd have some different behaviors by default like delayed infighting. But since 11 lets you change a lot more compatibility settings, I'd just copy the Boom settings from that page as much as possible.

[liPillON]

36 minutes ago, thelamp said:

unfortunately dehacked patches are not modular, there's no simple way to "combine" them.

you'd have to manually build just 1 patch that has what you want

hmm..

Does this limitation affect embedded dehacked lumps too?

I was under the impression that only .deh files loaded using the -deh parameter were processed this way.

 

[thelamp]

12 minutes ago, Delfino Furioso said:

hmm..

Does this limitation affect embedded dehacked lumps too?

I was under the impression that only .deh files loaded using the -deh parameter were processed this way.

 

 

far as I know, an embedded patch is gonna behave the same as one loaded separately. the only reason to load separately is for using vanilla-compat ports like choco (or vanilla itself)

 

[liPillON]

ok let's semplify the scenario:

- a mapset with no deh/bex lumps, exploiting some boom mapping features (eg: animated switches, scrollin walls, conveyor belts, friction) 

- a gameplay mod powered by mbf features (eg: minicharge, altering monsters and weapons appearance/behaviour)

 

would running in complevel 11/21 inhibit boom-specific map features?

 

[Bauul]

36 minutes ago, Delfino Furioso said:

would running in complevel 11/21 inhibit boom-specific map features?

 

As far as my understanding goes, the typical differences between when going backwards through complevels are how the engine treats different situations as they occur in game, it's not about having different features specifically available only in certain older complevels.

 

In other words, all the Boom mapping features will be recognized when playing on the latest complevel (for example), but how the game handles those features may change slightly. AFAIK, there are no Boom features that only work on lower complevels. If I were you, I would target the highest complevel you need to for the features you're trying to use, and design the level around how all Boom features behave in that complevel. 

 

1 hour ago, Delfino Furioso said:

Does this limitation affect embedded dehacked lumps too?

 

Yes. It helps to think about what Dehacked files functionally are: they're a list of instructions for modifying the exe. They tell the source port to "change A to D and B to Z" etc. If you load two files, you'll have two conflicting sets of instructions. Typically whichever is loaded last will be the one that gets applied. There's only one exe running the game, so generally you can only have one active set of instructions.

 

The exception is where you have multiple Dehacked files that each cover separate parts of the exe, for example one that modifies map names and another that modifies enemies. That way there are no individual conflicting instructions so everything gets applied correctly. It's tricky to confidently apply such combinations of Dehacked files unless you are completely confident what's in each though.

[Ludi]

Don't feel bad about not knowing, complevel differences are often arbitrary. It's a case where you know it when you see it. Like Bauul said, most differences lie in DeHacked with Boom being the main exception to that rule.

 

Here's the most obvious guide, and probably the most digestible. 

 

 

[magicsofa]

24 minutes ago, Bauul said:

If I were you, I would target the highest complevel you need to for the features you're trying to use, and design the level around how all Boom features behave in that complevel. 

 

I think OP is just trying to play a map with a separate weapon mod, not design one. In which case... @Delfino Furioso do you have a specific map/mod combination in mind that you could tell us? It might be easier to answer the question that way, especially if people have experience playing or working on those projects.

 

You mentioned MBF21 being backwards compatible with MBF... that just means that nothing from MBF should be broken in MBF21. If the mod is using MBF21 features, then you need to be running complevel 21 anyway. There shouldn't be any issue with "normal" Boom features (all the way from 1998!). The only issue I would expect to run into is if the mapset/custom monsters in question uses any bug exploits that were later fixed.

[liPillON]

25 minutes ago, Bauul said:

The exception is where you have multiple Dehacked files that each cover separate parts of the exe, for example one that modifies map names and another that modifies enemies. That way there are no individual conflicting instructions so everything gets applied correctly. It's tricky to confidently apply such combinations of Dehacked files unless you are completely confident what's in each though.

ok this is what I always thought would happen, thank you for elaborating on it

so when a specific string/frame/codepointer is modified by multiple dehacked patches, only the changes made by the one loaded last will occur

on the other hand, if there is no overlap between the strings/frames/codepointers affected by each deh file, all will probably work as expected

 

 

[liPillON]

5 minutes ago, magicsofa said:

 

I think OP is just trying to play a map with a separate weapon mod, not design one. In which case... @Delfino Furioso do you have a specific map/mod combination in mind that you could tell us? It might be easier to answer the question that way, especially if people have experience playing or working on those projects.

 

You mentioned MBF21 being backwards compatible with MBF... that just means that nothing from MBF should be broken in MBF21. If the mod is using MBF21 features, then you need to be running complevel 21 anyway. There shouldn't be any issue with "normal" Boom features (all the way from 1998!). The only issue I would expect to run into is if the mapset/custom monsters in question uses any bug exploits that were later fixed.

 

well I'm interested in a generic rule of thumbs but I'm slowly realizing that there's a bunch of things that should be accounted for, so a definitive answer will probably never come.. 

 

anyway, I've summarized the options described in the MBF21 specification in the following table

green cells are "safe features" meaning they should behave the same across all complevels

blue cells are "complevel-specific" features that might lead to incompatibilities

Spoiler

 

I would guess that using a MBF/MBF21 mod (Minicharge by Tango) or a MBF21 mod (Vesper by Xaser)

would then break CL9/CL3/CL2 mapsets relying on monster NOT avoiding hazards

 

[magicsofa]

1 hour ago, Delfino Furioso said:

I would guess that using a MBF/MBF21 mod (Minicharge by Tango) or a MBF21 mod (Vesper by Xaser)

would then break CL9/CL3/CL2 mapsets relying on monster NOT avoiding hazards

 

Well sure but that's because you have added a feature that changes the behavior of monsters, then loaded a map that depends on the old behavior. It's not because of the complevel and it isn't even really "broken." I think you are overestimating the importance of complevels in general. The main purpose is to allow demos to be properly played back from earlier versions of the engine/port. For example, I can use prboom to view a demo that was recorded with doom.exe, as well as boom.exe and so on.

 

For regular play (i.e. not recording demos or bug hunting) you should just use what is recommended by the mod itself. When mixing mods, the rule of thumb is "stuff might break and there's nothing you can do about it short from fixing the conflict yourself."

[banjiepixel]

Complevels should be mostly separate from dehacked compatibility, for example Crispy Doom doesn't have support for Boom/MBF maps but Minicharge does work anyway as MBF bex features are supported. As far as I know, it is basically just like how GZDoom gameplay mods work even with compatibility mode set to "Doom (strict)". I have no experience from more recent dehacked variations like MBF21 but generally Complevels are only for the maps themselves. As long as there no conflicting dehacked code, they should mostly work on any complevel as long as the source port has a support for the required dehacked format.

 

Use the complevel that the map is meant for, it's very rare that mods would be broken by "wrong complevel", at worst, there should only be very minor changes from intended functionality.

[Shepardus]

1 hour ago, banjiepixel said:

Complevels should be mostly separate from dehacked compatibility, for example Crispy Doom doesn't have support for Boom/MBF maps but Minicharge does work anyway as MBF bex features are supported. As far as I know, it is basically just like how GZDoom gameplay mods work even with compatibility mode set to "Doom (strict)". I have no experience from more recent dehacked variations like MBF21 but generally Complevels are only for the maps themselves. As long as there no conflicting dehacked code, they should mostly work on any complevel as long as the source port has a support for the required dehacked format.

 

Use the complevel that the map is meant for, it's very rare that mods would be broken by "wrong complevel", at worst, there should only be very minor changes from intended functionality.

Complevel does affect DeHackEd; for example, Valiant's monsters won't work correctly if you use complevel 9 instead of 11 due to the code pointers it uses (arachnotrons won't spawn arachnorbs).

[banjiepixel]

16 minutes ago, Shepardus said:

Complevel does affect DeHackEd; for example, Valiant's monsters won't work correctly if you use complevel 9 instead of 11 due to the code pointers it uses (arachnotrons won't spawn arachnorbs).

 

Why would a source port alter DeHackEd functionality based on complevel? As far as I know, MBF21 DeHackEd functions by default just like the classic 1.9 DeHackEd so everything that can be done with 1.9, should be possible to replicate 100% accurately with MBF21 DeHackEd code. So I fail to see any good reason for why complevel 9 would disable any MBF DeHackEd functionality. I also have not seen this happen in any source port that I have used.

 

And it does seem to be problem very rarely since you are supposed to use complevel 11 with Valiant anyway and I would say that a monster not being able to use it's attack is pretty minor issue. And you would generally use the Vacinated Edition instead with gameplay mods anyway.

[dististik]

12 minutes ago, banjiepixel said:

Why would a source port alter DeHackEd functionality based on complevel?

 

Because some ports or standards add things to the patch that don't exist in earlier/older ports or standards. Boom's ability to reassign actions to any state can't be applied to vanilla, MBF's unique code pointers (actions that things in a level can do) didn't exist in Boom, and likewise MBF21's new code pointers didn't exist in MBF.

[Shepardus]

2 minutes ago, banjiepixel said:

 

Why would a source port alter DeHackEd functionality based on complevel? As far as I know, MBF21 DeHackEd functions by default just like the classic 1.9 DeHackEd so everything that can be done with 1.9, should be possible to replicate 100% accurately with MBF21 DeHackEd code. So I fail to see any good reason for why complevel 9 would disable any MBF DeHackEd functionality. I also have not seen this happen in any source port that I have used.

 

And it does seem to be problem very rarely since you are supposed to use complevel 11 with Valiant anyway and I would say that a monster not being able to use it's attack is pretty minor issue. And you would generally use the Vacinated Edition instead with gameplay mods anyway.

Complevels aren't "only for the maps themselves"; their purpose is to preserve demo compatibility, which means they can affect all aspects of the game, including the game physics and miscellaneous bugs being fixed (or introduced!). Higher complevels don't strictly add features; existing behavior can change, too. Disabling features of higher complevels is also an aspect of compatibility; otherwise a complevel 2 demo recorded in PrBoom+ may not play back in Crispy Doom or vanilla.

 

Not sure what you mean by "you are supposed to use complevel 11 with Valiant anyway," since the DeHackEd is the reason why you're supposed to use cl11 in the first place. Same with Eviternity; the final boss won't function at all in cl9, and I'd say that's not a "pretty minor issue."

[banjiepixel]

31 minutes ago, dististik said:

 

Because some ports or standards add things to the patch that don't exist in earlier/older ports or standards. Boom's ability to reassign actions to any state can't be applied to vanilla, MBF's unique code pointers (actions that things in a level can do) didn't exist in Boom, and likewise MBF21's new code pointers didn't exist in MBF.

 

Yes, I know that DeHackEd formats are not forwards compatible but it would only make sense that patches using newer formats should be backwards compatible with lower complevels. I mean, what if I want to use MBF21 gameplay mod with complevel 2 map and be able to have vanilla gameplay outside of the specific changes that the MBF21 gameplay is only DeHackEd format able to make possible? It is just a good idea keep complevel and DeHackEd functionality completely separate. Especially since it seems to me that newer standards lack nothing that the older standards have and only expand what is possible unlike complevels that come with actual changes to the basic functionality of the game.

 

Just like how Crispy Doom supports MBF DeHackEd patches but doesn't support actual Boom or MBF maps and has no complevels for them. If what you say is correct, wouldn't it mean that Crispy should be able to only support Vanilla 1.9 DeHackEd format instead of having also Boom and MBF DeHackEd support?

[liPillON]

I like how this discussion is evolving

I've slightly changed the topic's title, hopefully this will bring more people here

[dististik]

31 minutes ago, banjiepixel said:

I mean, what if I want to use MBF21 gameplay mod with complevel 2 map and be able to have vanilla gameplay outside of the specific changes that the MBF21 gameplay is only DeHackEd format able to make possible?

 

If the CL2 map didn't have its own DeHackEd, I think it'd mostly play nice, sure. That said, there's always the obvious asterisk of since the map wasn't designed with gameplay mods or MBF21 in mind there could be any litany of issues.

 

32 minutes ago, banjiepixel said:

If what you say is correct, wouldn't it mean that Crispy should be able to only support Vanilla 1.9 DeHackEd format instead of having also Boom and MBF DeHackEd support?

 

Admittedly I'm not especially familiar with Crispy but it seems to take a different approach to DeHackEd than PrBoom+ related ports. The -complevel parameter explicitly emulates a certain port/standard so if you use -complevel 2 in PrBoom+, DSDA-Doom, or Woof! but load a BEX patch it won't work because Doom 1.9 doesn't have the features the former introduced.

[banjiepixel]

1 minute ago, Shepardus said:

Complevels aren't "only for the maps themselves"; their purpose is to preserve demo compatibility, which means they can affect all aspects of the game, including the game physics and miscellaneous bugs being fixed (or introduced!). Higher complevels don't strictly add features; existing behavior can change, too. Disabling features of higher complevels is also an aspect of compatibility; otherwise a complevel 2 demo recorded in PrBoom+ may not play back in Crispy Doom or vanilla.

 

Not sure what you mean by "you are supposed to use complevel 11 with Valiant anyway," since the DeHackEd is the reason why you're supposed to use cl11 in the first place. Same with Eviternity; the final boss won't function at all in cl9, and I'd say that's not a "pretty minor issue."

 

Again, using external DeHacked patch to alter the gameplay from the intended default of the map voids the demo compatibility anyway. It shoudn't matter if it is vanilla 1.9 patch with MBF21 map and complevel 21 or MBF21 patch or 1.9 vanilla map with complevel 2. We are talking about here mixing maps made for specific complevel with gameplay mods with different "complevel" and DeHacked format. If I load up Alien Vendetta using complevel 2 with Tango's Minicharge, it does imply that I want complevel 2 gameplay for anything else but the stuff that Minicharge changes with it's MBF format DeHacked patch.

 

This is how Crispy Doom functions and as far as I know, ZDoom based source ports behave this way too.

 

If the source port would use the maximum supported level of DeHackEd format no matter the complevel, Valiant's and Evilternity's crappy DeHackEd monsters wouldn't break while also lower complevels working just like they should as long as no advanced extra features using DeHackEd patch is loaded, something you would only ever do on purpose. It's a bad idea to limit DeHackEd features based on complevel. Does complevel 2 map become suddenly a MBF map if I place 1 monster using MBF format in it?

[dististik]

4 minutes ago, banjiepixel said:

If the source port would use the maximum supported level of DeHackEd format no matter the complevel, Valiant's and Evilternity's crappy DeHackEd monsters wouldn't break

 

You're misunderstanding what DeHackEd is on a fundamental level here. When you apply a patch, whether that be by editing the DOS executable or load it embedded in a WAD file, you only get one. The bigger reason you couldn't load Valiant or Eviternity with Minicharge or Vesper is because either the entire set's DeHackEd would be superceded or your gameplay mod wouldn't load.

 

6 minutes ago, banjiepixel said:

Does complevel 2 map become suddenly a MBF map if I place 1 monster using MBF format in it?

 

Yes.

[banjiepixel]

4 minutes ago, dististik said:

 

You're misunderstanding what DeHackEd is on a fundamental level here. When you apply a patch, whether that be by editing the DOS executable or load it embedded in a WAD file, you only get one. The bigger reason you couldn't load Valiant or Eviternity with Minicharge or Vesper is because either the entire set's DeHackEd would be superceded or your gameplay mod wouldn't load.

 

What are you talking about. Most source ports do allow to load as many patches as you want. I have used my own DeHackEd modifications with Valiant and Evilternity just fine, not any different from loading Brutal Doom or Complex Doom with those megawads. Literally the only problem comes when the patches make overlapping changes and cause the last loaded patch to replace something important from patches loaded before it.

 

I do have a habit of combining all the separate patches I make into one but that is literally just to make loading that set of DeHackEd modifications easier.

 

DeHackEd patches can be pretty modular. You can use several separate patches to alter many defined values of the same thing and ovewrite previous values easily. You can even alter some functionality of Decorate actors with DeHackEd. You make weapon switching faster with DeHackEd and it will work with any Decorate weapons replacing the original ones as long they do not define their own weapons switching using Decorate and instead use the default weapon switching definitions.

[Shepardus]

39 minutes ago, banjiepixel said:

Again, using external DeHacked patch to alter the gameplay from the intended default of the map voids the demo compatibility anyway.

Why would it? You can still record demos when loading a DeHackEd patch, and it'd be expected to play back when loading the same patch. That external DeHackEd patch could just as well be an internal one integral to the WAD. There isn't a distinction between "map complevel" and "gameplay complevel" like you're making there out to be.

[banjiepixel]

41 minutes ago, dististik said:

 

Admittedly I'm not especially familiar with Crispy but it seems to take a different approach to DeHackEd than PrBoom+ related ports. The -complevel parameter explicitly emulates a certain port/standard so if you use -complevel 2 in PrBoom+, DSDA-Doom, or Woof! but load a BEX patch it won't work because Doom 1.9 doesn't have the features the former introduced.

 

Original Doom 1.9 didn't have DeHackEd, you had to literally hack the executable to make changes so how CL2 having a DeHackEd support at all is any different from for example simulating Doom 1.9 functionality with MBF features added in? If no actual MBF features are used, gameplay should be exactly like the original Doom 1.9 and when you use MBF featires, it would only be like using hacked Doom 1.9 executable with those features added into it. Should CL2 also crash the source port with limit removing maps just like original Doom 1.9 did?

[banjiepixel]

9 minutes ago, Shepardus said:

Why would it? You can still record demos when loading a DeHackEd patch, and it'd be expected to play back when loading the same patch. That external DeHackEd patch could just as well be an internal one integral to the WAD. There isn't a distinction between "map complevel" and "gameplay complevel" like you're making there out to be.

 

What if I want to record a demo of my MBF format gameplay mod with CL2 map? I could do this with Crispy Doom but seems that I can't do this with the source port that you are using. Why is that your source port forces me to use wrong CL just because of my gameplay mod? Wouldn't there be more freedom if you could mix and match map complevels with more advanced DeHacked support levels? Valiant can be very easily made into CL 9 mapset with some wad editing or patching nothing is gained by MBF DeHacked not working correctly on complevel 9.

[Shepardus]

7 minutes ago, banjiepixel said:

 

What if I want to record a demo of my MBF format gameplay mod with CL2 map? I could do this with Crispy Doom but seems that I can't do this with the source port that you are using. Why is that your source port forces me to use wrong CL just because of my gameplay mod? Wouldn't there be more freedom if you could mix and match map complevels with more advanced DeHacked support levels? Valiant can be very easily made into CL 9 mapset with some wad editing or patching nothing is gained by MBF DeHacked not working correctly on complevel 9.

If part of your setup requires MBF then complevel 2 is the wrong complevel to be using, even if the rest of it is vanilla-compatible. Freedom isn't the point of having complevels; if you want freedom, then use complevel 21 and use an OPTIONS lump to set the compatibility flags needed for your map to work. Or just use GZDoom.

[Doomy__Doom]

3 hours ago, banjiepixel said:

Why would a source port alter DeHackEd functionality based on complevel?

The entire point of complevels is to replicate a specific set of behaviors for demos. Complevels aren't trying to make the most reasonable guess as to how it would work if we apply some random parts of a different standard - they're implementing a ruleset and hit you with a proverbial stick if you break it.

 

2 hours ago, banjiepixel said:

Just like how Crispy Doom supports MBF DeHackEd patches but doesn't support actual Boom or MBF maps and has no complevels for them.

That Crispy (and some other excellent ports) go the route of allowing people to combine more stuff easier is irrelevant to prboom/dsda complevels specifically - it's a case of different goals.

You're given several big feature sets that are easy to turn on and against which you can map and record demos that are guaranteed to not desync (at least for for the next 30 years :), and you can bring those demos to other executables that support identical feature sets.

Going back to Valiant - imagine if Prboom allows Valiant dehacked to work on -complevel 9, but Woof does not. Now your -cl9 demo will only work on prboom, which instantly destroys the whole concept of demo compatibility and leads us to zdoom situation on dsda archive.

 

2 hours ago, banjiepixel said:

I mean, what if I want to use MBF21 gameplay mod with complevel 2 map and be able to have vanilla gameplay outside of the specific changes that the MBF21 gameplay is only DeHackEd format able to make possible?

Then you play on higher complevel and accept that things may be bugged and/or work slightly differently compared to original vision if the map was designed around something that's incompatible with <insert your mod's standard> and it's neither map nor mod author's responsibility to fix that. Or choose a different port - GZDoom and Doom Retro would be among some examples that are designed for what you want - to use the "best for the player" settings as much as possible, and absent that tweak compat_* in console until it works as you think it should.

 

1 hour ago, banjiepixel said:

If the source port would use the maximum supported level of DeHackEd format no matter the complevel

...you'd be able to A_Spawn a helper dog/pusher/puller/music changer object. You'd be able to spawn a monster with bossdeath action into a map. You'd be able to call A_LineEffect - a broken by design codepointer that nevertheless can trigger things that are not part of -cl2. You'd be able to set and remove flags with MBF21 - potentially ones that do not exist on your chosen "complevel". And probably other things I can't think of off the top of my head.

 

Dehacked is not "separate" from complevels as you seem to consistently imply - it can have effects up to level of "tied directly to the map itself". Not to mention all the additional codepaths you'd need to rememer to "turn on", like with helper dogs. Doom is a trip to 30 years of interwined legacy behaviors that must be handled correctly. Incidentally, complevels have existed for at least 24 of those (PrBoom 2.0.2 dates back to late 1998), so really you could just accept that this way of doing things is legacy/special interest and never use these ports. Like I said above, there are other ports that are designed for and have been maintained to do things closer to what you want.

 

1 hour ago, banjiepixel said:

Again, using external DeHacked patch to alter the gameplay from the intended default of the map voids the demo compatibility anyway

Not at all. Demo compatibility extends to any pwad and patch combo, provided given executables are able to produce identical behaviors in the first place (which is what makes them "compatible").

 

46 minutes ago, banjiepixel said:

What if I want to record a demo of my MBF format gameplay mod with CL2 map?

An MBF21 demo of cchest2doom2+vesper made in Woof would and should play back in dsda-doom and any other (including future) mbf21 demo-compatible source port. Will the demo be different from cl2 behaviour? Sure - for one, you will not be using vanilla RNG table but rather boom's method of producing random numbers, which affects every aspect of gameplay straight away. But it is most certainly "demo compatible" within the combo you've chosen.

A complevel 9 demo of Valiant will be "broken" in the sense that you won't see an Arachnorb spawn among other things, but it should play back on any cl9 demo-compatible port.

 

 

Also I'd say that for speedrunning demos desyncing on a wrong complevel is equally as important as demos syncing on the right one, as this helps ensure that correct everything was used to produce the end result.

 

 

That said, there exists a dehacked standard, namely - dehextra, that works on current prboom irrespective of complevel (at least the common ones). You can use extra stuff from that, even new fields like Dropped Item, which surprised me - you can have a zombieman dropping rockets on death in -cl2 via a simple dehacked one-liner if you want to, apparently. Whether that's a bug or a very specific exception like sky transfers, I have no idea.

Edited February 23, 2023 by Doomy__Doom : edit: I'm stupid and forgot that cchest2 is -cl9 T_T

[Foxpup]

29 minutes ago, banjiepixel said:

Original Doom 1.9 didn't have DeHackEd, you had to literally hack the executable to make changes

But that's... literally what DeHackEd is. DeHackEd stands for Doom Executable Hack Editor, and it was originally a DOS utility for patching vanilla Doom executables from version 1.666 (complevel 1) and up. It's totally normal for DeHackEd patches to depend on the behaviour of specific Doom versions, or for users to disregard said dependency and try to use DeHackEd patches with a different version of Doom than they were intended for with varying degrees of success. For demo compatibility (yes, you can record and play back demos with a patched Doom executable), these behaviours need to be emulated through the use of complevels.

 

And ultimately, that's the only thing selecting a complevel does: emulate the behaviour of a specific executable. There's no way to mix DeHackEd features of one complevel with the mapping features of another complevel because running two mods simultaneously means running them in the same executable, which has a single set of features. If your mods require incompatible features, then your mods are incompatible with each other, and no messing around with complevels will make them work together.

[Xaser]

As a heads-up, Vesper does work with mapsets like Valiant and Eviternity, (though the latter will look quite different since the palette will change). The idea that "DEHACKED patches don't mix" is true in the general case but Vesper explicitly only uses the extended DEHEXTRA frame range so it works out of the box with older DEH mods. I've only extensively tested Valiant but give it a try with other mapsets and lemme know if things are broken since that sort of wad compatibility is one of Vesper's main goals.

 

Regarding all this other complevel stuff, part of the whole point of MBF21 was to a) provide a nice set of sane defaults and b) let you tweak additional behavior via OPTIONS. If you want exactly cl2 rules but also want to run a gameplay mod that requires a higher cl, you can do that with an OPTIONS lump.

 

Relatedly, the whole "disable higher-complevel DEH features in lower complevel" thing is an old-ass decision that the prboom+ dev(s) made way back, so it's grandfathered in to dsda-doom (preserving existing complevel behavior, good or bad, is a requirement for demo compatibility). It did drive enough of us nuts that we decided to do something about it, and the result is MBF21. :P