Fitzquake 0.85 introduced an ambiguous feature that allows wateralpha to affect water-textured brush entities. Illusionaries too, I think. 

If there's an option to define different transparency effects for water, teleporters and lava in some engines, why not in Quakespasm too ?

Water should be transparent (at least partially), but lava SHOULD stay opaque. Also, the teleport field should be opaque.

I'm even getting some weird rendering artifacts/weirdness in QS when I look at some lava fields. It's so ugly that I think to make all water/lava opaque, because of this.

What is the command to define opaque water/lava/teleporters in QS, for ALL maps/mods ? 

Fitzquake 0.85 introduced an ambiguous feature that allows wateralpha to affect water-textured brush entities. Illusionaries too, I think.

Hm, didn't realize that, but I can confirm it works. However, if you set an explicit "alpha" key on the entity, that value is used regardless of r_wateralpha.

@Barnak, just set "r_wateralpha 1" if you want to make everything opaque.

I wouldn't be opposed to adding the r_slimealpha, r_lavaalpha, r_telealpha keys. It does have a small potential for visually breaking existing maps if the author includes an r_wateralpha setting in the map (in a config, or trigger_command, etc.) and expects it to set the alpha of slime, lava, and teleporters, not just water. Not sure if that is a realistic problem or not. 

What is the command to define opaque water/lava/teleporters in QS, for ALL maps/mods ?
because that is the original command from glquake. the engine doesn't really make much distinction between liquids (although it is aware of it), it's only in the qc that things like damage and slower movement speed are taken care of. 

May I suggest to add the options to add r_slimealpha, r_lavaalpha, r_telealpha to QS ?

I think this would improve a lot the rendering in Quake. Water as semi-transparent liquid, lava and teleporters fully opaque.

What is slimealpha ?

I currently use r_wateralpha 0.8, as a compromise for lava/teleporters and water. 

I wouldn't be opposed to adding the r_slimealpha, r_lavaalpha, r_telealpha keys. It does have a small potential for visually breaking existing maps if the author includes an r_wateralpha setting in the map (in a config, or trigger_command, etc.) and expects it to set the alpha of slime, lava, and teleporters, not just water. Not sure if that is a realistic problem or not.

The way to make this backwards compatible is to say that when r_slimealpha etc are set to 0, slime transparency defaults to the value of r_wateralpha. Essentially these cvars become overrides for r_wateralpha, and ideally they'd work selectively, so if you're happy for slime to be as transparent as water you only need to set r_wateralpha and r_lavaalpha.

I'd also recommend that whoever implements this also adds support for worldspawn wateralpha/slimealpha/etc keys in the way fog works now, so that the new de-facto standard that is created incorporates two good ideas at once. 

r_skyfog too? 

Doesn't FQmk5 have a cvar for an ignore-wateralpha list? You have to put texture names in it manually, which is dumbish, but there it is.

and please, _worldspawn keys for this shit. I miss when the primo engine port was being developed by an actual mapper, who gave us control over what our maps looked like and left everything else alone, instead of cvars for everybody to twiddle, so debugging new content became a hopeless crapshoot. 

Currently, the gibbs and dead bodies are smoothly fading away or slowly moving under the ground to reduce the impact on frame rate and memory (I guess). On modern computers, I don't think this is a concern anymore.

So is there a way to tell Quake to leave all the gibbs and body parts there ? If not, it would be cool to have a new option about this.

I love to see the mess I do on a map, especially at the end.

What do you think ? 

Is there a frame rate counter in Quake1 (I suspect there isn't) ?
Probably no so usefull (the frame rate appears to be very high on my old 2009 Mac mini).

So a few options I would like to see in QS, that could improve the game or the user interface :

1. FSAA (antialiasing). I think ericw once add a good piece of code to add this (I have an old experimental version of Quakespasm OS X with FSAA, from him).

2. Gibbs and dead bodies staying on the floor.

3. Independant transparency control of water, lava, teleporters.

4. Frame rate counter.

5. A better looking icon on OS X ? I think it's currently too thin, especially on the OS X Dock.

6. An option to make the Shamblers serve beer, instead of electrical discharges. 

Preach, thanks, that sounds good.�I tried implementing the cvars and worldspawn keys, and seems to work.

I guess I should use underscores for the worldspawn keys, like "_wateralpha"? "fog" and "sky" don't, but they've been around forever.

mfx, supporting "_skyfog" as a worldspawn key sounds good, and it's trivial to do.

The straightforward way of implementing all of these worldspawn keys is to just set the cvar whenever the map is loaded (whether from playing a demo, dying, or starting it normally). Setting the corresponding cvar will mean they persist for the rest of the quake session, unlike "sky" and "fog" which are cleared whenever a map is loaded. Does that sound like a problem?

The only real workaround is e.g. turning r_skyfog into a command like "fog", where the value gets reset to its default (0.5 for r_skyfog) whenever a map loads. I wouldn't want to change r_wateralpha like this since it's been a cvar since glquake.

Also, quakespasm has archived r_wateralpha in config.cfg since 2011 or so. I'm not really a fan of this, because it means maps that use trigger_command to set r_wateralpha (or the yet-to-be-added _wateralpha key) cause the last value used to stick across launches of quake. r_skyfog is not archived though, and the r_slime/tele/lavaalpha cvars wouldn't be archived either. I would be tempted to stop archiving r_wateralpha in config.cfg, not sure how the other QS devs feel though.

Lunaran, yeah, hopefully adding support for these worldspawn keys is a step in the right direction.

Barnak, re: gib removal, it's probably the Quoth mod doing that. IIRC, it's not configurable by the player. You can get the fps counter with "scr_showfps 1". FSAA is on my todo list. 

could there be a _cvars key that simply accepts a semicolon separated list (that does not get archived)? 

No Texan Style approach to feature addition. 

Gibs always disappear after 10-20 seconds. It's standard Quake behavior set in QC. The corpse removal in this case is most likely from Quoth, indeed. I hate how the mod defaults to this instead of being opt-in. Neither should be overriden by the engine. 

So there's no way to prevent the gibs and dead bodies to disappear and make them stay on the ground ? (so we can eat'em later) 

What's in that quakespasm.pak file ? What are the differences if I remove it ?

The readme doesn't say much about this :

>Quakespasm content customization moved from engine-embedded
> into a new optional quakespasm.pak file. 

Maybe another feature request : a command to list all music files.

I can't remember all the music file names I placed into the music directory.

Currently, we can browse the map directory with TAB. Maybe something similar could be usefull for music ? Or at least a music list command ? 

hopefully adding support for these worldspawn keys is a step in the right direction.

Agreed, and thank you! Still, if only one engine out of a half dozen implements it, or if they all implement it different ways, it's still effectively unusable.

I really don't want to just say "this mod requires this engine" because everyone has their own choice based on personal preference, or based on what engine they can even run (because they're on a Mac or whatever), so that isn't an option either. That limits level designers and modders to the subset of features that are global enough to be effectively standard, which at this point is a _fog key and an .alpha key and not much else.

I explored using stuffcmds to switch the skybox during gameplay, so the player could go underground and emerge somewhere with a different backdrop, or to simulate lightning flashing during a storm. Research immediately revealed that not all popular engines have a console command to change the skybox, and the ones that do don't use the same command. The idea survived about five minutes.

Recent QS changes have even made me back off on stuff that would have been possible in stock Quake. I'm now greatly constrained in how I print text to the screen and how much (any more than 384 characters and apparently I'm creating a "rude mod," to quote the QS readme), and I've given up on having a custom demo or set of demos to play at the main menu because someone contributing to QS decided that the startdemos command in quake.rc should just be ignored, for no other reason than he prefers it that way. These are rather disheartening precedents.

So, yeah, _skyfog and _whateveralpha keyvalues would be nice! but unless we can convince Baker, LordHavoc, et al to implement the same things the same way, from the perspective of a mapper there's not much point. :( 

I have hundreds of nice custom maps inside my id1/maps folder. Very often, I simply don't know which one to play, and would like to be surprised.

So a "randommap" command could load some randomly selected map from the whole list. The player would then be surprised each time he calls "randommap" from the console. A keyboard shortcut could even be assigned to the command.

Wouldn't that be great ?

I'm not a programmer, so I don't know if this could be done for QS.

What do you think, Quake Gods ? 

I can't really see how people would implement _wateralpha differently, it's a much safer bet than fog ever was for being consistent. It's also one of those gracefully degrading features like skyboxes - your map doesn't stop being playable if the water is off. That means there's a nice path to adoption, you get a "recommended engine" not a "required engine".

Suggesting people should bundle it with the newer features is a bit of a risk, but hopefully the one will carry the other... 

...like a base that belongs to us. 

recommend "wateralpha" instead of "_wateralpha" since keys with an underscore are intended for the compile tools, not the engine (engine is supposed to ignore them) 

thanks for the pointer metl.

Thinking a bit more on it, these worldspawn keys should really behave the same as the existing "fog" and "sky" ones, not persisting beyond the map they're used in.

so maybe something like this:

Worldspawn keys:
wateralpha
slimealpha, etc.
skyfog

If set, the provided value is used for the duration of the map instead of the r_ cvar. Does not change the values of the corresponding r_ cvars.

Cvars:
r_wateralpha
r_slimealpha, etc.
r_skyfog

Gets/sets the fallback values used in maps that don't specify a value in worldspawn (i.e. unchanged from current behaviour). If the current map is overriding "wateralpha" with a worldspawn key, and you query "r_wateralpha" from the console, you get the fallback value, not the current map's worldspawn value.


The only missing use case here is: you've overridden some of these values in worldspawn, are playing the map, and want to check / tweak the values in the console. The cvars won't work because they get/set the fallback value that would be used if you weren't using the worldspawn key.

Idea: a set of commands:
wateralpha
slimealpha, etc.
skyfog

These print the current settings (whether coming from the cvars or worldspawn keys), and let you change the settings for the duration of the current map. They never change the corresponding cvars. i.e. same principle as the "sky" and "fog" commands. 

I can't really see how people would implement _wateralpha differently

Heh.

FQmkV exempts liquids beginning with *tele from wateralpha, and provides the unique keyword "r_texprefix_tele" to override or disable it.

There's the inconsistency brought up for Barnak earlier, where some engines will apply wateralpha to bmodels with liquid textures on them and some won't, making it harder to use the func_illusionary trick to get around undesirable wateralpha settings in the first place.

To make sure that engines which "fixed" the behavior still give you the desired original-quake behavior, you have to forcibly set alpha 1 on those func_illusionaries, which causes back to front sorting issues in all engines. (This is visible on the lava in my jam2 map.)

If there are cvars I can poke from progs.dat, do I have to worry about them being archived in the cfg, or not? Does the player's cvar setting override the worldspawn key or vice versa? How are the infamous not-water liquids found and handled?

If you don't see how the quake community can implement something inconsistently, you're underestimating their ingenuity. :) 

How about a fix for flickering entity as well?

Its where large bmodels end up spread across multiple leafs and go invisible depending on where the player is stood.

The bmodel doesn't even have to be that big - just an oddly shaped leaf or bmodel can do it.