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. 

How can you determine if an external .ent file is for the right .bsp?

Right now, you can't.

But I guess a .ent file could have some information about the expected .ent size or count it should be replacing, perhaps in the worldspawn section or some such thing. 

what about an md5 hash of the bsp file? 

how about... don't use the .ent file if it's lower on the search paths than the .bsp file of the same name?

i.e. id1/maps/e1m1.ent won't override mymod/maps/e1m1.bsp

likewise, a .ent in a pak file won't override a loose bsp in the same game dir. 

how about... don't use the .ent file if it's lower on the search paths than the .bsp file of the same name?

I'm not saying this is something that does happen, but I'd prefer a solution that can handle a case where somebody manages to get e.g a hipnotic start.ent into their ID1 directory.

This is mostly coming from reading various QuakeOne threads and observing the difficulties that people have with even getting the most basic stuff set up right. 

i think my suggestion would handle that by rejecting the start.ent (start.bsp would be later in the search path in that case.)

Hmm...

Actually a pretty good check would be to compare number of submodels in the bsp... since they are referenced in the .ent file right?

That would only fail if the .ent file doesn't use the highest-numbered submodel, which is still a point of failure i suppose.