ZDoom

Floor damage for monsters doesn't sound right with no features in the AI code to recognize and evade such places.
That reminds me a bit of Quake 2 where enemies stupidly run into lasers, getting themselves killed although by all accounts they should never have gotten close to that point.

Aren't there enough questionable pain flags already? The code looks horrendously convoluted to handle all the special exceptions that were added to it.

From looking at the code it seems this was merely done as a distinct style to help keeping the CheckFuzz function clean, because it operates on a render style alone and has no access to other fields. So the only choice to keep this style of fuzz rendering working was to make a new style out of it.

That's something I've been looking for for a long time. The workaround I tend to use was to make a copy of directory 1, then copy the files of directory 2 into it and then compare the copy with directory 1 and delete all files that are the same. It can be really annoying and time consuming when ...

You won't be able to address the problem with level postprocessing. It gets triggered while the level runs by performing an overeager sector type transfer that transfers the secret flag along with the desired parts of the flag field. You need at least a new compatibility flag here to have both the ...

Don't exaggerate. There was no performance loss at all. Just read up on what several people found out about how more modern versions try to even out the duration of a tic. Those 40000 monsters take their toll just as much on older versions. It's just the frame rate display in older versions that ...

That's not really the issue. GZDoom hasn't gotten slower since 2.2. All that changed was how average fps get reported. This map even runs just as badly on the most powerful PC at my workplace. CPU speed alone does not help with 40000 monsters where it all gets bogged down in cache misses. 2.2 does ...

Bait is putting it mildly. The whole thing looks like an ill-informed but deliberate attack, considering how little information got initially provided, both here and on Youtube.

Most of the work presently being done to comply with the spec as much or as little as GZDoom does is being done by third-parties, not the core developers. I have a sneaking suspicion that ports will just implement what they feel like, and map authors are going to end up saying "this map requires ...

It is hard to tell what they did - there's too many random changes throughout the code which makes comparing it very hard, much less finding the commit where they branched off.

No, 3D floors are static entities in the map. You can hide them but not remove them.

I think it is a huge problem if the author of the spec does not even consider differing opinions and openly stating that as long as he and some of his friends are okay with it, it is not going to change. A spec that doesn't at least acknowledge that not all ports are created equal is never going to ...

I have stopped putting sensitive data into my 'user' folder because of this. So thanks to making the preferred way to work unsafe I'm now back to global folders in the hard drive's root, i.e. what we used before Windows XP...

The main issue here is not features - the main reason for keeping the old light mode is that it is considerably cheaper on hardware resources which on low end GPUs can mean better frame rates. I have an old laptop for testing where on some maps this means 60 vs 50 fps. As long as the engine intends ...

Or the whole "rocket jumping" Randi added to ZDoom with no real way of turning it off. We all know what the euphemism Randi-style "improvement" , invented by Graf, means. There's two compatibility flags for this now so this one can be considered solved - thank God! :P The whole point of a standard ...