and since no one directly commented on this "I don't understand what clients and servers have to do with single player Quake."

Quake single player is still played on a "server". My guess is this is because of coop. 

Spike, thank you for once again answering very extensively. I'm struggling to understand all of what you wrote, because it introduces several terms and concepts I'm not familiar with at all, but I've read it a few times now after reading (and trying to understand) Wikipedia entries on the respective terms and concepts, and it's slowly starting to make a little bit of sense. Unfortunately I have no background in programming or coding, which would make things easier to follow.

ＰＲＩＴＣＨＡＲＤ, thanks, that helped a lot.

mukor, thanks, I kind of figured that it's something like that, but it still doesn't really make sense to me. In what sense is the "server" a server, and what is the "client", when you're playing on your own and unconnected to any network?

server physics is stuff moving around serverside. all the logic in nq is serverside, so there's none of the 1/8th rounding stuff going on.
So where is the rounding happening, if everything is serverside? Sorry, I'm not sure if my questions make sense. I'm really having difficulty understanding all of this. 

There are certain parts of Quake that are managed by the "server", and so even when you're playing offline what is happening is that the game launches a server inside of itself to handle all of those components, and then the client "joins" its own server.

I'm not sure exactly what parts of Quake are and aren't server side, but movement definitely relies on the server, for instance. The client is basically in charge of rendering and not much else, actually.

I think the game is built in this way to reduce workload for the developers, as it saves having to duplicate work that was already done. It's harmless to run a server inside of the client - it even comes with benefits like "listen servers", where the client's internal server is opened up to the internet and other players can join without you needing to run a separate application.

I may have rambled a bit this time but hopefully I have rambled correctly... 

Server runs the main game.
Clients connect.
All games are ran with a "server" due to design for coop.
Server handles stuff like physics, positions, velocities, monster kills, etc.
Client handles rendering of monsters, particle effects, HUD, etc. Anything that shouldn't be sent over a network (mostly). 

Yeah, and most (probably all?) networked co-op games are built in a similar way. Like you say, there's no harm in building a game this way even if its singleplayer sessions use the same framework since latency is non-existent on a locally hosted game.

There's probably a nice flowchart out there somewhere from a Carmack or Abrash talk that breaks down exactly which parts are on the server and which are on the client in Quake engine games 

Thanks for the tip! I think I've found it.
Here is the text that goes with it:
Quake’s 3-D Engine: The Big Picture by Michael Abrash.

Going to have to read that very carefully; hopefully it'll clear several things up for me.

Thanks for your responses, ＰＲＩＴＣＨＡＲＤ, Qmaster and Blitz. 

New Monitor, New Colors

Posted by SavageX [92.201.47.51] on 2017/11/30 19:49:12

Hi there,

I got a new monitor - nothing fancy, just a more "professional" (nicely adjustable pivot/height/angle) 24" Dell office thingie with an IPS panel, switching from an old 19" monitor with a TN-panel.

The colors happen to be much more vibrant/deep (not surprising - it's an IPS panel) - however, Quake looks much darker overall compared to what I'm used to. That's nothing that can't be "fixed" with an adjusted gamma setting (and I may end buying a colorimeter to properly adjust the monitor), which can give me nice, vibrant colors and a dark/light contrast I consider proper.

For me, this raises following questions, though, which are not strictly tied to my particular setup:

- As a player, are there any rules of thumb as to how Quake is *supposed* to look like? Is there any point beyond "just adjust it to your liking"?

- As a mapper, how can I make sure the lighting in my maps are okay for a wide range of recipients? My current strategy would be "adjust the display settings until the base game looks good. If my own maps look good with these settings as well, then everything should be fine".

How do you guys deal with such issues? 

On the second point, I think if you're confident of your colour accuracy, you should adjust your settings to make sure the base game looks good and then base your lighting on that. That doesn't hold true if you're using a bad monitor, as you might end up making maps that are too dark because you cranked the brightness. 

I always have the brightness all the way down or one tick higher than lowest. On occassion I'll have to raise brightness for a particular custom map, but most of the time I enjoy the gloominess.

I may be biased since bright lights hurt my eyes anyway. 

r_gamma 4
r_intensity 2
r_overbrightbits 100
r_vertexlight 1
r_picmip 100 

r_gamma 4
r_intensity 2
r_overbrightbits 100
r_vertexlight 1
r_picmip 100 

Relatively sure they were talking about Quake 1, not 3. I've wondered a similar thing myself and haven't been able to find a good answer; personally I left everything at default except gamma which is at 0.9 (no idea what the default here is, assuming 1 but that's nearly dark enough you have to squint on my monitor) but sometimes raise it up because every map is a bit different. Any lower (brighter) and most maps including id1 become a lot lighter than they probably should be, although I'll admit I haven't fiddled with the contrast cvar introduced with Quakespasm 0.93. 

Is it possible to turn a light on and then off again (without custom progs)? 

Or rather, how does one do it? Because I just remembered that at least one of the maps in this pack does exactly that. 

You mean just toggling it on and off? Give it a targetname and trigger it with a button/relay/trigger_once/whatever, works the same as a door or anything else you can activate. 

Oh, that seems fairly simple. It didn't seem to work the first time I tried, but I probably made some silly mistake somewhere in my setup. Thanks! :) 

Forgot to add, it'll only work if it's a standard light ('always on' light style): in vanilla Quake, a switchable light is its own 'style', so you can't turn on/off a light that uses anything but 'always on' (style 0), i.e. strobe, flicker, or candle. 

I'm guessing it doesn't apply to light entities that include a model, right? As in, you can't switch a light_flame_small_yellow on and off ... or can you? 

Unfortunately not, the two you can toggle are standard light and light_fluoro (the one that goes bzzzzz- turning off the light doesn't turn off the sound). You can check the qc file that includes lights (https://quakewiki.org/wiki/misc.qc) to see those are the only two that support it; notably this means that aside from the lights that include models, the light_fluorospark entity also can't be toggled, despite being the same thing as _fluoro except it goes 'fzz-tzzt, fzt fzt fzt' instead of 'bzzzzz.'

If you really need more options, IIRC the Quoth mod/entity pack includes a bunch more options for entity states including lights. 

Thanks very much for clarifying.

If you really need more options, IIRC the Quoth mod/entity pack includes a bunch more options for entity states including lights.

Thanks, I assumed Quoth/AD/Rubicon2 would open many more possibilities, but I'm deliberately sticking with id1 for the time being. 

You could place the light_flame_small_yellow and give it a light value of zero. Then next to it have your switchable light entity. Easy hack. In vanilla those don't flicker so no one will ever notice. 

I guess the sound *will* still play... duh. However, you could fake it by having an inaccessible area nearby with a light_flame_small_yellow "motivating" the sound. Think of a crack in a dungeon wall that spills a sliver of light on the floor. That kind of thing.