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"? 

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). 

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:

http://maikmerten.de/base1/terrainstuck.jpg

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: http://maikmerten.de/base1/terrainstuck.zip 

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.


"Trenchbroom-crash.map" 

 

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!