"You are ignoring mh's insights on how people out there actually play Quake."

Nobody here does that. And we all play Quake. 

 

I'm gonna say to make the fog command a mapper/mod setting that gets reset on map changes. With mods stuffcmding from triggers etc, doing otherwise is too unsafe.
If users want to override it, they can either do it on each map change or the engine can implmement something per-map like:
http://ezquake.sourceforge.net/docs/?commands#skygroup
maybe. 

I'm dismissing. 

Shame for us all, looking at Quake maps through mapper glasses on a Quake mapper forum.

Ah, but the question is: what's the purpose of releasing a map?

Sure, you can make a map for your own satisfaction (hell, even I've done that), but why release it? You release it to be played, by players, unless all you're interested in is a mutual back-slapping exercise among the mapping community. 

what's the purpose of releasing a map?

Can't justify working on it anymore. 

"You release it to be played, by players, "

Yes, and ideally they play the map you designed not the one they customized. :) 

I think there's a lot of cross purpose chat here, so I'm gonna try and post a few non-controversial things that everyone should agree on.

1. Maps with a fog key on should be loaded with those fog settings.
2. Going to a map with no fog key should reset fog to default in some sense.

There is a useful discussion buried somewhere in this thread, but it seems to be drowning amid people trying to argue in favour of 1. and 2. when actually nobody is arguing against them. mh, is this a fair point to start from? 

what's the purpose of releasing a map?

The feeling of self achievement of having a "thing" under my name being "out there". The knowledge that I've learned a lot in the process of making it. The enjoyment I get from playing it. The knowledge that my target audience might even enjoy it. And if they don't, I'll get earnest feedback from them, because there is no "mutual back-slapping" in this community at all. (But you probably haven't noticed that, because you're a complete cunt.) 

Because he makes reasonable well thought out conversation points and great engines? 

Both of those points are questionable to say the least. 

Also, my cocern wasn't even so much about the questions "what the player wants" versus "what the mapper intends" than the risk of accidentally, unintentionally or unknowingly 'spoiling' a map with the wrong settings. 

OK, I think I phrased my preamble wrong. I wouldn't want to go as far as saying nobody would disagree with 1 or 2, simply that at the moment it doesn't seem like anyone here does disagree with either. 

Most players aren't going to customise the fog.

If they want to, that's fine by me - I always release the map sources and its not even my IP, so I've nothing to get shirty about.

It's just a bug; maps shouldn't inherit fog not intended by the creator. 

It's not just fog though, think of things like wateralpha too. I'd wager that custom wateralpha settings and vispatched maps are much more common than people using different fog settings. Quake is messed up. :} 

Fitz/QS have always reset fog on map changes (whether or not the map you change to has worldspawn fog). So do Darkplaces, FTE, DirectQ, RMQEngine, and Qrack. The only engine I know of that doesn't is ezQuake (e.g. map e1m1, turn on some fog, map e1m2 - the fog will still be there.)

The thing with Tronyn's jam map was just a weird bug - Fitz/QS were clearing fog on map changes by just resetting the density to 0, which would normally work fine, except Tronyn's map happened to only specify a density, so that was combined with the last set of fog colors used.

I don't think anyone's really arguing that QS should change its fog command to match ezQuake. 

I missed that in the back and forth.

So, just set all 4 values to avoid the bug... 

Yeah, my primary argument was towards just removing user configurable fog and skybox (thereby rendering the problem of whether to reset to no fog or user specified fog on a map change a moot point). 

+1. People think these trigger_cvarset maps are buggy. I'm scared to copy-paste this into my engine. Also, why is 'fog' is a command and 'r_skyfog' a cvar? 

My title was one char too long. Anyway, skyfog could be an arg tacked on to the 'fog' command. 

fog has 5 values then. 

Yes. That would be more consistent with expected behaviour and compatible with engines that don't support it. The 5th value would be ignored without crashing in that case. There could still be an r_skybox cvar for players to tweak. 

one issue with that is that DarkPlaces already uses the 5th value for fog alpha, which is different than r_skyfog. Not sure if any other engines already use it for something too.

I still think skyfog as a separate worldspawn key is the way to go. 

That would be even more compatible. Again it does not preclude r_skyfog. Also I should have said 'fog DENSITY r g b'... density is more accurate 

But you probably haven't noticed that, because you're a complete cunt.

Maybe I am, but this kind of thing seems well-worth discussing even if so. Would you not think that nailing down some predictable and consistent standard behaviour in a case where a grey area remains owing to sloppy and/or weak initial standardisation is worthwhile? Is that something that could be of benefit to the entire community?