Graf Zahl

Did he tell you why they need to be removed?

How did you define the deep water? With Boom-style Transfer_Heights or with 3D floors. The Boom-style version has some weird semantics with scrolling due to some historic errors in its implementation.

The "more advanced" stuff is impossible to pull off outside an 8 bit software renderer. Even after so many years there is still no hardware that supports programmable blending.

The existing implementation is extremely awkward to use, you can easily let the engine generate the TRANMAP from a transparancy percentage value as needed instead of requiring the mapper to do this. It's also a lot easier to handle for hardware rendering where alpha values are the native way to blend colors.

Doom does not have any friendly AI code at all. So even if you managed to make your monsters not attack the player there is no way that they could acquire other targets outside of being attacked themselves. Not even Boom can do it, friendly monsters were added in MBF.

Considering that lots of games, especially older ones, feature an "extra hard" setting as their highest choice, there's lots of games I never played on it. Another thing that keeps me from it is that I do the first playthrough on the recommended skill and there's many games I never replayed after finishing once (or sometimes giving up before that)

ZMAPINFO overrides COMPLVL so that should be fine then. 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.) 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. 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.

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. 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? 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. 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) 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.

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

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.

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.

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.

I use Dosbox for things that have no working Windows equivalent but that's it. Playing games with Dosbox is an inferior experience mainly due to the assumptions being made about display hardware back in the day.

They won't help because no source exists. Also, we already got Delta-Touch as a base to derive from. Who knows? The main problem with the GPL is that it is entirely written in excessive legalese to make sure even the smallest loophole is covered. The result of this is that people tend to be careful because no normal person will be able to decipher this cryptic text and even lawyers depend on interpretation that may or may not hold up in court. At all the places I worked at over the last 20 years or so there always was a strict 'no GPL source' mentality, i.e. the general attitude was that even reading GPL code on work related things was considered dangerous. Although I doubt this case will ever be contested in a court of law, the same attitude towards the GPL still stands with many developers.

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. 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. 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. 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. 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. 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.