[Engine Standard] Water Alpha

[Spike]

however, darkplaces commits the most henious of crimes, and that is that it infects other engines with its default settings.
that is, if you've ever run DP, you now have a config.cfg in your mod directory which contains r_wateralpha forced to 1, no matter what your favoured engine defaults to.
Thus an r_wateralpha 2 cvar value is pointless, as noone would ever get a chance to use it if they've ever used DP(and similar engines) in the past, unless they explicitly change it, that is.

Argue all you want, but r_wateralpha defaults to 1 (thanks to all these config.cfg files that have been written), and that must therefore be the value to use map settings for. Use 2 for force-opaque by all means... But 1 is map settings - if you use some other value, your user has to change settings to get it to look how it was actually meant to look in the first place, and that's just clumsy and stupid.

[Baker]

however, darkplaces commits the most henious of crimes, and that is that it infects other engines with its default settings.
that is, if you've ever run DP, you now have a config.cfg in your mod directory which contains r_wateralpha forced to 1, no matter what your favoured engine defaults to.

Well, I may be missing something with what you said, but here is how it works in DarkPlaces (at least in 2007) and likewise it is how it works in ProQuake and probably mostly or entirely in FitzQuake. I mostly use the FitzQuake cvar system [well, I'm rewriting it right now to a moderate degree ...] and clearly Metlslime intentionally designed FitzQuake to do it ...

1. engine starts, cvars have engine defaults
2. quake.rc is executed
3. default.cfg is executed by quake.rc (at least in standard Quake and it is really typical ... I mean a quake.rc doesn't have to execute a default.cfg)
4. ----------------------------------
5. stuffcmds --- now at this point the host is initialized. ALL cvars now have their intended default values right now.
6. ----------------------------------
7. config.cfg
8. autoexec.cfg

(And IMHO, autoexec.cfg is a kludge and unnecessary except for a server. A user-friendly engine wouldn't require a user to need to open a text file to do settings, but I digress ... while acknowledging engines like DarkPlaces have an incredible amount of features and the idea of saving 600 to config is unreasonable .... again don't want to get off track.)

Unfortunately, doing a cvar reset in, say, JoeQuake/FuhQuake + derivates (=Qrack/ezQuake) resets the cvars to engine defaults. This is wrong. There is no user-friendly way to get back to #5 where the true defaults have been set. Needless to say, I am reworking all of that in my experimental JoeQuake derived engine.

[Reseting to "engine defaults" only works if it entirely mirrors Quake, but what if a gamedir mod isn't using Quake defaults. Even though I don't like everything about DarkPlaces, I can tell the very organized manner that LordHavoc thinks ... if all computers could run the engine well and if all game content were remade "correctly" .... but now I double digress ... just looking through ancient DarkPlaces and seeing the changes LH made often give me a smile ... even in the old days he made very forward thinking changes.]

And sadly, there is one need for reseting to engine defaults. A gamedir change. The cvars need reset to engine default state in order to properly run a different gamedir and then run quake.rc

Too much info? Not really. This is Inside3d

[Spike]

that's the startup order, yes.

but you forget the shutdown order, and what happens when you upgrade/use other engines/versions.

8. user asks engine to quit. cvars have default.cfg/config.cfg settings for ones that were in there, and engine defaults for ones that were not
9. engine writes config.cfg, including all the extra cvars that the particular developer has decreed should be saved.

10. user uses a different engine, or an updated version of the previous engine.
11. startup order is re-run. r_wateralpha is set to the previous engine/version's default because thats what was written in step 8.

I should also point out that your step 7 overrides commandline settings, for any cvars that were saved.

any clearer?

(quake.rc is a kludge. when resetting cvars, reset to engine defaults then exec default.cfg - mods should avoid editing quake.rc other than to change the demo list stored in there).

[Baker]

that's the startup order, yes.

but you forget the shutdown order, and what happens when you upgrade/use other engine.

8. user asks engine to quit. cvars have default.cfg/config.cfg settings for ones that were in there, and engine defaults for ones that were not
9. engine writes config.cfg, including all the extra cvars that the particular developer has decreed should be saved.

10. user uses a different engine, or an updated version of the previous engine.
11. startup order is re-run. r_wateralpha is set to the previous engine/version's default because thats what was written in step 8.

I should also point out that your step 7 overrides commandline settings, for any cvars that were saved.

any clearer?

Well, is DarkPlaces writing a default.cfg? If not, the order is still valid. You replied before I mentioned the complexity of a gamedir change.

Writing a config.cfg does not interfere with the game defaults process.

[Spike]

The QuakeWorld community has a real love of configs. They have all sorts of things in there, teamplay scripts, colours, everything and its dog, specific sensitivity, weird quirks, random things they forgot about, etc. And you expect people to obliterate them by resetting to defaults every time they upgrade their engine?

Writing a cvar into config.cfg _does_ interfere with the game defaults process. It prevents the default from ever reliably changing again, because the old default is saved. You can't just change r_wateralpha to default to 2 without asking the user to change it explicitly, or to blow away their entire config.
Yes, if the user resets their settings back to defaults, then they get defaults.

<rant>
Also consider engines that do have the capability to switch gamedirs depending on what the server is using. A default that is not purged somehow will affect other gamedirs, and can be saved into those other gamedirs because of it. What should be purged? Name? sensitivity? video width? so now we have a video mode change and a name you had forgotten you'd ever used, as well as an unusable sensitivity.
</rant>

[Baker]

The QuakeWorld community has a real love of configs. They have all sorts of things in there, teamplay scripts, colours, everything and its dog, specific sensitivity, weird quirks, random things they forgot about, etc. And you expect people to obliterate them by resetting to defaults every time they upgrade their engine?

I mean this in the kind possible way towards the QW community especially since I was highly influenced by FuhQuake.net from way back when ...

But the QW community is attracted towards complexity like a moth to a bug zapper. I feel complexity is the opposite of user-friendliness.

I also feel that communities shouldn't be run by elite players --- elite players have all the sensibilities of how to destroy a game and no sense of the actual history of the prior golden age. Remaining in dying community isn't necessarily that your preferences are best, but maybe that the community is shaped in such a way that your preferences are all that remain. Any attempt to grow with such a mindset is guaranteed to fail because the symptom is perceived as the cure of the disease. Which is, of course, preposterous.

Ability to frag other people != wisdom. At the same time, weak players don't see the value of competition and mastery. A good balance lies in between ....

Writing a cvar into config.cfg _does_ interfere with the game defaults process. It prevents the default from ever reliably changing again, because the old default is saved. You can't just change r_wateralpha to default to 2 without asking the user to change it explicitly, or to blow away their entire config.

Yeah that's true.

<rant>
Also consider engines that do have the capability to switch gamedirs depending on what the server is using. A default that is not purged somehow will affect other gamedirs, and can be saved into those other gamedirs because of it. What should be purged? Name? sensitivity? video width? so now we have a video mode change and a name you had forgotten you'd ever used, as well as an unusable sensitivity.
</rant>

Obviously a lot of things that get stored in a config have nothing to do with a gamedir (video mode, sound preferences, input preferences, name/color/etc.)

Complicated decisions. A little muddy as to the answers.

[Spike]

Anyway, back to the topic...
r_wateralpha defaulting to 2 is not a solution. :)

[frag.machine]

How is setting a value to an already well known cvar that respects the map or mods decision an evil hack?

r_wateralpha was meant to hold a linear value between 0.0 and 1.0. Using it to also toogle a non-directly related behavior is too hacky to be part of a proposed standard behavior among engines (which BTW is the thread subject). But hey, it's just my opinion.

[Karatorian]

I think frag.machine is onto something here. I agree with his reasoning for two reasons. First, it avoids the kludgy overloading of an already existing cvar. Secondly, using a different variable would avoid the problem that Spike pointed out, namely, an existing r_wateralpha being stashed away in a config somewhere.

While using another variable does have the disadvantage of adding yet another cvar to the massive list already supported by engines these days, I think it would be the cleanest way to go about it.

The simplest solution would be a basic boolean variable. The basic boolean switch would be between "using the worldspawn wateralpha" and "using the r_wateralpha" value.

However, I do see room for more advanced options, so perhaps they should be considered. The only idea I've had is for a third option to specify a more advanced method of water blending with distance based falloff. I don't know if any engine at the moment has this sort of thing, but I imagine that that with the continuing drive for more advanced graphics, it will eventually happen.

Even though it's speculative at this point, I think it would be a good idea to think about making note of the possibility that whatever variable is chosen could be something more than a simple boolean and specify what to do if the value isn't just one or zero, so engines will have consistent fallback behavior if they don't implement whatever new water blending features may come about in the future.

The simplest behavior is to have the variable treated as a boolean for fallback purposes. That way, engines can use a single if condition to test it. (Which is what's going to happen anyway, so we might as well make that consistent with the spec.) This would mean that the fallback for an unsupported (future) mode would work the same as setting the variable to 1.

In that case I'm not sure which way the variable should function. Should the variable being positive turn using the map's wateralpha on or or off? Which makes more sense in light of possible future extensions and fallback behavior?

[Spike]

if the mapper explicitly wants transparent water, they can just create it as a brush with .alpha - but that requires that the engine permits you to swim in such bmodels.
If the mapper explicitly doesn't want transparencies then they shouldn't use watervis.
What's more useful is some clean fast way to detect watervis, and the ability to distinguish between alpha 0(default opaque) and 1(always opaque), which fitzquake can already do.

A worldspawn key filled in by the vis app which says which textures are watervised would be all that is really needed. This would aid in the case where the mapper just doesn't care, or isn't really aware.
The existing method of allowing transparent water results in seeing the void/through things, and that's bad.

[mankrip]

if the mapper explicitly wants transparent water, they can just create it as a brush with .alpha - but that requires that the engine permits you to swim in such bmodels.
If the mapper explicitly doesn't want transparencies then they shouldn't use watervis.
What's more useful is some clean fast way to detect watervis, and the ability to distinguish between alpha 0(default opaque) and 1(always opaque), which fitzquake can already do.

A worldspawn key filled in by the vis app which says which textures are watervised would be all that is really needed. This would aid in the case where the mapper just doesn't care, or isn't really aware.
The existing method of allowing transparent water results in seeing the void/through things, and that's bad.

Which is why I'm thinking about detecting this during runtime, rather than upon loading, so the engine can disable translucency for the map's liquid surfaces upon first detection of void, and re-enable it on the next map loading.

I think this may also fail in some cases, but should be quite reliable, and implementing it should be dead easy anyway. Hmm... playing some old maps with r_wateralpha set to zero may be a good way of checking out how reliable this method will be.

[mh]

Which is why I'm thinking about detecting this during runtime, rather than upon loading, so the engine can disable translucency for the map's liquid surfaces upon first detection of void, and re-enable it on the next map loading.

I think this may also fail in some cases, but should be quite reliable, and implementing it should be dead easy anyway. Hmm... playing some old maps with r_wateralpha set to zero may be a good way of checking out how reliable this method will be.

I had implemented something similar by checking for a leaf with CONTENTS_WATER (or _LAVA, etc) being visible in the same view as a CONTENTS_EMPTY leaf, but there were quite a few edge cases where it broke down. Detecting void seems like a good idea, but of course it would only work for a software renderer.