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.

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

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.

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 .

Rest assured - it will happen. There's really no thing inconsequential enough that it WON'T happen. Compared to some things I witnessed over the last 20 years while developing GZDoom that hypothetical reaction is almost 100% guaranteed, just like I got countless reports of "I ran xyz on Doom (strict) and that passage was blocked", caused by running a ZDoom map with infinitely tall actors. The chance this will cause false reports is close to 100% unless the feature trigger is part of the map itself, like the proposed idea of using one of the free sector flags for it.

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?

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)

So much uninformed nonsense... The stuff you are talking about is at least 10 years out of date. Have you even seen what games can do on mobile these days? GZDoom is nothing compared to that. Regarding Metal, we use MoltenVK which also exists on iOS so that part should work with no problems. Video playback is absolutely secondary for Doom and could be disabled if push came to shove. No, you won't need HTML5 and 'native iOS languages' (whatever this is you are thinking about) to support the platform. It is well capable of setting up a window you can render into from C++ code. D-Touch works just fine on Android, so why shouldn't something similar work on iOS where you can take a lot more CPU power for granted than on Android where devices are all over the place.

You still need to answer the important question here: How is the engine supposed to detect which light value format is being used? MBF21 does not make any changes to how existing map fields are being interpreted, and there are no good facilities to flag a sector using a different format for an existing field. This is not an option. OPTIONS is not a standard, not all ports use it. You have to solve this problem within the map format itself and not via some tacked-on switches in a control lump (no, not even MAPINFO!) that change how certain fields are being interpreted. You might be better off placing a special thing type in the sector and use some of its fields to set such additional properties than making a potentially breaking change to the sector data.

The main question would be: Does Apple allow sideloading of apps? Once that is the case the Tivo clause won't be a problem anymore. Aside from the legal issues this is something better asked to the D-Touch object. Making the code work on another platform is one thing, having suitable controls is something entirely different and GZDoom proper has no touch controls at all.

In that case you make the center part wider. These are absolute edge cases that really do not warrant making the common use case more difficult.