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. 

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)

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 

Coders: the bug in #965 is fixed by increasing MAX_ENT_LEAFS in progs.h 

hexen2 ignores r_wateralpha on lava.
but it uses r_wateralpha as a general transparency value on other things like transparent projectiles etc..

when you have refraction/defraction effects, wateralpha is a nasty kludge that is often best ignored completely.

leading underscore means that mods can't see it, but that other engines won't spam like crazy leading you to think the map is buggy.
no underscore is an actual entity field. probably not desirable but at least qc can see it. and then someone thinks that changing it in code should work too. and then we get people complaining that it doesn't work and all the programmers bitch about it.
really, engines should probably support both, and mappers should use an underscore.

tweaking cvars randomly from gamecode for anything except menus is evil, and WILL glitch one day, one time... AND THEN THE USERS COMPUTER WILL BLOW UP AND THEY'LL SUE YOU! so don't poke cvars, mmkay?

I've taken to making empty cvars mean 'default setting'. if r_lavaalpha is empty, FTE uses r_wateralpha instead. I'd say if r_wateralpha is empty, use the map's _wateralpha key instead, or 1 if not present. or something. Meh, I dunno. Lots of ways to try to get it to be automatic and most of them will conflict with what you think should be the standard. And all of them useful in some way where the others are not.
All I can say is that in an engine with shaders, you can ignore the cvars completely and live in bliss because of it. Cvars have their place, but generally its better to just make the content define how it looks instead of the user tweaking random things because the map's readme says to do so, and breaking other things in the process. Yay shaders. And needing extensions (over q3 compat) to actually get the water looking reasonable. Bah. There's a flaw to everything.

The great thing about standards is that there are so many to choose from.

K, I'll shut up now.

maybe. 

Fitz 0.85 was a standard. QS as a fork should adhere to it. 

if r_lavaalpha is empty, FTE uses r_wateralpha instead.
This sounds like the best thing to do

I'd say if r_wateralpha is empty, use the map's _wateralpha key instead, or 1 if not present. or something.
This sounds okay too, so long as you don't archive r_wateralpha. I suppose there are three ways to treat the interaction between prior values of r_wateralpha and the _wateralpha key

1. Any prior setting of r_wateralpha wins - bad if you archive or if people set r_wateralpha in autoexec.cfg, but ok for people running the map fresh otherwise.

2. _wateralpha is a temporary override of r_wateralpha, effective just for the duration of that map. Removes the ability for players to adjust the wateralpha once they load the map - which might be good or bad I guess

3. _wateralpha effectively sets r_wateralpha, so the value persists. By far the easiest way to do it, and consistent with how QC mod-based wateralpha works, but when compared to the alternatives seems quite disruptive...