I looked through some of the Quakespasm changes and have 2 thoughts:

1) MAX_MSGLEN has been increased from 32000 to 64000. FitzQuake protocol 666 has a MAX_MSGLEN of 32768.

As I understand it, due to this change you aren't actually using protocol 666 any more, but have modified it and, as I understand it, it is now possible to record demos or host a server using protocol "666" that in isn't actually compatible with the standard.

[I could be wrong, but I don't think I am]

2) sv_aim 1 as a default makes playing with the keyboard really hard. Probably the reason id software didn't default it to 1. 

1) You're right, you can record demos that will be marked as protocol 666 but an engine with MAX_MSGLEN set to 32768 like Fitz 0.85 won't be able to play (but this would only happen in cases where Fitz wouldn't be able to load or run the map anyway.)

I can see the argument that MAX_MSGLEN should be considered as part of the protocol, but there's good precedent for bumping this limit without changing protocol numbers; DirectQ, Darkplaces, and RMQEngine all use 65536 regardless of protocol, and I think Fitz allows 32768 bytes messages even for protocol 15 (same kind of limit bump).

The background behind this is I wanted to support a map ijed is working on (bsp2); the snapshot I have has 2855 edicts at startup, which gives a 43392 bytes signon buffer.


2) That's also true. But I assume nearly everyone plays PC FPS's with mouselook, so it's a good default? QuakeSpasm (in the upcoming release) defaults to +mlook turned on, as long as you use the quakespasm.pak, which is why I wanted autoaim to default to off.

I figured anyone who wants to do a "1996 night" and play quake with keyboard aiming can look up the original default sv_aim 0.93 and enter that in the console.

An option would be something automatic where turning mlook on or off automatically updates sv_aim to 0.93 or 1; I think negke suggested this, and that could be a good option too. 

I feel like those sorts of limits are a grey area where they are not directly part of the protocol, but obviously affect which clients can handle what the server is sending them. 

WTF !?

Arcanum isn't working anymore. I'm getting an error message in the console after entering the last gate of the second map. Unable to play the third map. What gives ?

Anyone getting the same ? 

at least I can noclip to the exit trigger in arcanum2, and arcanum3 loads.

What's the error message? Are you using the build szo posted in #917? Can you try it in QS 0.85.9? Does it fail if you do "map arcanum3" in the console, or is arcanum2 the cause? 

check if using a large heapsize solves it like "-heapsize 256000" 

Ericw, I'm using -heapsize 480000. AFAIK, it should be enough.

The problem happens with all my versions of QS, and also when I try to load arcanum3 directly from the console. Here's the error message I got :

> can't find function monster_gremlin
> Host_error : ed_parseEdict : parse error

Here are the commands I'm using when I start QS :

-hipnotic -quoth -game arcstart +skill 3 +map arcanum3 -heapsize 480000 -zone 2048 -sndspeed 44100 

delete the hipnotic and quoth stuff. 

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.