The solution I have in mind is upgrading to quake 2's qbsp tool (backporting it to support Q1)

That's sounds awesome. Beyond better compile times, would a Q2-based compile set the stage for any other new features that could be introduced down the line? (in the vein of things like func_detail, which we have now of course) 

I feel like most of the potential features are already implemented (not sure if you saw the detail variants I added last summer: link), so a migration to q2 qbsp code would be mostly speed / stability. I'd want to port over all of those current features though. 

(not sure if you saw the detail variants I added last summer: link)

Yes, I discovered those a few days ago - they sound awesome :) 

Which topic should I use for help with key bindings? 

I'm trying to create a toggle for r_wateralpha "1" and r_wateralpha "0.5" 

you'd have to bind each to a separate key. binding a toggle looks like this, btw: bind x "toggle r_showtris" 

You could use the bind-that-rebinds-itself sort of technique. E.g.

alias w1 "r_wateralpha 1; bind k w05"
alias w05 "r_wateralpha 0.5; bind k w1"
r_wateralpha 0.5
bind k w1 

that's a useful technique, haven't seen that before. 

bind k "cycle r_wateralpha 1, 0.5" 

Thanks. Also when using r_wateralpha "0.5", assuming the map supports transparent water, should r_novis be set to 1 or 0? I'm using QuakeSpasm. 

0 

"r_novis" should pretty much always be "0" (i.e. off) -- which is the default anyway, so basically, don't tinker with it. This is why:

What r_novis does, is to tell the engine to ignore vis data, which specify which parts of the map are visible to the player at any given time.

Vis (short for visibility) saves the engine from having to draw the entire map at all times (which is a waste of resources and, especially on large maps and slower computers, can slow the game down). If a map has not been designed and compiled with transparent water in mind, then the water blocks visibility, and whatever is below or above the water (from the player's perspective) is not drawn. Simply setting r_wateralpha to a value lower than 1 will not magically make the water transparent -- in Quakespasm you'll get some ugly visual artifacts.

By switching r_novis to "1" and then lowering the wateralpha, you can force the engine to display the water as transparent -- but at the cost of having the engine ignore vis data and drawing the entire map at all times.

Perhaps more importantly, maps that do not support transparent water have often been deliberately designed as such, so if you "trick" the engine into displaying transparent water, you might also end up breaking the gameplay and/or aesthetics of the map you're playing.

So in summary: only ever adjust wateralpha and leave novis alone. If the map has been designed for transparent water, it will work; otherwise stick with opaque water (i.e. wateralpha 1). 

bind k "cycle r_wateralpha 1, 0.5"

Did cycle exist in vanilla quake? o_O 

Got it. The reason I asked is because one of mfx's maps had to be run with r_novis "1" to make some funky transparent glass in the map show up properly, but that's a special case I guess. Thanks mates. 

Don't think cycle was in the original engines nope. Looks like QS and Mark V support it though. 

 

you could place all the stuff in a file too and use the exec command too 

The "zoom" command in vanilla Quake is an alias. It always existed in Quake.

The zoom command also auto-rebinds itself, exactly as described in #29918. 

What's the best engine to play online today? Do they support more than 32 players? 

https://www.gamasutra.com/blogs/DavidLightbown/20180109/309414/Classic_Tools_Retrospective_Tim_Sweeney_on_the_first_version_of_the_Unreal_Editor.php

Some interesting history and insights about level design tools in this article. 

If you're going to play on quakeworld servers then FTEQW is clearly the better choice. Don't get me wrong, its nice that DP tries, its just that it doesn't really have much awareness of actual QW trends.
Things are a little more even when it comes to NQ servers, and given my bias I'm not even going to name my preference there...
but yeah, depends on personal preference, the server in question, and your choice of engine-specific content replacement stuff.

vanilla nq supports 16 players max.
vanilla qw supports 32 player slots max.
both fte and dp servers can be reconfigured for 255 players max, but don't expect other clients to be happy with it.
for fte you need to set both sv_playerslots and maxclients to 255 (two cvars because maxspectators also exists and shares slots).
although the chances of getting even 16 players is somewhat unlikely nowadays. 

Is there a way to combine players vs. environment arena combat in FPSs with co-op play that doesn't suck? Let me explain my question.

By an arena I mean a combat encounter against mobs that happens in a limited area. Door close or other barriers appear to prevent the player from leaving until he has cleared the area. I'm sure you could name various newer FPS games that do this as their main gameplay mechanic, and it's also a common design pattern in Quake SP maps.

This sucks in co-op play if one player goes into an arena and locks it up. The others have to wait until the combat is over to join this one guy, unless there is a way for them to enter during the fight. Being able to teleport in is one way to solve this, but it feels a bit forced and teleporting does not fit with all kinds of games & worlds.

I'd want the players to have the freedom to explore the map while others are possibly fighting and join these fights at any time, or start fights of their own. I wouldn't mind some requirements towards having all the co-op players present for big final boss fights to start, but this should be only done for the main combats that are tuned for the number of players taking part. Freedom to explore should come first, but on the other hand well-crafted arena encounters are really fun.

What ways can you think of combining co-op play with PVE and arena style combat? Are there any games that actually do this in an interesting and natural way? 

If the "lock-in" is due to the player dropping down from a higher area, then that would work. Or maybe have a sort of double-door "airlock" setup that allows only one-way access to an area. 

This is called a "push" game mechanic. This could be any number of things. In SP, doors that slam behind you are very common. For coop, a height push as Kinn mentioned is very useful, natural, and common and works in any game.

You could do other methods, for instance to have player freedom, such as gravity/wind/catpult lifts or devices to take you up to a lifted fight area.

You could also still use a door that slams behind and then open up another pathway to a height push for any straggling players. 

Oneway turnstiles work too. HL2 uses this at the very beginning level in the trainstation.