The COMPLVL Lump

[Andromeda]

16 hours ago, Doomy__Doom said:

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

Besides it doesn't make much sense for a vanilla wad targeting a certain IWAD to not run properly in the original executable.

[Arsinikk]

3 minutes ago, Andromeda said:

Besides it doesn't make much sense for a vanilla wad targeting a certain IWAD to not run properly in the original executable.

Lol it's a little bit of a tangent here...

 

But with my DOS DOOM setup, for years I was accidently using the Ultimate DOOM.EXE to run Doom 2 WADs... and it actually works fine. I know it was the incorrect EXE because it would crash when trying to play the fourth demo on the menu when it didn't exist. So it's not exactly out of the question whether EXEs could be mixed and matched with different IWADs. Obviously this is extremely obscure and no one probably does this.

[Professor Hastig]

The really interesting thing about these obscure differences is how it is handled by the various ports.

 

First things first, COMPLVL is being handled by DSDA, Woof and GZDoom. Strangely enough not by Eternity and Doom Retro.

DSDA, Woof and Eternity have special handling for the teleporter glitch. GZDoom and Doom Retro don't, unless I missed something.

The same applies to the Lost Soul bouncing glitch - only the ports with explicit demo compatibility handle it. GZDoom and Doom Retro only have the fixed version of it.

 

But none of these ports expose it in a mapping friendly way, it seems to be generally assumed that these differences are tied to their respective game modes and otherwise not really relevant.

 

 

 

 

 

[Trov]

19 hours ago, Arsinikk said:

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

Well obviously if the wad contained all the textures itself that could be easily accounted for. But if a wad references Plutonia textures but does not define them it is apparent the Plutonia IWAD would be needed.

 

But otherwise I agree with you that specifying it would be better.

 

The idea is a way for the wad to define it so that the user doesn't have to.

Edited April 23 by Trov

[maxmanium]

It's pretty unfortunate how many things are baked in stone just because of demo compatibility.

[dsda-dev]

The lump is based on the common and accepted standards, as seen by both source ports and authors, which work for most wads. There are rare, nonstandard use cases not covered by this lump. One example is having multiple complevels used in one wad in different maps. Another is numerical complevels targeting specific engine behavior that doesn't represent a cross-port standard. It might be more worthwhile to understand what kind of behavior you are trying to get and codify it in more compatibility behavior flags for the next iteration of mbf21+. There's a thread where such things can be gathered over in the editing forum.

[Redneckerz]

On 4/22/2024 at 6:57 PM, Arsinikk said:

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.

Considering i made the page you mention, i am very much watching over this thread in regards to any more info.

 

However, it should be noted that the people who know this kind of thing best, are the authors themselves - I am fairly happy with the DSDHacked and DEHExtra pages, but MBF21, for instance, which surely is one of the more often used extensions, still misses a detailed features paragraph - For the simple reason i don't find myself qualified enough to describe them, even with the open blueprints (Thank you for this!) in hand.

 

So i think it works in multiple ways. I am all for more universal frameworks, but detailed info and implementation shouldn't be relegated to either non-existence or a github page where it is open to interpretation. Hence why i prefer that the authors of these standards do a write up, as i am more likely to miss the essentials than they do.

 

COMPLVL in my opinion could be extended more with good examples of it. I realize i can do that myself, but hey, i am a man, not a machine. IRL stuff also gets in the way..

 

1 hour ago, dsda-dev said:

The lump is based on the common and accepted standards, as seen by both source ports and authors, which work for most wads. There are rare, nonstandard use cases not covered by this lump. One example is having multiple complevels used in one wad in different maps. Another is numerical complevels targeting specific engine behavior that doesn't represent a cross-port standard. It might be more worthwhile to understand what kind of behavior you are trying to get and codify it in more compatibility behavior flags for the next iteration of mbf21+. There's a thread where such things can be gathered over in the editing forum.

I for one would very much like to see this being accepted. Perhaps the core ideas of COMPLVL can be integrated in the MBF21+ spec or whatever it is going to be called.

 

In either case i am glad that through recent years we have somewhat of a universal standard set for certain things so that they work in most ports.

[Graf Zahl]

8 minutes ago, Redneckerz said:

COMPLVL in my opinion could be extended more with good examples of it. I realize i can do that myself, but hey, i am a man, not a machine. IRL stuff also gets in the way..

 

 

 

 

COMPLVL should not be extended. The way it works right now can be handled by most ports, even those without strict compatibility. If you go into the finer details it will run into problems if the features become too specific which would render the whole thing useless.

 

If you want to support these, use another feature that can be safely ignored if support cannot be done.

 

[Redneckerz]

Just now, Graf Zahl said:

 

COMPLVL should not be extended.

Not the lump, no - But the article can, which is what i mean't. Sorry if this didn't came across.

[Graf Zahl]

Thanks for the clarification, yes that makes sense. The article is not only a bit brief but also explains what it does in terms of PrBoom/DSDA complevels which really have no meaning for other ports that support the feature anyway. And due to how tech-y it is written it may not be that comprehensible for people with less internal knowledge of these ports.

 

[hobomaster22]

1 hour ago, Redneckerz said:

Considering i made the page you mention, i am very much watching over this thread in regards to any more info.

With that Helion added COMPLVL support in 0.9.2.7.

[Arsinikk]

3 hours ago, dsda-dev said:

The lump is based on the common and accepted standards, as seen by both source ports and authors, which work for most wads. There are rare, nonstandard use cases not covered by this lump. One example is having multiple complevels used in one wad in different maps. Another is numerical complevels targeting specific engine behavior that doesn't represent a cross-port standard. It might be more worthwhile to understand what kind of behavior you are trying to get and codify it in more compatibility behavior flags for the next iteration of mbf21+. There's a thread where such things can be gathered over in the editing forum.

It's important to clarify that the issue I have with the COMPLVL lump specifically is its "Vanilla" implementation. I never like when systems are put together in order to take a guess based on certain arguments. Usually the idea is for simplicity sake, but it's often a pain for power users as they can't exactly specify what they'd like something to do.

 

This is how I feel about the COMPLVL lump with it's current "Vanilla" implementation.

 

Alot of what you've mentioned regards MBF21+ which isn't really related to "Vanilla". While I'd agree that it'd be cool to see some of these features added as toggleable in MBF21+ (I assume through UMAPINFO), it wouldn't be through an OPTIONS lumps since that'd be disabled when running under Vanilla complevels.

 

The main problem with implementing such features in UMAPINFO is that you'd have to add that option to every single map, which is tedious and annoying (since there's no "defaultmap" like in ZMAPINFO). I'd rather just be able to set a specific complevel through the lump in order to make a global behavioural change.

 

Again this is why I mentioned it'd be nice to have a second GAMEVER wad for the source ports that actually do support specific vanilla complevels, so that we could exactly specify an exact complevel so that players don't drag-and-drop and play on the wrong compatibility.

Edited April 24 by Arsinikk

[Graf Zahl]

1 hour ago, Arsinikk said:

It's important to clarify that the issue I have with the COMPLVL lump specifically is its "Vanilla" implementation. I never like when systems are put together in order to take a guess based on certain arguments. Usually the idea is for simplicity sake, but it's often a pain for power users as they can't exactly specify what they'd like something to do.

 

This is how I feel about the COMPLVL lump with it's current "Vanilla" implementation.

 

That may be, but at the end of the day, "vanilla" means Doom 1.9 and truth be told, except for very rare cases the differences between the 3 variants do not matter for most maps - and several ports which support COMPLVL do not implement these quirks so what you propose simply cannot work because nowhere does COMPLVL guarantee that it activates a 100% accurate emulation of the requested feature level. In some ports it will, in others it won't.

While it may be of some use to have some option to set these things, COMPLVL is not the right place because if this gets too specific the lump will lose its purpose.

 

 

 

 

Edited April 24 by Graf Zahl

[Xaser]

The simplest way to handle the cited vanilla-version behavioral differences (namely, lost soul bouncing, boss action differences, and the Final Doom teleporter z-height) is the OPTIONS lump. Add some specific compat flags for these cases and let wads set 'em if they need 'em, no need to overcomplicate COMPLVL by changing how it works and pulling the rug out from all ports that support it.

 

Of the three cited issues, the Final Doom teleporter behavior is the only that's truly missing ATM (Lost Soul bouncing already has the comp_soul option and UMAPINFO handles the bossaction differences), but as far as I can tell, it's only been cited as a hypothetical in this thread; what wads out there depend on this? Is it something folks might get some real use out of? I'm usually of the "why not?" mindset for this sort of thing, but I'm also not the lead port dev anywhere. :P

 

Also, there's nothing wrong with the concept of using a port-specific feature (e.g. ZMAPINFO, UMAPINFO, or otherwise) to make other port-specific implementations agree with vanilla, especially once you start getting into the weeds. In an ideal world, everything would Just Work(tm), but in practice, once you start toying with very obscure features or edge cases, you sometimes have to dig in and tell the various other ports exactly how to handle it (e.g. setting GZDoom compat flags in ZMAPINFO, using a UMAPINFO to set up bossactions, adding tall skies so ports with mouselook don't look funny, etc). The features exist; it's better to use them than to elect not to and leave part of your playerbase with a seemingly-broken wad.

 

 

[EDIT] I should probably toss this out there to help clarify my stance here: COMPLVL is for new wads. Even if the "final/ultimate/doom" options existed in COMPLVL, you wouldn't be able to just repackage UAC_DEAD with a COMPLVL lump unless you're the original author (or otherwise get the blessing from everyone to update the canonical version of the map on /idgames). At that point, telling folks to load a separate PWAD or use a bootleg version is not any easier than telling folks to run it with -complevel 1 (or whichever it needs :P ).

 

So yeah, in light of that, if you're adding a COMPLVL, you're making a new wad or are already modifying something that exists, and at that point there's nothing stopping you from adding OPTIONS, UMAPINFO, ZMAPINFO, or whatever else you need to get it all running in tip-top shape.

Edited April 24 by Xaser

[Xyzzу]

On 4/22/2024 at 2:00 PM, Graf Zahl said:

What's the point of supporting something broken that no existing map depends on?

 

20 minutes ago, Xaser said:

Of the three cited issues, the Final Doom teleporter behavior is the only that's truly missing ATM (Lost Soul bouncing already has the comp_soul option and UMAPINFO handles the bossaction differences), but as far as I can tell, it's only been cited as a hypothetical in this thread; what wads out there depend on this? Is it something folks might get some real use out of?

On today's episode of "Xyzzy shilling his own stuff because it happens to be relavant to some topic": MAP10 of this requires use of the Final Doom teleporter shenanigans in order to defeat an Icon of Sin:

There's also this set from the sounds of it:

 

[Xaser]

Thanks! That's indeed more than zero, so I'll leave a note in the MBF24+ thread about it. Couldn't hurt to pitch it. ;P

[Arsinikk]

7 hours ago, Xaser said:

The simplest way to handle the cited vanilla-version behavioral differences (namely, lost soul bouncing, boss action differences, and the Final Doom teleporter z-height) is the OPTIONS lump. Add some specific compat flags for these cases and let wads set 'em if they need 'em, no need to overcomplicate COMPLVL by changing how it works and pulling the rug out from all ports that support it.

 

Ok there's quite a bit to unpack here....

 

1) DSDA Doom and PRBoom don't actually read the OPTIONS lump if a Vanilla complevel is specified. Imo this is a good thing, because introducing extra features via the OPTIONS lump into a theoretical "vanilla" WAD seems like a travesty regarding demo compatibility. To be quite honest, I actually do not like how UMAPINFO can add extra bossdeath actions and other such features to Vanilla complevel WADs... as it gives a false representation of what a Vanilla WAD actually supports and will obviously cause vanilla discrepancies when actually playing through DOS, Choco, Crispy, etc.

 

2) I actually use OPTIONS to set very specific options specifically for the Eternity Engine, as it's the only option setting tool for that source port.

 

For my Vanilla WADs, I aim to support these main ports:

• GZDoom and other older ZDoom-based ports, such as Zandronum and ZDaemon.
• Eternity Engine, which often requires it's own lumps to get working right
• DSDA Doom, PRBoom+, Woof, and Nugget Doom which I would consider much more classic ports as they rely on complevel for their compatibility.
• and of course, DOS Doom, Choco, and Crispy, which are the most accurate.

The way I support these ports is very different:

• ZDoom ports I often use ACS to fix things because some really old ZDoom ports don't support ZMAPINFO, or even DECORATE for that matter (ZDaemon).
• Eternity Engine, requires the use of OPTIONS to make sure certain Vanilla actions work right.
• DSDA Doom, PRBoom+, Woof, Nugget Doom, each use the complevel to ensure certain behaviours act as they should. The main benefit of these is that you can set a very specific complevel and it'll act as it should without having to add extra settings.

 

The problem with using OPTIONS for specifying actions for ports such as DSDA Doom or Woof is that the only way to force vanilla features in the Eternity Engine is via the OPTIONS lump... And because of how strange Eternity is, it often requires me to set other settings that aren't necessarily considered true "vanilla".

 

Let me give an example. For Hell Revealations MAP30, it features a ghost monster icon of sin. For many ZDoom ports, ghost monsters as a feature is unsupported. So Worst and I wrote a script to allow ZDoom and Eternity ports to be able to emulate the fight via ACS. The problem here is that the OPTIONS setting comp_vile should be turned off in Eternity, but obviously we don't want that in DSDA Doom or else the entire setup in that port would be borked.

 

 

To clarify, I think the OPTIONS lump in conjunction with MBF21 is amazing... But it's only amazing because all the source ports have agreed to support it in the same way. Unfortunately OPTIONS is a legacy lump used by Eternity that sometimes requires certain tweaks to get it fully compatible with the port. And since I'm targeting "Vanilla" compatibility, the behaviours of "Vanilla" have already been set in stone. This is why I don't see why we can't specify this further.

 

7 hours ago, Xaser said:

Also, there's nothing wrong with the concept of using a port-specific feature (e.g. ZMAPINFO, UMAPINFO, or otherwise) to make other port-specific implementations agree with vanilla, especially once you start getting into the weeds. In an ideal world, everything would Just Work(tm), but in practice, once you start toying with very obscure features or edge cases, you sometimes have to dig in and tell the various other ports exactly how to handle it (e.g. setting GZDoom compat flags in ZMAPINFO, using a UMAPINFO to set up bossactions, adding tall skies so ports with mouselook don't look funny, etc). The features exist; it's better to use them than to elect not to and leave part of your playerbase with a seemingly-broken wad.

 

I think the reason I am so frustrated, is I don't see why everyone wants to make it so difficult for Vanilla mappers to just automatically set a specific behaviour via a lump. Literally all this adding of UMAPINFO options into certain actions is just way more work, then just running the WAD with a simple "-complevel 2" parameter. COMPLVL is supposed to be like "-complevel" parameter but even easier and more automated for the player. The problem is it's actually easier and better for me to just tell people to use the old school "-complevel" parameter than it is to use the COMPLVL lump in general due to the lack of "vanilla" specification.

 

To clarify yet again, I'm actually more in favour of adding a secondary text lump called GAMEVER (1.9, ultimate, final) to specify the exact vanilla compatibility as it wouldn't affect any ports implementation of the COMPLVL lump up to this point.

[Graf Zahl]

7 hours ago, Xyzzу said:

 

On today's episode of "Xyzzy shilling his own stuff because it happens to be relavant to some topic": MAP10 of this requires use of the Final Doom teleporter shenanigans in order to defeat an Icon of Sin:

There's also this set from the sounds of it:

 

 

Good to know. I think I have to add handling for this to GZDoom then...

 

[Graf Zahl]

15 minutes ago, Arsinikk said:

Ok there's quite a bit to unpack here....

 

1) DSDA Doom and PRBoom don't actually read the OPTIONS lump if a Vanilla complevel is specified. Imo this is a good thing, because introducing extra features via the OPTIONS lump into a theoretical "vanilla" WAD seems like a travesty regarding demo compatibility. To be quite honest, I actually do not like how UMAPINFO can add extra bossdeath actions and other such features to Vanilla complevel WADs... as it gives a false representation of what a Vanilla WAD actually supports and will obviously cause vanilla discrepancies when actually playing through DOS, Choco, Crispy, etc.

 

 

You are conflating two things here. A WAD only using vanilla features and vanilla bahavior is not the same as a vanilla-compatible WAD. It may well be limit removing with some additions (e.g. shuffling around the maps with boss actions) - but such a WAD still should be able to declare use of vanilla-behavior and be able to configure itself.

 

26 minutes ago, Arsinikk said:

2) I actually use OPTIONS to set very specific options specifically for the Eternity Engine, as it's the only option setting tool for that source port.

 

That's actually a problem because you now enter dangerous territory. What if other ports start supporting OPTIONS as well and do not obey the exact same semantics you assume?

 

28 minutes ago, Arsinikk said:

The way I support these ports is very different:

• ZDoom ports I often use ACS to fix things because some really old ZDoom ports don't support ZMAPINFO, or even DECORATE for that matter (ZDaemon).
• Eternity Engine, requires the use of OPTIONS to make sure certain Vanilla actions work right.
• DSDA Doom, PRBoom+, Woof, Nugget Doom, each use the complevel to ensure certain behaviours act as they should. The main benefit of these is that you can set a very specific complevel and it'll act as it should without having to add extra settings. 

 

36 minutes ago, Arsinikk said:

Let me give an example. For Hell Revealations MAP30, it features a ghost monster icon of sin. For many ZDoom ports, ghost monsters as a feature is unsupported. So Worst and I wrote a script to allow ZDoom and Eternity ports to be able to emulate the fight via ACS. The problem here is that the OPTIONS setting comp_vile should be turned off in Eternity, but obviously we don't want that in DSDA Doom or else the entire setup in that port would be borked.

 

Here you need to be careful again: You seem to assume that some features you depend on are only supported by certain ports and support level will never change. That isn't true. For example, GZDoom 4.12 DOES support COMPLVL and if you set up your ACS with the assumption that it doesn't you got a problem. As an example, COMPLVL vanilla enables ghost monsters in GZDoom! So, if you add a workaround it would now conflict with proper support of the feature.

Another thing that may happen is that Eternity starts handling COMPLVL as well, you again may run into conflicts with your assumptions no longer being correct for the port.

 

37 minutes ago, Arsinikk said:

To clarify, I think the OPTIONS lump in conjunction with MBF21 is amazing... But it's only amazing because all the source ports have agreed to support it in the same way. Unfortunately OPTIONS is a legacy lump used by Eternity that sometimes requires certain tweaks to get it fully compatible with the port. And since I'm targeting "Vanilla" compatibility, the behaviours of "Vanilla" have already been set in stone. This is why I don't see why we can't specify this further.

 

 

Here you point out a genuine item of concern. TBH, considering what you wrote here, DSDA should never have appropriated OPTIONS like this and instead chosen a different name. (Speaking of which, I really need to start supporting this for MBF21 complevel as well in GZDoom)

 

40 minutes ago, Arsinikk said:

I think the reason I am so frustrated, is I don't see why everyone wants to make it so difficult for Vanilla mappers to just automatically set a specific behaviour via a lump. Literally all this adding of UMAPINFO options into certain actions is just way more work, then just running the WAD with a simple "-complevel 2" parameter. COMPLVL is supposed to be like "-complevel" parameter but even easier and more automated for the player. The problem is it's actually easier and better for me to just tell people to use the old school "-complevel" parameter than it is to use the COMPLVL lump in general due to the lack of "vanilla" specification.

 

Nobody wants to make it difficult. What you have to realize is that most vanilla mappers don't work like you. They seem to agree on the 'canonical' feature set that is safely supported by all ports (i.e. avoiding ghost monsters, not depending on the Final Doom teleporters and a few other things that Boom fixed.) and as a result the ports never gave priority to handling such outlier needs seamlessly.

And if you want to support older ports or older versions of existing ports with less awareness you really have to be careful as actively supported ports may hear what you say and adjust how they work to better support vanilla mapping. So for example, if you add workarounds for older ZDoom variants (ZDaemon, 2.8.1 or Zandronum) and also add new standardized features like COMPLVL that are in the process of being adopted by more ports you have to make sure they can coexist, i.e. you have to deal with the case that both are active at the same time.

I am also fairly certain that the Eternity devs read all of this and will eventually make adjustments. What then? You again got a problem that you load two conflicting implementations for your feature.

 

And then you have the unpleasant result that all your hard attempts to make your mod as compatible out of the box with as many ports as possible may backfire and break it for engines that support multiple of your approaches at the same time. Sometimes you should offload these things to a second file that can be omitted once the need for it ceases to exist.

 

[Arsinikk]

51 minutes ago, Graf Zahl said:

For example, GZDoom 4.12 DOES support COMPLVL and if you set up your ACS with the assumption that it doesn't you got a problem. As an example, COMPLVL vanilla enables ghost monsters in GZDoom! So, if you add a workaround it would now conflict with proper support of the feature.

Tbf I do disable ghost monsters in ZMAPINFO... so it really depends if GZDoom's implementation of COMPLVL and how it deals with that.

 

51 minutes ago, Graf Zahl said:

Another thing that may happen is that Eternity starts handling COMPLVL as well, you again may run into conflicts with your assumptions no longer being correct for the port.

Here's the thing. Would you rather me not add any support to any source ports? I could wait an "eternity" for the Eternity Engine to finally release a stable update with new features, or I can work with what I have. (Sorry, it's kind of a bad joke, even if sorta true)

 

Mappers can't wait for source port developers to implement certain features, or else they'd be waiting forever. This is especially funny to me because these features are literally Vanilla features from 30 years ago.

 

Regard ACS specifically, Worst and I have developed a script that detects certain source ports and only applies ACS based on which source port is being used. So if a source port adds support for something, it's rather easy to just exclude that specific port.

 

51 minutes ago, Graf Zahl said:

Here you point out a genuine item of concern. TBH, considering what you wrote here, DSDA should never have appropriated OPTIONS like this and instead chosen a different name. (Speaking of which, I really need to start supporting this for MBF21 complevel as well in GZDoom)

This is a fair point. Tbh the same could be said of the COMPLVL lump to a certain extent.

 

51 minutes ago, Graf Zahl said:

Nobody wants to make it difficult. What you have to realize is that most vanilla mappers don't work like you. They seem to agree on the 'canonical' feature set that is safely supported by all ports (i.e. avoiding ghost monsters, not depending on the Final Doom teleporters and a few other things that Boom fixed.) and as a result the ports never gave priority to handling such outlier needs seamlessly.

Well no one influential let boundaries dictate what they could do or not do. I am just looking at what options I have laid in front of me and making the best out of them.

 

I created this thread because I specifically care about how source ports have implemented the COMPLVL lump. If I didn't care, I wouldn't have said anything at all. I know it doesn't seem like it, but this isn't really about me. Yes my WADs are probably the most affected by it right now, but I care about the Doom community and want to allow future mappers to spread their wings regarding Vanilla behaviours. Right now this lump is sorta in the way of that, and I know rfomin said that they want to move past the "complevel" parameter. But that only works if the replacement is equivalent in its feature set. Which at the moment, it is not.

 

Would it not be fair to say that the main reason mappers don't tend to include stuff such as ghost monsters and the like nowadays is because ZDoom was the main port of the 2000s and didn't support the feature? You used to see lots of WADs exploit these things in the 90s because the ports at the time supported it. While I can't change history as it's already happened, I can try making a better future for mappers targeting Vanilla.

Edited April 25 by Arsinikk

[Arsinikk]

Edit: Ehhhhh... I'm gonna slightly retract my statement above where the crossed out section was... well or more amend it. The real reason some of these Vanilla bugs were lost was due to Boom and MBF, so that statement's not great. However I will say that it is probably true that because some of these were patched out, it led to mappers just simply not using them. And specifically ZDoom cut other features even more, so that part does kinda correlate to why mappers often don't use those features anymore.

[Graf Zahl]

5 minutes ago, Arsinikk said:

Tbf I do disable ghost monsters in ZMAPINFO... so it really depends if GZDoom's implementation of COMPLVL and how it deals with that.

 

ZMAPINFO overrides COMPLVL so that should be fine then.

 

 

5 minutes ago, Arsinikk said:

Here's the thing. Would you rather me not add any support to any source ports? I could wait an "eternity" for the Eternity Engine to finally release a stable update with new features, or I can work with what I have. (Sorry, it's kind of a bad joke, even if sorta true)

 

5 minutes ago, Arsinikk said:

Mappers can't wait for source port developers to implement certain features, or else they'd be waiting forever. This is especially funny to me because these features are literally Vanilla features from 30 years ago.

 

Regard ACS specifically, Worst and I have developed a script that detects certain source ports and only applies ACS based on which source port is being used. So if a source port adds support for something, it's rather easy to just exclude that specific port.

 

How do you try to detect ports? I've seen such things backfire on more than one occasion (e.g. scripts trying to detect the hardware renderer in GZDoom stopped working when the backends were unified and several mods broke as a result.)

 

 

5 minutes ago, Arsinikk said:

This is a fair point. Tbh the same could be said of the COMPLVL lump to a certain extent.

 

No, COMPLVL is quite clear in what it does, i.e. setting up the engine to one prefefined baseline. The main problem here is that you want to support ports that do not support it (yet), otherwise things would be a lot easier.

 

 

 

5 minutes ago, Arsinikk said:

Would it not be fair to say that the main reason mappers don't tend to include stuff such as ghost monsters and the like nowadays is because ZDoom was the main port of the 2000s and didn't support the feature? You used to see lots of WADs exploit these things in the 90s because the ports at the time supported it. While I can't change history as it's already happened, I can try making a better future for mappers targeting Vanilla.

 

Most of these changes originate from Boom and just not using the things that are not part of the Boom default was simply the easiest way to work on all ports without having to interfere with their operation. All the complevel stuff only appared many, many years later in PrBoom+. That meant 10+ years where there was no easy way to force any of the existing ports into a strictly compatible mode.

 

[Arsinikk]

5 minutes ago, Graf Zahl said:

How do you try to detect ports? I've seen such things backfire on more than one occasion (e.g. scripts trying to detect the hardware renderer in GZDoom stopped working when the backends were unified and several mods broke as a result.)

A set of source port exclusive CVARs are checked (i.g. GZDoom, ZDoom, Zandronum, Eternity). A percentage of matching CVARs is then aggregated for each port. Whichever port has the highest percentage is then determined to be said port.

 

7 minutes ago, Graf Zahl said:

No, COMPLVL is quite clear in what it does, i.e. setting up the engine to one prefefined baseline. The main problem here is that you want to support ports that do not support it (yet), otherwise things would be a lot easier.

I would argue it isn't clear, or else this thread wouldn't exist. By using the a name very similar to "complevel", you'd assume that COMPLVL would have the same functionality as "complevel". We've established that is not the case here.

 

9 minutes ago, Graf Zahl said:

Most of these changes originate from Boom and just not using the things that are not part of the Boom default was simply the easiest way to work on all ports without having to interfere with their operation. All the complevel stuff only appared many, many years later in PrBoom+. That meant 10+ years where there was no easy way to force any of the existing ports into a strictly compatible mode.

In a previous post, I quickly fell back on this. Yeah it's mostly Boom that cut the support. However my point still stands that since those features were not available in the most used ports at the time... Mappers just simply stopped using them. I'd like to lower the barrier to entry for those to actually be able to use these features, so that we can have more unique and interesting WADs in the future.

[hobomaster22]

If we are going down the path of turning on esoteric bugs as features, UMAPINFO should mimic the ZMAPINFO method of toggling individual compatibility options and leave COMPLVL alone.

[Professor Hastig]

UMAPINFO would indeed be the logical place for that, if it gets a 'defaultmap' section like ZMAPINFO has.

The existing OPTIONS lump would be even better if not for this:

 

On 4/25/2024 at 6:55 AM, Arsinikk said:

To clarify, I think the OPTIONS lump in conjunction with MBF21 is amazing... But it's only amazing because all the source ports have agreed to support it in the same way. Unfortunately OPTIONS is a legacy lump used by Eternity that sometimes requires certain tweaks to get it fully compatible with the port. And since I'm targeting "Vanilla" compatibility, the behaviours of "Vanilla" have already been set in stone. This is why I don't see why we can't specify this further.

 

This is something that really should have been considered when writing the MBF21 spec because this little gotcha makes OPTIONS somewhat of a landmine feature that can bring the whole house down.

MBF21 went to great lengths to do the right thing and limit the scope of OPTIONS, but as long as other ports also use it for general configuration setups it can cause serious clashes if a mod needs different settings for such an engine.

 

Maybe MBF21 should rethink this and use a different name instead? ZDoom also pulled this off when renaming MAPINFO to ZMAPINFO for similar reasons. Why shoulsn't the same be possible here?

[Xaser]

The underlined phrase in that post is not correct -- OPTIONS is a feature from MBF, which was preserved in Eternity, removed in Prboom-Plus, and restored for dsda-doom. The lump itself in dsda's case is just an interface for a series of comp_ flags, and the actual comp flag implementations were not removed from the codebase in Prboom-Plus -- i.e. the code that actually implements these options hails back from Eternity and DSDA's shared ancestor (MBF). It's the same feature.

 

If there's some sort of inconsistency on a particular comp_ option between Eternity and DSDA-Doom, then that's what needs to be fixed here -- they are absolutely intended to work the same.

 

[Side note: Eternity does add a few new options that are specific to itself, but dsda-doom no-ops on these so you can still set these EE-specific flags without breaking anything else -- again, unless there's some specific incompatibility with a particular option that needs fixing.]

[Arsinikk]

9 hours ago, Xaser said:

The underlined phrase in that post is not correct -- OPTIONS is a feature from MBF, which was preserved in Eternity, removed in Prboom-Plus, and restored for dsda-doom. The lump itself in dsda's case is just an interface for a series of comp_ flags, and the actual comp flag implementations were not removed from the codebase in Prboom-Plus -- i.e. the code that actually implements these options hails back from Eternity and DSDA's shared ancestor (MBF). It's the same feature.

Look I'm not gonna try and bit be too picky here, but what I said was correct. "OPTIONS is a legacy lump USED BY Eternity" I said that OPTIONS is a legacy lump. Which while I didn't say in the post, is in fact an MBF feature like you said. MBF came out in 1998, so OPTIONS is in fact a legacy lump. I also never said it was ONLY an Eternity lump. I just said it was the main lump you would use for Eternity to set compatibility settings. So at this point, OPTIONS is essentially the ZMAPINFO defaultmap, or COMPLVL of the Eternity Engine. Due to the Eternity Engine being the port that's slowest in development, OPTIONS is essentially the only current way to force settings.

 

As you can see, I've been down this rabbit hole a bunch of times. DSDA Doom doesn't read the OPTIONS lump in complevels under MBF, as OPTIONS didn't exist before then. This is a good thing regarding demo compatibility. OPTIONS shouldn't be used to overwrite a complevel, and only should be used to for the complevels that allow it's use (MBF, MBF21).

 

This is regarding DSDA Doom (which I'd consider the best way):

The complevel setting hierarchy goes a bit like this COMPLEVEL (parameter) > COMPLVL (lump) > OPTIONS. If the COMPLEVEL parameter isn't specified it then falls on the other two. OPTIONS is only engaged if COMPLEVEL and COMPLVL don't exist. In addition if the COMPLVL is set to "Vanilla" or "Boom", OPTIONS is disabled altogether. The COMPLEVEL parameter is the end all, be all, in that it will override every other lump regardless.

[Shepardus]

4 minutes ago, Arsinikk said:

This is regarding DSDA Doom (which I'd consider the best way):

The complevel setting hierarchy goes a bit like this COMPLEVEL (parameter) > COMPLVL (lump) > OPTIONS. If the COMPLEVEL parameter isn't specified it then falls on the other two. OPTIONS is only engaged if COMPLEVEL and COMPLVL don't exist. In addition if the COMPLVL is set to "Vanilla" or "Boom", OPTIONS is disabled altogether. The COMPLEVEL parameter is the end all, be all, in that it will override every other lump regardless. 

Complevel does not override OPTIONS (aside from OPTIONS being disabled for non-MBF complevels). Complevel determines whether OPTIONS is available and sets the defaults, but OPTIONS will override those defaults regardless of whether the complevel was set by -complevel, COMPLVL, or the menu option.

[Arsinikk]

1 minute ago, Shepardus said:

(aside from OPTIONS being disabled for non-MBF complevels

Ah yes I was thinking of this through a non-MBF complevel lense. Thanks for the clarification.

 

My real main point here was that OPTIONS gets disabled unless complevel (or COMPLVL) is MBF or higher.

[Xaser]

42 minutes ago, Arsinikk said:

Look I'm not gonna try and bit be too picky here, but what I said was correct. "OPTIONS is a legacy lump USED BY Eternity" I said that OPTIONS is a legacy lump. Which while I didn't say in the post, is in fact an MBF feature like you said. MBF came out in 1998, so OPTIONS is in fact a legacy lump. I also never said it was ONLY an Eternity lump. I just said it was the main lump you would use for Eternity to set compatibility settings. So at this point, OPTIONS is essentially the ZMAPINFO defaultmap, or COMPLVL of the Eternity Engine. Due to the Eternity Engine being the port that's slowest in development, OPTIONS is essentially the only current way to force settings.

 

No, what you're doing here is spreading misinformation (intentionally or not), then trying to grammar-lawyer your way out of the conversation when it gets pointed out.

 

BTW, a comp_ option doesn't have to be disabled in vanilla -- it could easily be whitelisted into lower complevels if that's where it's meant to be used, and comp_soul fits the bill. We have the source code; the behavior can change. Citing "the way it is" doesn't make any sense in a thread that's all about pitching a behavior change.

 

To be clear, I suggested the option because the proposal in the OP has already been shot down by all relevant port devs and I thought this approach would have a better chance of getting traction while still fixing the problem at hand. If you're going to react by shutting it down immediately and trying to rules-lawyer your way through any further discussion, then I doubt anyone else is going to bother assisting you any further. You're doing something extremely niche here, and there's very little incentive to address this case if it benefits precisely one person and that fellow is being difficult.

 

Port compatibility is hard. It's even harder if you decide not to work with the folks who develop the ports.