So, GZDoom has replaced its sector light options...

[NeoWorm]

12 minutes ago, Shepardus said:

They didn't remove the "Doom" option from the menu, it's just been renamed to "Classic."

And that's definitely not true. Just lauch the game switch options to Classic (faster) and than switch to DooM mode by console. The difference is apparent. No current mode offers no glow around player and propper darkness sector have light set to 0.

Also I see that the wiki page was updated since I was looking into this matter last time. Good at least something was done. Now please add back the DooM and Dark options.

[Shepardus]

7 minutes ago, NeoWorm said:

And that's definitely not true. Just lauch the game switch options to Classic (faster) and than switch to DooM mode by console. The difference is apparent. No current mode offers no glow around player and propper darkness sector have light set to 0.

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.

[NeoWorm]

Last time I was trying to fix my map, that this change to sector light modes broke, there was definitively difference and couldn't get it to look right unless I set it to Doom light mode that I was hapilly using since the feature was added to GZDooM. I can't check right now, maybe later but I posted some screens before.
The lightening around player is a feature that should be option anyway. Vanilla and Software both have it very strong and it clashes quite a lot with sector light gradients and dynamic lights. If I want player to glow, I will give him dynamic light, thank you...

[Bauul]

8 hours ago, akinata said:

funny how you first talk about how you like gzdoom forcing onto players the light mode you prefer, but then ask mapper to put their preferred one inside a mapinfo. can't you do the same on your maps and leave player who like having the light setting inside gzdoom alone??
no need for gzdoom to get read of ESSENTIAL options.

 

My take is that every mapper, if they're targeting GZDoom, should specify a lightmode.  The different lightmodes change things so much that if a mapper has spent any degree of time fine-tuning the lighting then they should probably specify a lightmode so their hard work isn't lost by a player using a different lighting engine.

 

But if a mapper isn't targeting GZDoom (and the map is still fully compatible), it's more likely they're targeting a software renderer or "more traditional" source-port like DSDA.  In those cases, the lightmodes that most closely resemble the original Doom renderer (i.e. the ones available in the options menu) are the right choice, because that's what the map will have been designed around.  So having those as the ones available in the menu makes sense.

 

And if a player really wants to use one of the old lightmodes (because they understand what they are and like the look of them) then the console / autoexec is there for them.

 

Maybe I'm missing something but this seems logical to me?

 

2 hours ago, NeoWorm said:

The lightening around player is a feature that should be option anyway. Vanilla and Software both have it very strong and it clashes quite a lot with sector light gradients and dynamic lights. If I want player to glow, I will give him dynamic light, thank you...

 

The lightening around the player is a fundamental aspect of how Doom plays, all the classic levels are designed around it, and all software renderers (and more traditional OpenGL renderers like DSDA's) all feature it.  Given GZDoom is a fundamentally a Doom source port, having the defaults reflect the base game seems like a sensible move.

 

If you're playing a map that features dynamic lighting or more detailed lighting gradients, then it's likely a map designed for GZDoom, and therefore the mapper should have specified the right lightmode in the MAPINFO anyway.  And if they didn't for whatever reason, you can just force it in the console.

 

Nothing here seems too controversial to me to be honest.

Edited June 14 by Bauul

[Xaser]

Just a PSA for folks: if the author of your favorite GZDoom map(set) hasn't specified a lightmode in their MAPINFO, that's a very good thing to report to the author. Many people simply don't know that the option exists, or why it's important.

[Shepardus]

15 minutes ago, Bauul said:

But if a mapper isn't targeting GZDoom (and the map is still fully compatible), it's more likely they're targeting a software renderer or "more traditional" source-port like DSDA.  In those cases, the lightmodes that most closely resemble the original Doom renderer (i.e. the ones available in the options menu) are the right choice, because that's what the map will have been designed around.  So having those as the ones available in the menu makes sense.

 

And if a player really wants to use one of the old lightmodes (because they understand what they are and like the look of them) then the console / autoexec is there for them.

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

[akinata]

1 hour ago, Bauul said:

But if a mapper isn't targeting GZDoom (and the map is still fully compatible), it's more likely they're targeting a software renderer or "more traditional" source-port like DSDA.  In those cases, the lightmodes that most closely resemble the original Doom renderer (i.e. the ones available in the options menu) are the right choice, because that's what the map will have been designed around.  So having those as the ones available in the menu makes sense.

 

And if a player really wants to use one of the old lightmodes (because they understand what they are and like the look of them) then the console / autoexec is there for them.

 

Maybe I'm missing something but this seems logical to me?

asches 2063 didn't specify any light mode but you get the full experience with the dark light mode.
that mod isn't just an unpopular niche mod...

why not let player choose inside the menu? why force them to use command lines?...
i don't like the glow. why force it onto me? i don't care about the "vanilla experience".

[Xaser]

43 minutes ago, akinata said:

asches 2063 didn't specify any light mode but you get the full experience with the dark light mode.
that mod isn't just an unpopular niche mod...

 

Ashes is a GZDoom project -- if it's designed to work with a particular lightmode, it should specify it in its MAPINFO. If the author does explicitly support multiple lightmodes or their stance on the topic is "yeah use whatever, they all look fine", then sure, it can be left out -- but far more often than not, mappers aren't using it because they don't realize it exists.

[akinata]

38 minutes ago, Xaser said:

 

Ashes is a GZDoom project -- if it's designed to work with a particular lightmode, it should specify it in its MAPINFO. If the author does explicitly support multiple lightmodes or their stance on the topic is "yeah use whatever, they all look fine", then sure, it can be left out -- but far more often than not, mappers aren't using it because they don't realize it exists.

or they just want to allow players to tailor their experience. instead of forcing one specific way of playing.
if mappers consider some light mode to be THE ONLY WAY of playing their map they can set that in mapinfo right?
no need to delete options.

[Xaser]

2 minutes ago, akinata said:

or they just want to allow players to tailor their experience. instead of forcing one specific way of playing.
if mappers consider some light mode to be THE ONLY WAY of playing their map they can set that in mapinfo right?

 

That's exactly what I'm saying said in the post you're quoting. I'm not sure what you're trying to say here, unless we're in agreement on this. :P

[Blzut3]

On 6/13/2024 at 2:30 PM, akinata said:

i don't understand their choice of getting rid of such an essential lighting effect just because it's not the most popular on polls.

I'm pretty sure there's around three of you that consider this option "essential."  Most of the people that made complaints were complaining about not being able to use it as a hack to increase brightness (and are more or less satisfied with the autoexec option because they aren't changing between modes for any reason).  At the very least searching the forums don't turn up anyone complaining since a few weeks after 4.11 was released except for the recent bumps.

 

For you power users that play with the light modes there are many tools as your disposal to continue to play with them (make separate GZDoom short cuts for each light mode for example).  They may not be quite the same workflow as before, but for everyone else by encouraging the use of the mapinfo field the experience is meaningfully improved for everyone else in the long run.

[Lila Feuer]

Lmao there's way more than three buddy, just because they won't voice their discontent on Doomworld does not mean they don't exist. What is going on in here?

There's no further complaints because the complaints aren't being addressed or rather taken seriously and it's all just half-ass compromises because nobody on the dev team wants to actually take the L for this decision. It's halfway up there already, so just sit on it. I'm done, I'll let other users like NeoWorm waste their time arguing with a wall.

[Shepardus]

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

[Xaser]

A side thought here: if the reasoning behind removing the save-on-exit behavior was to reset the option back to default for everyone, that could also be achieved by changing the name of the cvar to something new, so any previous configs just ignore the old value. If that gets done, and the new name gets saved to the config, that would only require folks to set it from the console once before it "sticks". Since MAPINFO takes precedence anyway, that won't trip up any GZ projects that need something explicit, and folks setting the cvar are consenting to modifying the base game at that point.

[Blzut3]

29 minutes ago, Shepardus said:

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

I would consider the ephemeral nature a feature since if I come across an old mod that needs a certain light mode I can set it temporarily without having to remember to reset it to software for the next mod.  As I suggested in my last post I'd set it via the command line along with the mod files so it would effectively persist across play sessions of that mod (in my case in my bash history, but could easily be a short cut or launcher profile etc).  I strongly believe all the tools needed are there and this is just an xkcd 1172 moment.

 

1 hour ago, Lila Feuer said:

Lmao there's way more than three buddy, just because they won't voice their discontent on Doomworld does not mean they don't exist. What is going on in here?

I did look in more places than Doomworld.  While there happens to be three in this thread, I'm not convinced from what I've seen elsewhere that the number is that much higher to change the point.

[Shepardus]

30 minutes ago, Blzut3 said:

I would consider the ephemeral nature a feature since if I come across an old mod that needs a certain light mode I can set it temporarily without having to remember to reset it to software for the next mod.  As I suggested in my last post I'd set it via the command line along with the mod files so it would effectively persist across play sessions of that mod (in my case in my bash history, but could easily be a short cut or launcher profile etc).  I strongly believe all the tools needed are there and this is just an xkcd 1172 moment.

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.

Edited June 15 by Shepardus

[Li'l devil]

Remove lighting from GZDoom maps altogether and force mappers to rely only on dynamic lights like in Doom 3!!

[Xaser]

1 hour ago, Blzut3 said:

I would consider the ephemeral nature a feature since if I come across an old mod that needs a certain light mode I can set it temporarily without having to remember to reset it to software for the next mod.

 

I still feel like this is a great case for GZDoom's auto-compatiblity stuff -- If a wad explicitly documents which lightmode to use, but doesn't set it in MAPINFO, add a hash for the map to gzdoom.pk3 to auto-set it. Then those of us goofballs who know how to make a GZDoom PR can patch 'em when we find 'em. 

[Edward850]

2 hours ago, Blzut3 said:

I strongly believe all the tools needed are there and this is just an xkcd 1172 moment.

It's extremely funny you say this because I mentioned this exact xkcd comic as well in a private conversation about this thread. Sort of the main problem with this "feature" and the complaints about removing it is people were using it for something it objectively wasn't for, the sector lighting model only coincidentally changed brightness but it never had anything to do with that but rather how light diminishing even worked, or in some cases how it didn't, it only existed as a function to provide compatibility for a specific subset of maps designed around entirely different rendering models. GZDoom already has a brightness control, and it can now fully replicate the intended lighting model of most maps so the feature actually outlived its entire purpose, and it was a mistake to even have it as an option instead of automatic detection (it should have been possible for example to detect Doom Legacy maps and thus switch to that).

Edited June 15 by Edward850

[Kinsie]

The whole lighting choice system was a giant cluster-fuck that caused far more problems than it solved (see: one level I collaborated with someone else on having the geometry blocked out for one light mode with texturing and detailing done for another) and I am glad the user-menus side of it was taken out behind the shed and thoroughly Old Yeller'd while keeping it on the mapper-controlled MAPINFO side. It was long, long overdue.

That people are furious about it almost a full year on is honestly more confusing than anything - If you're gonna be pissed off about GZDoom design decisions, there's probably 50 more deserving candidates.

Edited June 15 by Kinsie

[Shepardus]

IMO the biggest problems with the light mode options were (1) their names, which were so unhelpful it's impressive, and (2) the default setting, which was simultaneously not faithful to vanilla and also dark enough that it led people to change it before they knew what they were doing (it also doesn't help that seeing an option that literally says "Dark" leads one to believe it has something to do with brightness). Its being configurable by users isn't the problem, especially with mappers being able to set it through MAPINFO.

 

15 minutes ago, Kinsie said:

If you're gonna be pissed off about GZDoom design decisions, there's probably 50 more deserving candidates.

That I can agree with.

[akinata]

10 hours ago, Kinsie said:

The whole lighting choice system was a giant cluster-fuck that caused far more problems than it solved (see: one level I collaborated with someone else on having the geometry blocked out for one light mode with texturing and detailing done for another) and I am glad the user-menus side of it was taken out behind the shed and thoroughly Old Yeller'd while keeping it on the mapper-controlled MAPINFO side. It was long, long overdue.

That people are furious about it almost a full year on is honestly more confusing than anything - If you're gonna be pissed off about GZDoom design decisions, there's probably 50 more deserving candidates.

what's confusing me is how people like you are happy to take out QOL because of some imaginary problems the user might have when the creator can just set up his mapinfo how he wishes for.
if you have issues working with other creators because you are both not using the same light mode it is a you problem, not us.

now i am forced to "gl_maplightmode 3" everytime i use gzdoom and it is annoying.
i don't care if your map is meant to be played with glow. either force it via mapinfo or i will play it with dark. because thats what i like.

[akinata]

13 hours ago, Shepardus said:

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

so basically just like it was before but with the setting hidden??
just put it back inside the menu but hidden behind a switch if you don't want the casuals to use dark mode...

[akinata]

14 hours ago, Blzut3 said:

I'm pretty sure there's around three of you that consider this option "essential."  Most of the people that made complaints were complaining about not being able to use it as a hack to increase brightness (and are more or less satisfied with the autoexec option because they aren't changing between modes for any reason).  At the very least searching the forums don't turn up anyone complaining since a few weeks after 4.11 was released except for the recent bumps.

what we hate is the glow. Dark mode was the only one that had nice darkness AND no glow, but still bright lights and outdoors.
there is way more than just 3 people. most ppl just don't bother coming here. and even if there wasn't many, getting rid of a QOL setting just because it is not popular enough is dumbfounding.

[Redneckerz]

11 hours ago, Edward850 said:

It's extremely funny you say this because I mentioned this exact xkcd comic as well in a private conversation about this thread. Sort of the main problem with this "feature" and the complaints about removing it is people were using it for something it objectively wasn't for, the sector lighting model only coincidentally changed brightness but it never had anything to do with that but rather how light diminishing even worked, or in some cases how it didn't, it only existed as a function to provide compatibility for a specific subset of maps designed around entirely different rendering models. GZDoom already has a brightness control, and it can now fully replicate the intended lighting model of most maps so the feature actually outlived its entire purpose, and it was a mistake to even have it as an option instead of automatic detection (it should have been possible for example to detect Doom Legacy maps and thus switch to that).

It is retroactively speaking, but there should have been a lot more enforcement on mappers misusing (and abusing) certain flaws. For every misused flaw a compatibility option had to be made. Its not just the lighting model.

 

That some mappers said bah humbug and went with it anyway is precisely why corrections like these have had to be made.

 

1 hour ago, akinata said:

what's confusing me is how people like you are happy to take out QOL because of some imaginary problems the user might have when the creator can just set up his mapinfo how he wishes for.
if you have issues working with other creators because you are both not using the same light mode it is a you problem, not us.

now i am forced to "gl_maplightmode 3" everytime i use gzdoom and it is annoying.
i don't care if your map is meant to be played with glow. either force it via mapinfo or i will play it with dark. because thats what i like.

Thing is very few mappers actually know you can set up MAPINFO for that so they will retain their own preferences.

 

Then there's also folks who use DarkDoomz to correct any of these flaws.

 

But yes, the fact that there is a option remaining but you have to create a separate bat for it really is a huge struggle.

 

51 minutes ago, akinata said:

just put it back inside the menu but hidden behind a switch if you don't want the casuals to use dark mode...

That's only mildly different than everything suggested so far, isn't it?

 

I swear sometimes you lot are really interesting. Especially when it comes to GZDoom.

46 minutes ago, akinata said:

most ppl just don't bother coming here.

I wonder why. Maybe if one forfeited nagging (Or even better, attempted to understand why the whole spiel was wrong in the first place) you wouldn't be so used to it. What you advocate for is incorrect behavior, which you have become conditioned to as the right or correct way.

[Shepardus]

1 hour ago, Redneckerz said:

Then there's also folks who use DarkDoomz to correct any of these flaws.

I was actually going to mention DarkDoomZ as an example of a gameplay mod that works best with particular light modes. The glow around the player in software and vanilla modes looks particularly out of place when you've darkened the maps with it, and goes against why you would want to use the mod in the first place (the mod gives you a flashlight for looking around). The glow is a lot less pronounced in Doom/Classic mode but still there. Dark mode legitimately looks best when using the mod, and not just because it's dark. Should gameplay mods also use MAPINFO to set their preferred light mode? Should players set gl_maplightmode every time they use that mod?

Edited June 15 by Shepardus

[Kinsie]

3 hours ago, akinata said:

what's confusing me is how people like you are happy to take out QOL because of some imaginary problems the user might have when the creator can just set up his mapinfo how he wishes for.

Having 20 cryptically-named, varyingly-terrible options with no explanation beyond "i dunno it's just a hangover from a zdoomgl build from back before the korean war began" isn't "QOL". In fact, it's rather the opposite.

 

GZDoom's menus, while still better IMHO than the Boom-style menus in other source ports, are still pretty terrible at letting you find what you want in any fast or convenient way. They desperately need an overhaul, but attempting to trim down that nightmare to something usable is surprisingly difficult, and the current "fast options menu" attempt leaves a bit to be desired.

Edited June 15 by Kinsie

[Shepardus]

3 hours ago, akinata said:

so basically just like it was before but with the setting hidden??
just put it back inside the menu but hidden behind a switch if you don't want the casuals to use dark mode...

To me the console already is kind of a "menu hidden behind a switch," which is why I am okay with shoving some of the options behind it. Which is how it is now with gl_maplightmode, but I don't buy the arguments that it's better not to save the option. I also find it hard to believe that having two options that do the same thing, but one saves in the config and the other doesn't, and they also have different numbering, is really the best we can do.

[akinata]

3 hours ago, Redneckerz said:

I wonder why. Maybe if one forfeited nagging (Or even better, attempted to understand why the whole spiel was wrong in the first place) you wouldn't be so used to it. What you advocate for is incorrect behavior, which you have become conditioned to as the right or correct way.

the answer is simple. because most player just do not care going on some niche forum to discuss about a niche game.
what incorrect behavior am i advocating for?? i am confused...

[Redneckerz]

37 minutes ago, akinata said:

the answer is simple. because most player just do not care going on some niche forum to discuss about a niche game.
what incorrect behavior am i advocating for?? i am confused...

I very much doubt DoomWorld is a niche forum. And the ZDoom Forums... well, i didn't see this thread over there.