Hmm,

apparently, the commands "-hipnotic -quoth" are the culprits. Why ?

I now can start arcanum3 if I dont put -hipnotic -quoth at start. 

I thought that -hipnotic -quoth was usefull. I don't even remember what it's doing. 

they load different game directories and progs.
Which interferes very heavily. 

You only want to use -hipnotic, -quoth if the mod readme specifically requires them. Glad it was an easy fix. 

what is -hipnotic ?

And the last map of Arcanum sucks : it has lots of holes and rendering problems on some walls. 

hipnotic is the first missions pack (Scourge or Armagon). 

Is there a way to make water transparent, but lava opaque ?

What are the commands for this ?

Real lava isn't trasparent. It doesn't even make any sense ! 

We did this in RMQ/e with different keys for telealpha, slimealpha, lavaalpha and wateralpha.

But it wasn't adopted by other engines. 

Not without map hackery. you could make a thin illusionary brush over lava and give it an alpha key of 1.0, but I assume your question is as a player. RMQEngine has separate alpha values for each liquid. 

you could make a thin illusionary brush over lava and give it an alpha key of 1.0,

Actually you don't need the alpha key to get a non-transparent brush. Also, you can put the illusionary a few units below the actual lava and get a dual layer effect on the ripple. 

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)