[Engine Standard] Water Alpha

[mh]

I think this discussion is not about forcing (the lack of) certain features on anyone, but about establishing sane defaults for those certain features.

Absolutely. I've personally no major preference either way, just shooting out an idea that came up in discussion elsewhere for the purpose of getting opinions.

[goldenboy]

Here we go again...

What about adding another worldspawn key/value pair allowing the mapper to set a global override for r_wateralpha?

I'm still referring to this.

[Baker]

Don't try to obsolete or replace r_wateralpha.

Supercede it.

The "sky" key in worldspawn supercedes the sky textures.

A wateralpha key in worldspawn could supercede r_wateralpha if it is detected.

It is really the only logical way to go.

A little signal to a supporting engine on how the presentation of a map should look. Nothing but the .bsp required = perfect.

(Please don't call the key r_wateralpha, because then 2 different things with the same exact name leads to confusion.)

[scar3crow]

If its not being done dynamically by view angle, brush thickness and material (lava and mud are not renowned for their translucency, and slipgates seem like they are 'thick' to me), it really seems like it should be done on a per brush basis, but that would be more of a QuakeC resolution, material_water, material_mud, material_slime, material_lava, material_slipgate, with individual keys for alpha.

[mankrip]

Here we go again...

What about adding another worldspawn key/value pair allowing the mapper to set a global override for r_wateralpha?

I'm still referring to this.

If this overriding happens only upon map loading, the user can still be able to change it later.

[Baker]

*snort*

Code: Select all

if (worldspawn_wateralpha != NULL && !developer.value)
{
    // use that and ignore users r_wateralpha setting entirely
    // Do whatever worldspawn indicates is the presentation of the map
}
else if (r_wateralpha <= 1.0f)
{
      // do r_wateralpha stuff
}

They could change r_wateralpha. It just wouldn't be used.

I added the idea of the developer.value in there because if you are actually working on the .bsp you might need r_wateralpha available for some reason during testing.

[mankrip]

It just wouldn't be used.

This is what goldenboy is complaining about, and I really don't see much reason to take away that flexibility, unless it's to prevent cheating. Any user with enough knowledge of the console can already do a ton of other things to break the intended visual of the map anyway.

A callback function in r_wateralpha could solve this, by telling the engine to use its value instead of the map-defined value, so it would be just a matter of the player reissuing r_wateralpha with its current value to override the map-defined value.

[frag.machine]

It just wouldn't be used.

This is what goldenboy is complaining about, and I really don't see much reason to take away that flexibility, unless it's to prevent cheating. Any user with enough knowledge of the console can already do a ton of other things to break the intended visual of the map anyway.

A callback function in r_wateralpha could solve this, by telling the engine to use its value instead of the map-defined value, so it would be just a matter of the player reissuing r_wateralpha with its current value to override the map-defined value.

Code: Select all

if (single player or coop) {
  let the players change any map defaults;
} else {
  if (server defines the equivalent cvar) {
    use cvar values instead the map ones or clients cvars;
  } else {
    do not permit players change map defaults that can affect gameplay balance, but allow change things like skyboxes on/off;
  }
}


Ultimately, the player (or, at the least, the server admin) must always have some form of control over gameplay relevant factors.

The rationale above can be applied not only for wateralpha, but fog, fullbrights, etc.

[ceriux]

why not have it set through the entitie like half-life does? set it up in the engine, then through qc add a variable which can be set between a different number 1- 255? so the mappers can pick how dense they want their liquid?

[Baker]

My example wasn't intended as a way to limit user flexibility, but as a way to ensure the proper presentation of a map the way the author of the map designed it, while respecting r_wateralpha's value when those worldspawn keys aren't present.

Such keys could indicate whether or not slime was transparent etc.

It isn't taking away user flexibility, they could use developer 1 to play their way, but the developer 0 default is to ensure they couldn't accidentally mess it up.

[scar3crow]

Or r_wateralpha 2 to defer to map settings.

[frag.machine]

@scar3crow: r_wateralpha 2 would be an evil hack IMHO.

@Baker: this is more a philosophical discussion than anything. As a (mediocre) mapper I understand when one wants to make people play, see and feel their work as they envisioned (and frequently, worked hard to reach the desired result). But ultimately, everything we do - mappers, modders, engine coders - should always respect our "customers" (read: the tiny remaining Quake player community) desires. Without them, all our work is pointless. That's why any worldspawn info setting water alpha and such should be only recommended defaults - if the player explicitly uses "r_wateralpha 0.3", then this value must be used instead my "wateralpha 0.3166666666" optimal default.

Yeah, I know that by now many people in the Quake mapping community wants to know where I live so they can hunt me with torchs and pitchforks, but this is just my $0.02 on the discussion.

[Baker]

@scar3crow: r_wateralpha 2 would be an evil hack IMHO.

@Baker: this is more a philosophical discussion than anything. As a (mediocre) mapper I understand when one wants to make people play, see and feel their work as they envisioned (and frequently, worked hard to reach the desired result). But ultimately, everything we do - mappers, modders, engine coders - should always respect our "customers" (read: the tiny remaining Quake player community) desires. Without them, all our work is pointless. That's why any worldspawn info setting water alpha and such should be only recommended defaults - if the player explicitly uses "r_wateralpha 0.3", then this value must be used instead my "wateralpha 0.3166666666" optimal default.

Yeah, I know that by now many people in the Quake mapping community wants to know where I live so they can hunt me with torchs and pitchforks, but this is just my $0.02 on the discussion.

I think an engine + mapping standard that automatically set the water alpha accordingly as a welcome feature as a player.

Some single player releases have an autoexec.cfg in the gamedir or pak to select the setting that was meant to be used.

And probably some single player release just happen to be water vised, but the author didn't intend it.

I think an engine should load a map and mod as the author intended it by default, the way a skybox is automatically loaded by most skybox supporting engines and the way fog is automatically set.

But then again, I understand their are alterative views.

[scar3crow]

How is setting a value to an already well known cvar that respects the map or mods decision an evil hack? Seems akin to letting people leave via the front door as well, instead of proceeding through the house to the back door, and then walking around to the front. This would keep the user in the same region of comfort for deciding how their system displays, while making it convenient to defer to the author of the loaded content.

[Baker]

After thinking about things a bit, your r_wateralpha 2 is a fine idea.

Here is why it is "ok". But first I need to explain why I wasn't sure it was "ok" so something that sounds obvious, I had a complicated non-obvious concern .... so I'll explain that ...

[short version: I was worried about the changing of a default value that has historically existed in Quake. Long version of why ...]

A good engine honors the defaults specified in quake.rc on load ... now there are not many engines that actually do this. DarkPlaces does. FitzQuake either mostly does or completely does (I can't recall why at the moment why I'm not just saying completely does.) ProQuake long ago, I changed it to be like DarkPlaces and honor default values that should be set when quake.rc is executed (a couple insignificant exceptions exist).

Failure to do this causes unpredictable results when doing Options -> Reset to defaults. This is not user friendly. And then the user can be stuck with super-weird settings and the only way to fix is to actually delete his/her config.cfg.

Engine default values have to be secondary to whatever gets run in quake.rc.

NOW, r_wateralpha isn't going to be changed by anything in quake.rc for Quake. As a GLQUAKE feature, it was added AFTER the fact and isn't set in Quake.

Likewise, for a proper mod they would have put the default settings in quake.rc and you just can't worry about improper mods (much) if the feature isn't going to lethal and this wouldn't.

So an engine default of r_wateralpha 2 isn't going to interfere with anything ever.

I know this was a long explanation, but I was thinking of both backwards and forwards compatibility.

The r_wateralpha 2 thing is a very good idea. Would not interfere with anything.