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. 

add a player counter trigger that activates only once it has been touched by every player. would need new qc though.

possibly fake it with some elaborate counter with timeout, and not enough players are standing on (separate) buttons then it doesn't continue.
sucks if there's only one player though.

one other alternative would be to flood the earlier parts of the map with lava or something. you'd need some teleporter with careful killtarget use to prevent respawning players from dying instantly though.

alternatively place a massive triggered teleporter over the earlier parts of the map and trigger it to instantly teleport lingering players into the arena. would need a teleporter at the start...

or just use one way teleporters so that you can always get in. You could put them behind a door that is toggled when the area starts, and again when it is ended (if desired). 

add a player counter trigger that activates only once it has been touched by every player. would need new qc though.

Easier one would be to put the trigger that targets the counter on a drop down or on a wind tunnel. Would need for the area to be wide enough so only one player passes at the same time and fiddle with the wait key till even if the two players go one right after the other it will trigger for both. 

https://twitter.com/ioquake3/status/952351931535519745 

How very interesting, I'm sure you could talk for hours about GPL given the go. 

I'm gonna share a simple trigger setup you can use to only trigger something once all the players have progressed beyond a "gate" (and then ruin it a bit at the end). We need to build something I call the "dead man's switch".

The idea of "dead man's switch" is that we build a system of entities with an input and an output, where the output fires if we haven't had an input in the past 0.5 seconds. I'm gonna prove it's theoretically possible using spike-shooters and doors - if I put more effort in I expect there's a cleaner way to build it, but that will have to wait until the blog post in a few years time.

Build a spikeshooter, firing continuously at the output trigger: a shootable trigger_once. Now position a door such that the door blocks the spikes when open, but allows them to pass when the door is closed. Make this door return rapidly to closed after fully opening.

Now add the input: a rapid firing trigger_multiple in the actual level which targets the door. So long as at least one player stands in this trigger, the door is retriggered repeatedly and kept in the open position. As soon as this stops happening, the door closes, a spike passes through, and the output trigger fires. The dead man's switch is complete!

How do we use the dead man's switch to create a gate that all the players must pass beyond before the level progresses? By defining the gate in negative terms. We cover all the portions of the level before the gate with trigger_multiple inputs to the dead man's switch. As long as at least one player remains in the pre-gate parts of the level, the switch cannot trigger. As soon as the last player leaves the triggers, the dead man's switch activates.

Now I've shared how to pull the basic version off, here's the first problem: the dead man's switch will trigger if there are no players in the pre-gate region, and one way to achieve that is to have zero living players anywhere in the server! This could happen if all the players die at once (especially easy if there's only one in the server) or if some network problem causes all clients to drop from the server (the "zero players connected" state at the root of many rare co-op bugs).

There's a reasonable workaround to this though: require a positive input to the spikeshooter, using a trigger_multiple from the region after the gate. Now we've changed the conditions to "no players before the gate, 1 or more after the gate".

The last thing to worry about is what happens if players die after you've fired the gate event. They will presumably respawn in the pre-gate area of the map, so you have to remember that you can't guarantee that players will remain trapped on the far side of the gate. This is especially important if you're locking an arena with a door - how will dead players rejoin the map? If your answer is that they can't, are you happy that the map will be impossible to complete if everyone dies? Or get disconnected by a network glitch? Don't worry unduly, but do try to bear these in mind. Good luck! 

Simplest solution to the problem at the end that I can imagine is to have a second, drop-down pathway that opens when the gate closes. Small, short & simple but enough to let players rejoin the ongoing fight. 

3 cheers for Khreathor and all the modeling help he gives me. 

I am seeing a lot of new users here. Both posting maps and questions. New blood is always good in the Quake scene. Glad to have you all. Stay... please!!! 

I now have beef with dumptruck for interrupting my round of cheers. 

EOM