Recently another discussion started in the Quakespasm thread on func_, a few people asked for r_slimealpha/r_lavaalpha/r_telealpha cvars, and Preach and Lunaran chimed in requesting worldspawn keys: http://celephais.net/board/view_thread. ... &start=937
I think metl posted a really nice concept of how this could work here: http://celephais.net/board/view_thread. ... &start=971 . I implemented a prototype of this in Quakespasm (code and exe at the bottom), and tried to expand this into a proposal which I'm posting here.
So, the motivation is, the current possibilities for q1 mappers to control water alpha are pretty bad:
- put an “r_wateralpha” setting in quake.rc bundled with your map directory (e.g. the map jams do this)
- pros: pretty reliable
- cons: too global - gives all maps in a mod get the same setting. treatment of lava/teleporter/slime depends on engine
- use trigger_command to change r_wateralpha:
- pros: can set different wateralpha for different areas
- cons: requires custom qc, not saved in savegames, may be saved to config.cfg, will persist to next map, no control over how it applies to lava/teleporter/slime, generally the most dirty method possible
- use a func_illusionary on the water surface with an explicit "alpha" key on the entity. Haven't used this method, but it sounds cumbersome and I think the water transparency from the inside looking out will depend on r_wateralpha, not the func_illusionary alpha
Here are the worldspawn keys i’m proposing:
_wateralpha
- When a map is loaded, if the “_wateralpha” key is set in worldspawn, the given value should be used by the renderer instead of r_wateralpha for the duration of the map.
- Loading a map with this key shouldn’t have any other side effects; the value of the r_wateralpha cvar shouldn’t be modified*, and the value given in the worldspawn key shouldn’t persist in any way when you change to another map or disconnect EDIT: (*- or if the implementation modifies r_wateralpha when parsing the _wateralpha key, r_wateralpha should be reset to its original value when leaving the map, unless the player explicitly changes r_wateralpha)
- If the player (or qc code) changes the “r_wateralpha” cvar while the map is running, the engine may switch to using that value until the map is reloaded, or may continue using the value from worldspawn. (EDIT: Made optional at request of LordHavoc)
- EDIT: just to be clear, the value is a float from 0 (fully transparent) to 1 (fully opaque).
-
Follow the same rules as “_wateralpha”, but these worldspawn keys apply to a subset of water textures:
_slimealpha applies to textures beginning with “*slime”
_lavaalpha applies to textures beginning with “*lava”
_telealpha applies to textures beginning with “*tele”
(same naming patterns in RMQEngine). - It should be possible to implement this behaviour regardless of whether an engine already has special treatment for slime/lava/tele textures or not (RMQEngine, DirectQ have r_slimealpha/lavaalpha/telealpha cvars, Fitzquake Mark V, automatically makes “*tele” textures opaque, I think). If a specific _slimealpha/_lavaalpha/_telealpha worldspawn key isn’t provided, the engine would just do whatever its default behaviour was for those textures.
- r_skyfog is a fitzquake cvar that controls the fog opacity against the sky. 0 means there is no fog drawn over the sky/skybox, 1 means the sky is drawn as the fog color, fully opaque.
- it's not directly related to the water alpha settings, but the spirit is the same: in a more sophisticated map format, this would be a property of the sky texture or map entity. In Fitz 0.85, it's a cvar, which is better than nothing, but the mapper can't really make use of it without resorting to r_wateralpha-like hacks.
- including it in this proposal because mfx requested it, and it was easy to implement using the same technique as _wateralpha. It's only relevant for fitz-derived engines or engines that implement sky fog.
That's all, comments / feedback would be appreciated.
Rationale for underscores in the keys: Preach says: “The intent here was to make it so that it doesn't throw up errors in engines that don't support the key, since they're already trained to ignore it : - ). I know the original intent was for tools, but it can serve a second purpose for things the engine understands but is hiding from the QC and third for hiding QC fields from those pesky mappers ” (EDIT: Engines should accept _wateralpha or wateralpha, same for the other keys)
--
ADDED: Test maps, with readme and screenshots:
http://www.quaketastic.com/files/misc/w ... stmaps.zip
UPDATED: Diff for my initial stab at implementing this:
https://github.com/ericwa/Quakespasm/co ... a?expand=1
UPDATED: Quakespasm win32 binary with the patch:
http://quakespasm.ericwa.com/job/quakes ... c015d1.zip
There are a couple known bugs with my implementation:
- FIXED specifying 0 for the _lavaalpha/_telealpha/_slimealpha worldspawn keys doesn't actually cause the alpha to be set to 0 for those textures, but means "fall back to the wateralpha value".
- FIXED if you, as a player, want to override the _wateralpha worldspawn key, you have to set the r_wateralpha cvar to something other than it's current value. e.g. worldspawn _wateralpha is 0.5, r_wateralpha is 1. If you want to override the alpha to be 1, you have to do "r_wateralpha 0.9" then "r_wateralpha 1"