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. 

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. 

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 

Wait so do brush entities not count towards the limits for verts, tris, etc.?

Is the limit per "model"?