The COMPLVL Lump

Hi Doomworld,

Today I'd like to talk about the COMPLVL lump and how while it's a great addition that many source ports have adopted, it's a bit flawed in execution.

If you don't know about the COMPLVL lump, there is a wiki page about it.

Basically it's a way to enforce a complevel via a lump embedded in a WAD, instead of requiring the use of the "-complevel x" parameter with the exe.

It's just a simple text lump instead a wad (called COMPLVL, of course) with some text saying like "mbf21".

This, in theory, is a great tool for mappers as it allows mappers to theoretically enforce a complevel if one isn't specified.

It's honestly sorta similar the compatibility options you can force in ZMAPINFO for GZDoom.

It's a little strange because I'm a little unclear about what options it accepts (it's tricky cuz the wiki page has no sources to follow).

But I know for sure it accepts:

• vanilla
• boom
• mbf
• mbf21

Now at first, I thought this lump was awesome because it would force a certain complevel when the player didn't specify one or just drag-and-dropped the WAD.

That was... until you start dealing with Doom 1 or Final Doom WADs.

My problem with this implementation is that the "vanilla" option is far too vague. While Doom 2 WADs are often "complevel 2" and using "vanilla" works fine, once you start getting into Doom 1 or Final Doom complevels, things start to get unclear.

It's possible that the source port tries to make a guess based on the IWAD, like DOOM.WAD with "vanilla" should be "complevel 3"; TNT.WAD or PLUTONIA.WAD should be "complevel 4"; etc. But it'd be really nice if we could actually specify the exact vanilla compatibility in the COMPLVL lump.

While it's very rare for Boom, MBF, or MBF21 WADs to be something other than the complevels 9,11,21 respectfully, Vanilla WADs are more often to alternate between 2,3,4 depending on the WAD. Especially old Doom 1 WADs often rely on complevel 2 behaviour. Many of these Vanilla WADs will break as the behaviour between 2,3,4 is quite different. (I'm not even going to advocate for complevel 0 or 1, as I know some ports like Woof do not currently support them).

It'd be really nice to have the added options:

• final (for final doom)
• ultimate (for ultimate doom)
• doom (for doom 2 / doom 1 before ultimate)

The reason I'm mentioning "doom" instead of the "vanilla" option above is because "vanilla" has already been implemented in wads, so it'd be a bad idea to change how it works at this point.

I'm guessing that this COMPLVL lump works similar to the "-complevel" parameter in Woof works. Which in Woof, it has the bizarre decision to also have a second parameter called "-gameversion" to determine "1.9", "ultimate", "final", or "chex". This is honestly bizarre to me that it requires two parameters to specify the right Vanilla compatibility in Woof, whereas in DSDA Doom, I just need the one parameter "-complevel" with a number. I honestly think it'd be better for just one parameter; having two just over-complicates things.

(To be honest, I'm pretty sure this is holdover from the "-gameversion" parameter from Crispy / Chocolate Doom. The problem here is that for Crispy / Choco, it makes sense, since they don't have a "-complevel" parameter. For Woof, it's just really over-complicating how to specify what kind of Vanilla compatibility is needed).

The reason I'm making this post is because the COMPLVL lump is often useless to me as a primarily Vanilla mapper, unless I'm just making a normal Doom 2 WAD. I'd like to be able to use the COMPLVL lump, but unfortunately its oversimplification results in it not being very helpful.

I'm not actually sure why the lump doesn't specify the complevel explicitly (or at least allow the option).

Using text substitutions for the numbers seems like it was made for user-friendliness, but I don't see why an explicit number couldn't work too.

It sure could work, but you'd lose some important abstraction here for ports that do not use PrBoom's concept of 'complevels'. With this small set of basic options it can be implemented by everybody, not just by ports that follow PrBoom's concept to the letter.

Most of the other complevels are too obscure or not really needed (e.g. 'vanilla' adapts to the game being played without spelling it out explicitiyl)

30 minutes ago, Graf Zahl said:

Most of the other complevels are too obscure or not really needed (e.g. 'vanilla' adapts to the game being played without spelling it out explicitiyl)

Again, while I would agree on this for many of the obscure higher complevels and possibly complevel 0 and 1, I'm just asking to be able to specify between complevel 2,3,4. They are distinct enough that having the source port try to adapt it can cause a lot of problems / unintended behaviour.

- Complevel 2 (Vanilla Doom 2 / Doom 1 Before Ultimate)

   - Allows for multiple bossdeaths in Doom 1

- Complevel 3 (Ultimate Doom)

   - No multiple bossdeath support for Doom 1

   - Lost souls can bounce on ceilings/floors

- Complevel 4 (Final Doom)

   - No multiple bossdeath support for Doom 1

   - Introduces teleport bug that can be used by the mapper for some cool effects / teleporting flying monsters mid-air

For example, my latest WAD RUST is complevel 1 (which is really close to complevel 2 tbh) and relies on multiple bossdeaths. I'd assume using the COMPLVL lump with "Vanilla" would default to "Ultimate Doom" compatibility, which would make E1M8 incompletable.

54 minutes ago, Arsinikk said:

Which in Woof, it has the bizarre decision to also have a second parameter called "-gameversion" to determine "1.9", "ultimate", "final", or "chex". This is honestly bizarre to me that it requires two parameters to specify the right Vanilla compatibility in Woof, whereas in DSDA Doom, I just need the one parameter "-complevel" with a number

Same in Woof! You may explicitly pass complevels as numbers in Woof, and even semantic shortcuts like `-complevel final` or ` -complevel ultimate` and so on. Everthing that's in this table works:

https://github.com/fabiangreffrath/woof/blob/877836530867a100f91834c05c362b48b7dc7c30/src/g_game.c#L3186-L3203

3 minutes ago, fabian said:

Same in Woof! You may explicitly pass complevels as numbers in Woof, and even semantic shortcuts like `-complevel final` or ` -complevel ultimate` and so on. Everthing that's in this table works:

  

 https://github.com/fabiangreffrath/woof/blob/877836530867a100f91834c05c362b48b7dc7c30/src/g_game.c#L3186-L3203

Ah yeah I do see that. I just said that as that's what the wiki stated... Though it's probably out-of-date.

I will agree that is good.

Although my main point is specifically that the COMPLVL lump is severely limited in the "Vanilla" area, and therefore not useful for me as a mapper:

https://github.com/fabiangreffrath/woof/blob/877836530867a100f91834c05c362b48b7dc7c30/src/g_game.c#L3277-L3302

29 minutes ago, Arsinikk said:

 

- Complevel 2 (Vanilla Doom 2 / Doom 1 Before Ultimate)

   - Allows for multiple bossdeaths in Doom

May I ask what exactly does this do and what cool mapping tricks you can pull off with this?

3 minutes ago, LSC Lasico said:

May I ask what exactly does this do and what cool mapping tricks you can pull off with this?

From the Doomsday of UAC wiki page (WAD that uses this):

Quote

This map occupied the E1M8 slot in order to use the special tag 666 twice, exploiting a peculiarity of Doom's handling when more than one type of boss monster is present in the map. This peculiarity was changed in Ultimate Doom...

38 minutes ago, Arsinikk said:

For example, my latest WAD RUST is complevel 1 (which is really close to complevel 2 tbh) and relies on multiple bossdeaths. I'd assume using the COMPLVL lump with "Vanilla" would default to "Ultimate Doom" compatibility, which would make E1M8 incompletable.

Since you already depend on the COMPLVL lump and all ports that support COMPLVL also support UMAPINFO, why don't you define your special boss actions there?

3 minutes ago, Graf Zahl said:

Since you already depend on the COMPLVL lump and all ports that support COMPLVL also support UMAPINFO, why don't you define your special boss actions there?

I feel this is slightly off topic, but I'll answer.

This would work for the complevel 2 case, but not for the complevel 4 (final doom) case.

Regarding my specific wad, I've opted for using an ACS script so that the map works on legacy ZDoom ports / Eternity as well.

37 minutes ago, Arsinikk said:

This would work for the complevel 2 case, but not for the complevel 4 (final doom) case.

True, but don't forget that this bug is not universally supported by all ports out there, it's one of these things that is important for demo playback but in general has very little use for mapping - at least I cannot think of even a single released map that may depend on it .

I think this concept should go further and allow the lump or similar to specify a desired IWAD in general. 

It gets annoying to have to look whether a WAD wants say Plutonia or Doom 2 when it isn't obviously called "Plutonia 2" or such, for similar reasons as it being annoying for a user have the burden of specifying the complevel.

I think ports could be smart enough to make a better guess based on which flats/patches are used as well.

1 hour ago, Arsinikk said:

For example, my latest WAD RUST is complevel 1 (which is really close to complevel 2 tbh) and relies on multiple bossdeaths. I'd assume using the COMPLVL lump with "Vanilla" would default to "Ultimate Doom" compatibility, which would make E1M8 incompletable.

complevel 1 is only supported by PrBoom+/DSDA-Doom. There is a "-gameversion 1.666" in Chocolate Doom, but judging by the source code it only affects the OPL emulation.

If you're making PWAD then "vanilla" should be enough, the correct complevel will be determined via IWAD. Honestly, I was hoping the community would move away from complevel numbers to "vanilla", "boom", "mbf", "mbf21" Woof style.

15 minutes ago, Trov said:

I think ports could be smart enough to make a better guess based on which flats/patches are used as well.

This honestly could just cause more problems... Especially when wads commonly take textures and flats from other iwads.

I honestly think the idea of making source ports guess the complevel is the wrong approach, and we should be able to specify exactly what complevel we want in the COMPLVL lump, instead of a simple "vanilla" value that each source port tries to take a guess at.

5 minutes ago, rfomin said:

If you're making PWAD then "vanilla" should be enough, the correct complevel will be determined via IWAD. Honestly, I was hoping the community would move away from complevel numbers to "vanilla", "boom", "mbf", "mbf21" Woof style.

This is incorrect regarding doom 1 wads that rely on pre-ultimate doom behaviour. For those wads COMPLVL is useless as it will try to force complevel 3, when it should be complevel 2.

Same if a doom 2 wad wanted to use complevel 4 for the benefits that the teleport z-axis bug gives. There'd be no way to determine that because the source ports just have to guess what "vanilla" means.

5 minutes ago, Arsinikk said:

I honestly think the idea of making source ports guess the complevel is the wrong approach, and we should be able to specify exactly what complevel we want in the COMPLVL lump, instead of a simple "vanilla" value that each source port tries to take a guess at.

Not all ports support complevels, like Graf mentioned above. The proposal needs to address that.

5 minutes ago, JadingTsunami said:

Not all ports support complevels, like Graf mentioned above. The proposal needs to address that.

Well what are the current ports that support the COMPLVL lump?

Because those are the main ports we need to be concerned about.

According to the wiki, it just lists:

• DSDA-Doom (added in v0.19.0)
• From Doom With Love
• Nugget Doom
• PrBoomX (added in v2.7.0)
• Woof! (added in v6.3.1)

But that definitely seems out of date, and there are no sources to let me know more info about the lump 

From that list, all those ports support doom2, ultimate doom, and final doom compatibility.

I do know that gzdoom has recently added some partial support for the lump that just adds some compatibility flags... And so that could work well for things like adding the "allow multiple bossdeaths" for doom2 (complevel 2, doom 1) compatibility.

Not all ports need full support for the features of certain complevels if the ports don't support it, but for the ones who do, they should have an option to specify... Which they currently do not.

13 minutes ago, Arsinikk said:

This is incorrect regarding doom 1 wads that rely on pre-ultimate doom behaviour.

Which are few and far between - Doomsday of UAC is the only exception I'm aware of.

14 minutes ago, Arsinikk said:

For those wads COMPLVL is useless as it will try to force complevel 3, when it should be complevel 2. 

Simply define the special boss actions in UMAPINFO like Graf said - all ports that support COMPLVL also support UMAPINFO.

3 minutes ago, Andromeda said:

Simply define the special boss actions in UMAPINFO like Graf said - all ports that support COMPLVL also support UMAPINFO.

You miss the point of the lost soul demo incompatibility here in some ports. Also of course complevel 4 in of itself.

3 minutes ago, Andromeda said:

Which are few and far between - Doomsday of UAC is the only exception I'm aware of.

I feel like this is a mute point. Saying something doesn't usually happen doesn't mean it should be ignored or it's the not better way to do something. Perhaps some mappers may be more encouraged to experiment if the barrier to entry was lower.

Sure I can do lots of things to "fix" my wad for certain ports. But I'm looking to the future, in case I want to do something unique.

Right now this COMPLVL system is flawed and is not of much use to me. Anything I can do to lower the barrier to help players experience my wads in the right way, I'll do... And right now it's possible that COMPLVL will lead them to playing on the wrong compatibility.

So I'm bringing this up this whole conversation because the system that was set up to make it easier for players, is actually making it harder for players that play my WADs. Now and going forward, as long as it works how it does now.

5 minutes ago, Arsinikk said:

So I'm bringing this up this whole conversation because the system that was set up to make it easier for players, is actually making it harder for players that play my WADs. Now and going forward, as long as it works how it does now.

It only makes it harder for players of your WADs because you use the wrong features.

The boss trigger can be handled by other officially supported features and the bugs in Final Doom are something nobody should base their maps on because there is no universal support for them across ports - any ports that doesn't have demo compatibility has very little use supporting them. The point of COMPLVL is to set a feature baseline, not to enable or disable specific quirks of singular older Doom versions. And the four feature levels it supports are precisely the four that are relevant.

8 minutes ago, Graf Zahl said:

the bugs in Final Doom are something nobody should base their maps on because there is no universal support for them across ports - any ports that doesn't have demo compatibility has very little use supporting them.

You say this as if "ports that don't have demo compatibility" and "ports that don't replicate Final Doom bugs" covers most source ports, when it doesn't. I'd argue something that only supports source ports that don't have those characteristics wouldn't be "universal", but would still be useful. And I don't know why you're treating demo compatibility and version differences as interchangeable when it's entirely possible for ports to do the latter but not the former.

If, say, GZDoom doesn't want to support Final Doom teleporters, that's its (or your, I guess) prerogative. But clearly there are lots of ports that do bother to distinguish Doom 2 from Final Doom, or Doom from Ultimate Doom, and for those ports, it's worth expanding COMPLVL to cover those cases.

And if the response is "this should go in xMAPINFO" then why does COMPLVL exist at all?

8 minutes ago, Blast_Brothers said:

 

You say this as if "ports that don't have demo compatibility" and "ports that don't replicate Final Doom bugs" covers most source ports, when it doesn't. I'd argue something that only supports source ports that don't have those characteristics wouldn't be "universal", but would still be useful. And I don't know why you're treating demo compatibility and version differences as interchangeable when it's entirely possible for ports to do the latter but not the former.

There are features and there are bugs. If you want to depend on bugs you have to accept that you may run into some problems. The two known quirks in Final Doom are both clear and unambiguous bugs that normally have no effect on a map's playability.

12 minutes ago, Blast_Brothers said:

 

If, say, GZDoom doesn't want to support Final Doom teleporters, that's its (or your, I guess) prerogative. But clearly there are lots of ports that do bother to distinguish Doom 2 from Final Doom, or Doom from Ultimate Doom, and for those ports, it's worth expanding COMPLVL to cover those cases.

 

What's the point of supporting something broken that no existing map depends on? You need that for demo playback but not for playing the map.

12 minutes ago, Blast_Brothers said:

 

And if the response is "this should go in xMAPINFO" then why does COMPLVL exist at all? 

Since it supports four specific values that all equal a major baselines the answer should be clear. What also should be clear from the choice of options is that it was never meant for what is being asked for in this thread. "Use UMAPINFO" was said because UMAPINFO DOES support the needed feature in a form that's compatible and officially supported across ports. Why use hacks if a proper feature exists that solves all the problems out of the box?

9 minutes ago, Blast_Brothers said:

why does COMPLVL exist at all?

To cover common mapping targets found in 202x?

Those being:

- doom2.wad + cl 2

- doom.wad + cl 3

- tnt.wad/plutonia.wad + cl 4

- any iwad + cl 9/11/21

doom.wad+cl2 sounds about as obscure as tnt.wad+cl2 or anything+cl1, quite honestly.

this COMPLVL expantion probably should only target ports that already support vanilla version diferences like prboom+/dsda-doom/woof, if a port isnt focused on version/demo compatibility, this kind of thing already doesnt work exacly as expected ( mainly involving more obscure behavior/ bugs/ hacks ), in such ports it should be fine to use the geral vanilla compatibilty mode that they support.

it's unfair to ask for more especific/ demo compatibility to ports that focus on others things like adding their own advanced feature-set/ changing especific behavior to improve player experience and/or extend modding for the game.

if the mapper depends on a certain especific vanilla behavior, they should especify the player to use version/demo-compatible sourceports.

or if they want to support non-version/demo compatible ports, they should add the feature themselves using the more advanced featureset of the port ( scripting, umapinfo, zscript, etc ).

personally i recommend mappers that like messing with vanilla hacky stuff and/or obscure behavior ( like myself ) just stick to doing the former and focus on ports that support our needs. better to stick with ports that were made to support our stuff, instread of "fixing" for ports that doesn't.

1 hour ago, Blast_Brothers said:

And if the response is "this should go in xMAPINFO" then why does COMPLVL exist at all?

Simply put: Demos

The Compatibility Level system was made to mitigate the need to have every little different version of PRBoom+ or vanilla Doom just to watch or record demos without desyncs

While purists also got alot of use out of it for it's necessarily extremely accurate emulation to vanilla quirks and bugs; I do think mappers trying to stretch it for niche behaviors is a bit ridiculous. It sounds more like actual modding formats such as umapinfo need to step up their game rather than a will the complevel system needs to bend to

10 hours ago, Graf Zahl said:

It only makes it harder for players of your WADs because you use the wrong features.

Don't take this the "wrong" way, but who are the gatekeepers of what features are wrong or right? You don't push the envelope by staying within the confines you've been placed in. It isn't my fault if I want to use features that many other people haven't. If certain source ports don't support it, it's their fault, not mine.

10 hours ago, Graf Zahl said:

The point of COMPLVL is to set a feature baseline, not to enable or disable specific quirks of singular older Doom versions.

If this is the case, it shouldn't have been called "COMPLVL" as it infers it would have equal to similar functionality with the "complevel" parameter. I don't actually mind if ports that don't support specific stuff like "complevel 4 teleports" don't actually emulate those... For the large amount of ports that do support "complevel 2,3,4", it'd be nice if the lump that's viewed to be equivalent to "complevel" would actually be able to distinguish between Vanilla complevels. It's not like I'm asking to add esoteric complevels like 0-1, or 5-8.

10 hours ago, Graf Zahl said:

And the four feature levels it supports are precisely the four that are relevant.

Don't get me wrong, I appreciate your work on GZDoom... But I do not regard your opinions on Vanilla support very highly.

For the last half a year, most of my vanilla WADs have been broken because GZDoom 4.11 broke a compatibility setting. You may say that it was fixed very early on, but that was in the developer build, and a new stable build with the fix didn't come out until a few days ago. This didn't stop numerous comments on my WADs constantly saying that "certain things were broken", which was all because of GZDoom and not me. Even though I could tell them to download a developer build, that wouldn't stop people commenting on the WADs with "false" bug reports. So to be frank, it's very clear to me that you don't think of Vanilla compatibility very highly.

11 hours ago, rfomin said:

If you're making PWAD then "vanilla" should be enough, the correct complevel will be determined via IWAD. Honestly, I was hoping the community would move away from complevel numbers to "vanilla", "boom", "mbf", "mbf21" Woof style.

I know I commented on this earlier, but it's interesting for you to say this, but then say that there is no need to have complevel 2,3,4 specified. With that logic, you are honestly prolonging the use of the old-school "complevel" parameter even longer, since it is not equal in its functionality.

To reiterate my stance here, I used to really endorse the COMPLVL lump, because I thought it was a great way for layman users to easily play WADs in the right compatibility. Unfortunately regarding Vanilla, it lacks certain needed features to be on par with the traditional "complevel" parameter, and so there is no reason for me to use it in the future. Whether you agree with me or not is kind of irrelevant. There is no reason for me to use a feature that lacks the functionality to suit Vanilla WAD needs.

Actually an idea just occurred to me.

Would it be possible to have a new lump called "GAMEVER" that would have the following options?:

• 1.9
• Ultimate
• Final

This would be extremely similar to the "gameversion" parameter that Woof uses to distinguish Vanilla versions. So if "Vanilla" in COMPLVL was used with "Final" in GAMEVER were used, it would use complevel 4. This could mean ports that support complevel 2,3,4 could specify the version.

This would work for ports that already support COMPLVL, but would allow for more specific declaration for ports that support the GAMEVER lump.

Best part about this is that it wouldn't affect ports that don't need further Vanilla specification.

6 minutes ago, Arsinikk said:

Would it be possible to have a new lump called "GAMEVER" that would have the following options?:

• 1.9
• Ultimate
• Final

I like the idea, we can probably do it in Woof and Crispy. But not sure if @dsda-dev will like it.

51 minutes ago, Arsinikk said:

Don't take this the "wrong" way, but who are the gatekeepers of what features are wrong or right? You don't push the envelope by staying within the confines you've been placed in. It isn't my fault if I want to use features that many other people haven't. If certain source ports don't support it, it's their fault, not mine.

Nobody. But why are you so dead set on NOT using an existing feature that does what you need? A feature that already works with all relevant ports and was explicitly implemented to do what you want.

51 minutes ago, Arsinikk said:

If this is the case, it shouldn't have been called "COMPLVL" as it infers it would have equal to similar functionality with the "complevel" parameter

 

The name is indeed a bit unfortunate, but that's what we're stuck with now. The same happened with DECORATE in ZDoom, which initially was for decorations only, hence the name These things happen.

51 minutes ago, Arsinikk said:

. I don't actually mind if ports that don't support specific stuff like "complevel 4 teleports" don't actually emulate those... For the large amount of ports that do support "complevel 2,3,4", it'd be nice if the lump that's viewed to be equivalent to "complevel" would actually be able to distinguish between Vanilla complevels. It's not like I'm asking to add esoteric complevels like 0-1, or 5-8.

Personally, I think that all this should better be integrated into UMAPINFO where it could be set on a per-map basis for better control.

51 minutes ago, Arsinikk said:

Don't get me wrong, I appreciate your work on GZDoom... But I do not regard your opinions on Vanilla support very highly.

 

For the last half a year, most of my vanilla WADs have been broken because GZDoom 4.11 broke a compatibility setting.

 

Unless you mean the compat_floor regression that has already been fixed, where's the report? Here's the thing: These things happen with external contributors that often do not care about backwards compatibility, but if they get reported they'll be fixed ASAP.

1 hour ago, Arsinikk said:

I know I commented on this earlier, but it's interesting for you to say this, but then say that there is no need to have complevel 2,3,4 specified. With that logic, you are honestly prolonging the use of the old-school "complevel" parameter even longer, since it is not equal in its functionality.

Out of interest, what's so desirable here to control these features?

I just had a look at Woof to see what they do and came up with precisely 3 differences:

* slightly different handling of boss deaths (allowing both cyber and spider to end E2M8 and E3M8) - this can already be done with UMAPINFO

* the lost soul bounce

* the teleporter glitch

What can you do with the latter two? I've always seen them as bugs that are to be avoided than something that has potential use.

1 hour ago, Arsinikk said:

To reiterate my stance here, I used to really endorse the COMPLVL lump, because I thought it was a great way for layman users to easily play WADs in the right compatibility. Unfortunately regarding Vanilla, it lacks certain needed features to be on par with the traditional "complevel" parameter, and so there is no reason for me to use it in the future. Whether you agree with me or not is kind of irrelevant. There is no reason for me to use a feature that lacks the functionality to suit Vanilla WAD needs.

You still need it to set the feature baseline. Don't pretend it is useless just because it doesn't handle this very small amount of rather esoteric things. It still sets up the ports to the most vanilla-like setup they can do and that really can often make or break a map. In GZDoom it enables 19 compatibility flags, for example, if you specify 'vanilla' in COMPLVL.

53 minutes ago, Graf Zahl said:

Nobody. But why are you so dead set on NOT using an existing feature that does what you need? A feature that already works with all relevant ports and was explicitly implemented to do what you want.

This isn't really about a specific use case here. Like I said I could fix the bossaction issue using UMAPINFO. This is looking into the future for any other possible issues that could crop up, regarding complevel 2,3,4 dependency.

Even if that is the case, UMAPINFO wouldn't really be a useable option for me, due to the targeting of Vanilla. Mapping for Vanilla requires alot of work in trying to make mapsets compatible with as many ports as possible. If I was making a mapset for MBF21, sure, I'd use UMAPINFO because every MBF21 port supports it. There are quite a few ports such as Zandronum and ZDaemon that do not support UMAPINFO... or even DECORATE for that matter.

To be honest, this COMPLVL setting probably does less for ZDoom-based ports, as they always require some extra tweaking and scripting to get working as intended. Due to ZDoom having altered physics and weird quirks, complevel means a lot less, and the best option is to fix it using ZDoom-exclusive features (almost as a sort of patch). But for more complevel supported ports like Woof or DSDA Doom, complevel is way more important. Both for demo-compatibility and just overall engine changes to allow the maps to act in the correct way.

1 hour ago, Graf Zahl said:

The name is indeed a bit unfortunate, but that's what we're stuck with now. The same happened with DECORATE in ZDoom, which initially was for decorations only, hence the name These things happen.

Interesting about the DECORATE thing, although that makes alot of sense in hindsight. You are correct in that there's no use in complaining about the name now that it's been implemented in ports.

1 hour ago, Graf Zahl said:

Personally, I think that all this should better be integrated into UMAPINFO where it could be set on a per-map basis for better control.

This would be really awesome for the successor of MBF21... Although for complevel ports, this seems like a bad idea for older complevels. Especially when looking at the teleport behaviour of complevel 4, it can cause the player to teleport in a very high place where they'd have to wait to fall down. That would affect demo-compatibility. I guess it's possible you could say the same thing about UMAPINFO custom bossdeath definitions regarding complevel 1,2,3 as in Chocolate / Crispy, those would not be accepted.

1 hour ago, Graf Zahl said:

Unless you mean the compat_floor regression that has already been fixed, where's the report? Here's the thing: These things happen with external contributors that often do not care about backwards compatibility, but if they get reported they'll be fixed ASAP.

I'm not exactly saying it's your fault, but I cannot deny the amount of messages I've gotten saying "this map doesn't work in GZDoom". This has even been reported in the forums about Plutonia levels softlocking due to this.

At first, I was willing to wait it out a bit, since the "compat_floor" issue was fixed in Github... but after around 5 months past, what am I to do, but to just say that GZDoom is incompatible.

Just so that we are on the same page about how I feel about dev builds, this is an excerpt I wrote in one of my WAD threads:

Quote

As much as developers like to say that users can download a dev build of their source port, many users do not like using a dev build and just get the stable version. It's because the stable version is supposed to be less prone to issues. I don't like telling users to download dev builds, because what happens if the port breaks something in the dev build that affects someone playing my WAD? Someone could come across an issue and think it's the WAD's fault and not the port. There is no way for me to test whether a WAD will work on a build that's compiled every other day.

It's honestly just as simple as most people when they download GZDoom, they go to zdoom.org and download the release. Expecting people to download a dev version of a source port is both a ridiculous ask and is a risk depending on if that daily build will actually run the WAD the way it is supposed to.

1 hour ago, Graf Zahl said:

Out of interest, what's so desirable here to control these features?

 I just had a look at Woof to see what they do and came up with precisely 3 differences:

  

 * slightly different handling of boss deaths (allowing both cyber and spider to end E2M8 and E3M8) - this can already be done with UMAPINFO

* the lost soul bounce

 * the teleporter glitch

  

 What can you do with the latter two? I've always seen them as bugs that are to be avoided than something that has potential use.

Regarding the lost soul bounce, with GZDoom's altered physics and lack of demo compatibility, it pretty much is useless.

However the teleporter glitch is actually very useful and can do a lot in Doom maps. Essentially, you know that in Plutonia and TNT, teleports remember the height of which the entering teleport is and exit the destination at the same height. This goes for both the player, monsters, and things. Essentially everything that can be teleported. For ground monsters, this really doesn't do much since they are clamped to the ground... but for the player, flying enemies, and barrels, this means they can teleport in the air at any height based on how the mapper has set up the teleports.

I have a recent Plutonia map (unreleased atm) that includes an exploding bridge using a vanilla conveyor and barrels. Essentially, the bridge which is a midtex bridge has each part instantly raise (due to the ceiling instantly raising up), and it teleporting barrels where the bridge midtextures were. Since it's in complevel 4, the barrels teleport in the air and fall down exploding to give the illusion that the bridge itself is actually blowing up.

However the same thing can be used in teleporting flying monsters into an arena. Using out-of-bounds monster closets, you can set particular heights, and then have Cacodemons teleport into an arena at different heights when they take the teleporters.

1 hour ago, Graf Zahl said:

You still need it to set the feature baseline. Don't pretend it is useless just because it doesn't handle this very small amount of rather esoteric things. It still sets up the ports to the most vanilla-like setup they can do and that really can often make or break a map. In GZDoom it enables 19 compatibility flags, for example, if you specify 'vanilla' in COMPLVL.

I wouldn't consider complevel 2,3,4 features esoteric. It may seem esoteric to one used to GZDoom, but for ports like DSDA Doom and Woof, it's a bit much more common to rely on features such as this. Perhaps this is because ZDoom ports didn't support some of these in the first place.