Professor Hastig

And in the end, if a mod requires to change a global setting (which is bad per se) it now needs to alter its docs from "To play this mod as intended, go to the xyz-menu and set the abc-option to 123" to "To play this mod as intended, go to the console and change the abc CVAR to 123". Both should be a red flag that something was done wrong.

From what I remember, the only reason to even introduce the uncompressed format was the unwillingness of some ports to implement the decompression logic. Whether all ports that have implement extended nodes also support the compressed variant I cannot say, but I don't think so. There's just too many forks floating around and not all are up to date. If you disregard port support, the extended node format is actually better because it has full fixed point precision for vertices and nodes so it should be a lot less susceptible to slime trails or other node-based render glitches. BSP tricks are generally not format dependent, but you need a node builder that can generate them and output the node in the extended format - but to my knowledge such a node builder does not exist. You'd have to be very careful anyway because most of the time these tricks are not portable which makes it rather unappealing to support them in a format the vanilla engine cannot read.

They should work within the rules of the engine and not outside of it. And if the light mode is important to them they should expose the needed CVARs themselves. Let me repeat myself:

There's a few rules you should follow when using self-referencing sectors: 1. Any line within such a sector should have the same sector on both sides. If you don't the renderer will detect a visual boundary that causes render glitches. 2. If the node builder does not do what you want, choosing a different one is not a good solution because it's more or less a gamble to find one that just happens to do the right thing. Better fix the map so that it does not depend on what the node builder does with it. Some ports will always regenerate the nodes and those you cannot control. 3. Always be aware that subsectors do not have a sector reference in the map-provided data. They will only get it when the map is loaded and the assigned sector depends on which seg in the subsector is first. What you should do instead is add some untextured self referencing lines of the sector the player is supposed to stand on in a small enough grid that it will always touch one of these lines. This will ensure that any hole is small enough for nothing to fall in.

If this is so essential for those maps they should set their light mode through MAPINFO - which they should have done in the first place. So essentially this just confirms the need for the change, what we had before was a mapper option that was needlessly exposed to the end user. It is a lot better to force the mappers to think about it!

Let's just be realistic and look at the number of people voicing complaints, both at the forums and on Discord. My impression here is that is is a small number in the lower two-digit range at most who just got too attached to a specific setting that strays far too much from what is to be considered 'proper'. Does this really warrant a menu option? There's already far too many menu options and every time a discussion starts to streamline and condense the menu there are endless discussions like this where a small group of people cannot accept that what's in their opinion the most important menu option in the world (TM) is in reality a fringe setting that's never being touched by more than 99.9% of all users.

I remember dpJudas saying it was by accident, but when it was discovered there was no easy way to revert to the original formula anymore. In any case with a true colour hardware renderer the specific quirks of the vanilla mode tend to be far more pronounced to the point where it just looks bad. It's fine with a paletted software renderer where the coarse gradients make it stand out less.

It's supposed to be the lava filled crater of a volcano.

Correction: It's a Raven-ism that somehow got activated in Doom as well.

According to the Github logs, this got fixed one day after the 4.12.2 release.

There's no interest from me. The recent Doom games are nothing special, really, just more modern shooters. Whatever they do next will not and cannot bring back any of what the original 90's games brought to the table.

ZDoom will show demos if they are recorded with a compatible version. Of course that's not really feasible for released mods because the demo will break quite quickly as the engine gets new things added.

Windows 11 Intel Core i7-13700 32 GB AM Nvidia Geforce RTX 3060 12 GB 1 TB SSD + 5TB HDD plus two older 1920x1080 monitors. That CPU is really nice even for larger and more demanding maps, my last system was struggling a bit on some maps. One quick note to previous posters. 'i5', 'i7', 'i9' with a clock rate means nothing. It's the number afterward that defines the actual CPU. As an example, an i7-4700 is probably just half as fast as an i7-13700 with the same clock rate.

If you refer to the 4 TEXTURES warnings, that means your texture definitions may not be correct. Post the contents of that lump.

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