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? 

Do whatever Preach says. :) Thanks! 

A number of old releases were made for GLQuake and never tested in WinQuake or an engine that supports fullbrights. And as a result, you have fullbright patches in the map textures.

It is possible that in the future, some sort of informational only external .ent file could tell the engine not to use fullbrights on the map textures supplied in the .bsp.

Similar to the idea of producing external .ent files signaling the author's intended r_wateralpha value for the level.

I'm just filing this thought here. 

I have problems with these on practical grounds.

A .lit file can be associated with the source .bsp by comparing the size of it with the size of the original lighting lump.

A .vis file can be associated with the source .bsp by comparing the number of leafs in it with the number of leafs in the original leafs lump.

There's no such comparison available for .ent files.

Sure, you can do string comparisons of certain fields in the worldspawn entity but it just doesn't seem as robust.

I'm aware that Quakespasm has it's own way of checking these, by means of only loading them from the same gamedir, but I can see a case where someone might want to keep these modifications in a second gamedir so they have the option of playing with either the original content or modified content.

I personally have the extended Dismal Oubliette (among other things) in a pak2.pak in ID1 so how can I be sure that a hypothetical .ent file for it - even if loaded from ID1 - refers to the original version or the extended version?

I don't pretend to have an answer to this, just highlighting potential issues as they occur to me so that we don't end up with another half-baked standard that isn't as robust as possible from the outset.