News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread:
First | Previous | Next | Last
Client/Server Architecture 
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 
"There's Probably A Nice Flowchart Out There Somewhere" 
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, PRITCHARD, Qmaster and Blitz. 
From Savage X 
New Monitor, New Colors

Posted by SavageX [] 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. 
Do A Survey: What Brightness Setting Do You Use? 
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. 
Thanks, Spud 
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. 
Thanks For The Extra Info! 
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 ( 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. 
Thanks For The Tip 
That's not exactly the kind of scenario I'm going for at this point, but I'll keep it in mind for future reference. In the mean time I think I've found a different solution ... but I need to play around with it some more. 
Mcache 2047 
anyone got any tips for lowering the number reported by mcache? My Christmas Jam map won't load in anything except Darkplaces right now (yuck) :(

I suppose I should reduce the number of breakables in the map, but that almost seems a shame... So any tips? 
does darkplaces's "mcache" command print the list of models like QS's?
The ones with a "*" prefix are submodels of the main bsp, i.e. func_ stuff in the main map. The other things in the list will be the unique mdl's and sprites precache by the map.. so e.g. if you remove all monsters that use a certain mdl, it should free up a slot in the list.

Can you merge any breakables that are close together?

If you use any func_illusionary / func_wall that don't need any scripted behaviour, switch to func_detail_illusionary / func_detail_wall, which don't use up models. 
mcache isn't a command that works in DP.

I merged a lot of breakables, saved several hundred entries. I'll see how I go getting through the rest of the map, there are a lot of func_illusionary brushes that i could convert if need be. 
Several hundred!??

You could potentially combine all func_illusionaries into 1....except then they would probably always be drawn instead of culled. 
Looking forward to seeing all these breakables!

You could potentially combine all func_illusionaries into 1....except then they would probably always be drawn instead of culled.
func_detail_illusionary are pretty much perfect for this, the only downside is they tend to increase leaf/node count, because they're part of the main bsp just like func_detail. It's only really a problem if you're trying to fit in standard BSP format and are near the limit.

func_detail_illusionary will also have the best rendering performance (as they're identical to other world polys), and 100 separate func_illusionary's the slowest. 
I did look into func_detail_illusionary but it casts a shadow, which makes it unusable in a few of my cases for this map.

Unfortunately the breakables aren't that interesting - just crates, like I did for my Noir Jam map. Interestingly despite all the breakables the mcache for that map was <1000. 
Ah, right.. for it to not cast shadows you need to be on the latest version of my light tool. I'm still working on the bug you reported, sorry it's taking so long 
Bsp Limits 
Wait so do brush entities not count towards the limits for verts, tris, etc.?

Is the limit per "model"? 
brush entities do count towards the overall .bsp file limit, but func_wall vs func_detail will have different resource usage because the func_detail has to slice up the map geometry that it is overlapping (leafs/nodes, faces). 
Colliding With Quake's Collision Method 
On my current mapping adventure I'm creating an outdoor map with terrain-esque features. I find that in Quakespasm and Winquake I get stuck when walking over that edge:

All fine in FTE and Darkplaces. Map compiled with the awesome ericw-tools. All brush vertices on integer coordinates.

I'm pretty sure a random vertex manipulation should resolve the issue and I guess this is just a side-effect of how Quake handles collision (I think FTE and DP basically have their own ways of doing things there).

Is there a lazy way to resolve such issues reliably other than pushing vertices until things are resolved?

BSP and .map source: 
That's A Pretty Common Issue 
It can even happen out of nowhere after a compiling in areas where nothing has been changed since several compilings before.

Move some vertex around a bit and that will disappear. 
Yeah, I already fixed it - once you discover such problems a workaround does seem to be mostly trivial. Just wondered if this is an indication that I'm doing something wrong or if this is just some charming oddity of Quake in general. Looks like it's the latter and I shall embrace the madness Quake awakens in our hearts and minds.

Glad I'm testing with multiple engines, though ;-) 
If one is mapping using trenchbroom on an unsaved map and TB crashes, is the map lost?? 
Ive found them hiding in C:/users/MYNAME.

You're A Lifesaver! 
this is just some charming oddity of Quake in general

Yes, and that's why there is not much terrain in Quake custom maps, and one of the reasons there is none on the official maps. 
niccce. happy to help, drow! 
Higher Resolution Lightmaps With FTEQW? 
I'm using ericw-tools to compile my maps but the lightmaps always look like shit. They are too blurry. Is there a way of increasing the lightmap resolution? 
you can do it on a per entity basis by adding an '_lmscale' field set to eg 0.25
on the command line you can use '-lmscale 4' with ericw's light util.
I'd also recommend the '-bspx' light util argument, if only so that you don't need the external lits.

alternatively compile it as a q3 bsp via q3map2 (using q1 ents still so that mods don't break). A _lightmapscale field set to 0.25 or so for that, I believe. this'll give you a few more options that are not available with q1 bsps.

that's the theory, anyway. note that each of these have different results when viewed in other engines. 
There's a good chance I inadvertently broke one of _lmscale/-lmscale/-bspx since I haven't tested them since Spike contributed the features, but a ton of other things have changed since then. If that's the case, there are old releases available at: and feel free to file a bug.

Anyway I would +1 using q3bsp. AFAIK all of the _lmscale/-lmscale/-bspx options will produce a q1bsp that only looks right in FTEQW. 
iirc the per-entity _lmscale + -bspx will generate redundant data for engines that don't support it.
obviously other engines will get inferior lighting, but it should at least otherwise work (unless you use -novanilla for smaller bsp sizes, in which case other engines will glitch, but shouldn't crash).

I really ought to add this stuff to QSS too, same as many other things. 
QSS now supports lmscale too, in case anyone cares. 
Q3bsp... But... But... Lightstyles? 
Won't you lose lightstyles by going q3bsp? I always considered that a feature-gap that might have a sound technical explanation (*) but just robs single-player maps of a simple way to make things appear more dynamic and dramatic.

(*): I guess lightstyles just don't go well with the light-grid, but then I'm not a fan of that anyway because its size just balloons quickly as you extend map dimensions unless you lower the resolution so much you could just as well sample from the lightmap. 
the rbsp variant (and derivatives like fbsp) supports lightstyles (4 per surface, like quake).
and yes, 4 styles per lightgrid node too (it uses some compression scheme).
FTE supports them (if you've custom shaders then lightmap passes need to be first due to format weirdness), but dp doesn't.

(side note: it might be nice to calculate model lighting for the centre of each leaf, and interpolate between those, using surface data in place of neighbouring solid ones.)

even with q3bsp itself, you can get lightstyles with rtlights.
alternatively you can get quite creative with custom shaders. 
The problem with q3bsp is that i can't use TrenchBroom and Radiant is pathetic. :( 
Can you provide a screenshot of the light/shadow situation?

In Quake (when not going to q3bsp) it's pretty much not possible got get sharper shadow/light contrast than shown, e.g., on - all one can achieve is to make sure you don't get ugly stairs by using some advanced light options (in my case, for final compiles I use -extra4). 
The problem with q3bsp is that i can't use TrenchBroom
Does the compiler not accept q1 map format?

You could use the -convert flag on my qbsp (see ) and hook that in as a compile step. You can convert vanilla q1 map to q2 (which I think q3bsp compilers accept). Or, valve to brush primitives, etc. 
In Quake (when not going to q3bsp) it's pretty much not possible got get sharper shadow/light contrast than shown
There is the "scale your textures up 2x and use texutre scale 0.5" hack that gets you higher resolution. Downside is it causes more qbsp subdivision of your level so the faces still fit in Software Quake's surface cache. 
2X Texture Size With .5 Scale 
Downside is it causes more qbsp subdivision of your level...

Would QS/QSS have any issues with that?

I don't think I asked this specifically in a previous post, if it has been answered already my apologies ;) 
It makes a mess of linear filtering.
Replacement textures should at least fix that, but anyone using the default settings+textures will find it looks a bit ugly.
Software renderers will have less mipmaps available (this also affects fte's r_softwarebanding).

note that you can also double the -subdivide qbsp arg too which will reduce the subdivisions needed.
QS supports up to (128-1)*16-precision. glquake actually supports up to (18-1)*16-precision.
FTE/DP/QSS(now) support up to (256-1)*16-precision. However that doesn't mean you must use lightmaps that big, as it kinda makes a mess of the lightmap allocator resulting in excessive wasted space, with more texture switches/batches (doubling won't hurt much though). 
7 posts not shown on this page because they were spam
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.