Agreed. The map should dictate the fog settings. No other option really makes sense. If the player wants to change the fog AFTER the map sets it the way it wants it, then that's fine. But the map should dictate what it starts at. 

The bug was that on map changes, only the fog density was reset to 0. Now the rgb values are also reset to their defaults (0.3).

It's probably best to always specify all four density/r/g/b components in the worldspawn key; I just checked Darkplaces and jam3_tronyn.bsp gets black fog vs. gray in FitzQuake/QS. 

In principle I agree, but the doubt I have is that this is exactly what a mapper would say. Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.

I need to clarify that I'm not necessarily arguing in favour of the other perspective here: like I said, in principle I agree.

In practice what would be nicer to see is an agreed way out of this that involves both parties being able to have what they want; a way that lets mappers set their preferred fog settings (which could be no fog), that also lets players (and I'm primarily thinking of those who like to sex-up their Quake here, not that I necessarily agree with that mindset) set a fog that will persist over map changes, but that has a mapper-specified fog override a player-specified fog.

The major stumbling block here seems to be the convention of "no fog key in worldspawn = no fog". 

Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.

I'd be interested in hearing that equally forceful argument, because so far I'm pretty sure it doesn't exist. 

In principle I agree, but the doubt I have is that this is exactly what a mapper would say. Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.

To this, I only ask what other game lets you go in and change things like skyboxes and fog that are integral to the look of the game.

If I ever release another map, I'll stuffcmd the fog and skybox every frame just to be a dick. :P 

A compromise proposal:

Fog has a "background state" which is only ever set by direct use of the fog cvar. The fog key in worldspawn is treated as a temporary override of the background state - once the map ends the background state is restored before the next map loads. Background state can be "no fog". If a fog command is issued during the map, this will not only produce an instantaneous change, but also update the background state to the given settings.

Result: on load, maps with fog keys look like the author intended. Maps without a fog key appear as the player sets fog by default (sober people: none, eyecandy freaks: lots).

Of course, info_command entities changing fog throw a spanner in the works. I can think of two unpleasant ways to work round that, but I will practice restraint and post neither... 

Does Requiem support BSP2? 

If you do what Preach suggests for fog, you should consider doing it for skyboxes as well. 

Cousin to the EULA, all maps and mods will be released from this point forward with "End User Mapper's Agreement".

Any player who changes a graphical or gameplay setting, config file or other game enhancing feature, excluding and limited to key bindings, will void said EUMA and have said map/mod removed!

Now we just need the Mappers to DRM their creations to enforce it... 

I always thought the fog and sky commands in Fitz/QS were a good balance between mapper control and player tweakability. Yes, they're reset on every map load to the worldspawn values (or if not set, the engine defaults). I like this because I can mess with fog and not have to worry about restoring it to the original value.

If there is really a demand for a way to control the fog of maps with none set in the worldspawn, maybe a dedicated "r_defaultfog" cvar would be the cleanest. But I have to say, I'm not a big fan of the idea, e.g. my jam3 map has no fog setting in the worldspawn; it's really intended to be played with no fog, not "whatever fog". 

"To this, I only ask what other game lets you go in and change things like skyboxes and fog that are integral to the look of the game."

Yeah, I agree. We don't allow anything else to be customized ... what's so special about fog? 

Is there anybody who seriously goes and changes the density and color of fog, just for the sake of extra eyecandy? 

Absolutely, checkout the stuff at quakeone.com and the various HD packs. 

Yes, but should that override the mappers intentions? I mean, fog isn't chosen for a map at random. 

 

They do stop you seeing the level if you apply enough. 

Fog is one of the settings that HD packs like to set (afaik, I am not into that kind of stuff). 

We should add settings for tweaking color ranges. Like, if I don't like red lighting I should be able to tint it more towards orange.

Also, lava kind of sucks ... being able to switch that to slime would be great. 

Is anyone here colorblind? Not that this matters a lot, but perhaps there's an argument for a colorblind mode or somesuch. 

Dark Places let you change the colour balance with RGB sliders? 

 

oh, i thought you guys were actually interested in some kind of meaningful discussion. my mistake.

zwiffle: there is at least one ex-mapper. statistically about 5% of men are more or less, they rarely speak about it though. I know of 4-5 players but that's a fraction. 

RGB sliders for fog would be awesome... 

Yes, but should that override the mappers intentions? I mean, fog isn't chosen for a map at random.

That's not actually the point being made.

Of course if a map specifies a certain fog setting, the engine should honour it and the player should accept it. That's not in dispute.

The point being made is that where a map doesn't specify it's fog (or water alpha, or skybox, or whatever), right now there are two possible interpretations and both are valid:

(1) The mapper doesn't specify fog because the mapper doesn't particularly care, never thought to do so, or else the map predates engine support for fog.

(2) The mapper is explicitly specifying no fog.

Interpretation (1) is the only case where the player can go nuts with user-specified fog. This is the case that, if you look at the world through mapper-coloured glasses you, may miss becoming aware of.

Interpretation (2) is unambiguous: again, the mapper doesn't want fog and the engine should honour that. Again, that's not in dispute.

The problem is: how does the engine tell which of interpretation (1) or interpretation (2) is the case? 

#2 is the safe assumption.