Shepardus

I get that, but GZDoom's all over the place when it comes to what options are saved and how they are saved. You've got compatibility flags, which are persisted in the config and also in save files (so loading a save with different flags set also changes your config), you've got gameplay flags, which are not persisted in the config but are in save files, you've got various graphics options, which are in config but not altered by saves, and now you've got gl_maplightmode, which is neither in config nor in saves. If the intended use is to set the option for specific maps when you need it, like you described, I would expect the value to persist in my save, like a gameplay flag. Others like NeoWorm want to set a default for all maps that don't specify a light mode of their own (like the current menu option allows, but only for a subset of the available light modes), due to their personal preference; for such use cases, it's most intuitive for light mode to work like other graphics options. Personally, I use separate config files when I'm playing mods with options significantly different from what I normally use. I can work with it by putting +gl_maplightmode in my ZDL config (and am actually doing that for something I've been playing recently), but it doesn't feel like a benefit to me for the option to not save.

Depends on who you ask. Some abhor it, some think it's part of the charm of the game (I'm in the latter camp). Some source ports have things like anisotropic filtering to mitigate the effect, so I'd say it's fine if your WAD exhibits such effects without filtering.

It'd be easier to take the complaints seriously if half the posts weren't misinformed about what the change is and who it affects, and half more interested in having someone "take the L" than in making any actual improvement. Just make gl_maplightmode save on exit and it'd solve the most valid complaint people have here (the inconvenience of setting it through other means) for those who deliberately seek out the option (if it's possible I'd just have the menu set gl_maplightmode directly, so there aren't both gl_maplightmode and gl_lightmode to worry about, and relegate the non-vanilla values to console-only).

Have you asked on ModDB or the Doom Infinite Discord server? I don't think the developers of Doom Infinite frequent this forum, and they are the ones who would best know what that error message means. Just to make sure, you are on the latest version of Doom Infinite (0.978.6) and GZDoom (4.12.2)?

I think changing the default to one of the more vanilla-faithful options makes perfect sense and was long overdue, for the reasons you stated. Maybe removing the other options from the menu and making gl_maplightmode not save was overkill, but just changing the default would have had the problem that it doesn't do anything for people upgrading from an older version, including people who never touched the setting themselves. I can also understand the devs wanting to discourage people from immediately reaching to it as a brightness option (which it really isn't, GZDoom has actual brightness settings).

Blade of Agony and Total Chaos might fit the bill (I haven't played them), also commercial GZDoom games like Hedon.

I'm not seeing a difference between "Classic (faster)" light mode (gl_lightmode 0, gl_maplightmode -1) and Doom light mode (gl_maplightmode 2). They should be the same since the function I linked before selects ELightMode::Doom at its end. The wiki mentions that the Doom light mode has "some added brightening near the current position," though.

They didn't remove the "Doom" option from the menu, it's just been renamed to "Classic." https://zdoom.org/wiki/MAPINFO_options_for_GZDoom's_GL_renderer Here's the place in the source code that determines the order of precedence: https://github.com/ZDoom/gzdoom/blob/c693e3b0731707351cd166aa160aaa7803751d89/src/g_level.cpp#L159

gl_maplightmode does not override MAPINFO.

For (G)ZDoom, you can use the NoFreelook property in the MAPINFO map definition.

The other buildings shouldn't be featureless brown slabs either (unless they're 33 Thomas Street), but they only have so many pixels and colors to work with.

You still have the choice, just add +gl_maplightmode <number> to your launch options or download that one mod that adds it back to the menu.

Played through the demo level, worked pretty well. Only problem I faced was that the audio starts lagging behind the video after restarting the game (use key after dying), not sure if that's just my computer/browser (I'm using Firefox). Neat demonstration of several projects at once!

The revenant missile.

Blade of Agony sets the light mode in its MAPINFO, so you get the intended light mode regardless of the menu options.

It's a Discord CDN link, Discord made a change some time ago making their CDN links temporary, breaking a significant portion of images posted on this forum.

I didn't have any problem understanding Doom's skill levels, obviously I didn't know the specifics but I just chose the middle/default option. But even being experienced with Doom, Hexen's skill levels still managed to confuse me - reading titles like "knight," "warrior," and "berserker," I think of class names (even though this is after the class selection) or even subclasses, not difficulty selection. It doesn't help that the skill names are different for each class.

With Chocolate Doom you may need to use -merge instead of -file. Naming works the same way whether it's a decoration or some other thing; for each frame you need either rotations 1-8, or 0 (which is for no rotations).

X2A8, X2A7, and X2A6 should be A2A8, A3A7, and A4A6, respectively. Each letter and number pair represents an animation frame (the letter) and rotation angle (the number), e.g. PLAYA1 is the player sprite for frame A, rotation 1. If you have two number+letter pairs in a lump name (e.g. A2A8), that means the same sprite is mirrored for two different angles, but the same naming convention still applies; A2A8 means frame A angle 2 and frame A angle 8, etc. The way you've named your lumps, you have a sprite for X1, three sprites for X2, and one for X5, so Nugget Doom is telling you that it's missing rotations 3, 4, 6, 7, and 8 for frame X. I think Chocolate Doom is complaining that both the PLAYX2A8 lump in your WAD and the PLAYA2A8 lump from the IWAD map to A8. I'm guessing you actually mean for these to be rotations 1-8 of frame A, so they should be numbered and lettered as such. Reference: https://doomwiki.org/wiki/Sprite (also just look at how things are named in the IWAD)

You left some unused textures RAIN1, RAIN2, RAIN3, RAIN4 referencing nonexistent patches in your TEXTURE1 lump. Remove those and the WAD should load. By the way, this sort of thing should go in the Doom Editing subforum.

Gamers in 1994 didn't have a queue of dozens of megawads to check out, so spending some quality time with Doom II wasn't a slog, it was what they paid for.

"Doom: The Dork Ages" sounds like a coming of age story about Doomguy as an awkward schoolboy.

Doom pioneered first-person shooter gameplay, and Quake was a technical marvel long before it was open source. They're not the only games from the time period to have had their source released, either. If you mean being open source is why they're still relevant, then I'm inclined to agree, but it had nothing to do with their initial success.

Between MAP01 and ENDMAP you should just have TEXTMAP and ZNODES. I think you need to move the extra stuff out of the way. https://zdoom.org/wiki/Universal_Doom_Map_Format#Map_lumps

Frankly, if someone telling you to stop pushing against the author's privacy "ruins" it for you, I don't think it was ever meant for you.