We all read the same threads here, there's no reason to crosspost when there's only like ten active threads on the whole site. 

So I'm tired and maybe this is obvious ... is it possible to have a trigger_once that starts disabled (won't respond to player touches) and then has a way that I can turn it on later? 

Than had a really good tutorial on how to do complex and/if/or trigger system using nail shooters. No idea how to find it though. 

make that trigger_once a trigger_multiple targetting a shooter that that shoots a your trigger_once.

Put a func_wall in between, kill it when your trigger is needed. 

or: include a progs.dat that actually does that, and skip all that nonsense 

It's more nonsense to include a progs.dat just for that feature if there are means and ways to achieve it within the standard code.

Most basic hack: info_notnull brush entity with a "use" "trigger_once" field and a targetname. Becomes a regular trigger when being targeted by any other entity. 

https://tomeofpreach.wordpress.com/2012/11/18/mid-map-entity-spawning/ is the negke way of doing it.

If you need to be able to turn the trigger on and off multiple times, you need https://tomeofpreach.wordpress.com/2013/05/13/new-logic-gate-design/ plus the follow-up pingback in the comments. 

How does one get around the precache issue for trigger_once or trigger_multiple? The first link from preach uses "trigger_multiple" as the example but I can't get it work without crashing out due to precaching ... what am I missing? 

The first example is a monster_ogre, to illustrate the limits of the technique. Make sure you're actually using a trigger_once classname instead. If you're still getting crashes and there's no trace of monster_ogre then can you say which model causes the error? 

Yep, it looks like it's something to do with trigger_multiple ...

https://dl.dropboxusercontent.com/u/161473/Misc/2015-05-24%2017_07_09-QuakeSpasm%200.90.0.jpg

I currently have a door entity targetting the info_notnull and when the door is activated, boom, it crashes.

I get the same crash using a trigger_once or triggering it from another actor other than the door.

It must be something simple but I don't see it yet... 

Aaaaand never mind! I had a...

"sounds" "3"

...key on the info_notnull for some reason. Deleting that makes everything work.

Thanks a lot for the help! Excuse the derp... 

That's good, I did wonder if it was that, but I thought missing sounds were just a warning not a crash. 

Actually reading the error, it's the other way round, trying to precache something late, rather than trying to use something without caching it first. For models, both are fatal but for sounds the latter can be survived. It is possible to get sounds indirectly - set the noise keys with the paths to the desired sounds. Of course, you need some other entity to do the caching for you or you get warnings and no sounds... 

There is no func_group. It's a huge pain working without this. 

the .map format doesn't have native support for groups, so you have to hack it with func_group and a compatible compiler if you want it.

you can add func_group to your entities.ent file (usually hidden in something like E:\GtkRadiant\ 1.5.0\q1.game\id1)

<group name="func_group" color="0 .5 .8">
Used in editor to group structural brushes. Added to worldspawn by QBSP. Not a real entity.
</group>

stick that in with the other brush entities (find some other entity like func_wall or something, and add it after it's </group> tag). then you can make func_group like any other brush entity in Radiant, and select all their parts with ctrl+alt+e

you'll want a qbsp version that supports it, otherwise it will be compiled into a brush entity that Quake won't recognize. I know ericw's latest tyrlight will have support
https://www.dropbox.com/sh/1q5giu2leyvvhk0/AAA0UCacYD-tgVpElMSpf5Awa?dl=0 

ericw's latest tyrutils I meant! been fussing over tylight too much lately... :D 

Thank you so much! It seems to be working fine with hmap2 and ezquake.

I'm curious though why Quake has to recognize it. Isn't it really just for convenience moving stuff around in the editor? 

To the editor, a func_group is just an entity with brushes attached (like a door, button, etc.) These are normally treated specially by qbsp (compiled as a bmodel) and the engine (looks for qc code with the classname to set up the entity behaviour).

But since func_group is a special thing just for mapper convenience, qbsp has special code to merge it into the world, and the engine never sees it. 

When I use 254 as seen here http://www.celephais.net/board/view_thread.php?id=4&start=14949 texmex turns it brown like 255, and that's how it appears on the map. 

Of course I meant here: http://quakewiki.org/wiki/Quake_palette 

254 should work. Is it broken in all engines or just some engines? 

oh wait, it sounds like it might be a texmex bug (if the error occurs inside texmex too) 

btw i didn't write the code in http://quakewiki.org/wiki/Quake_palette even though it claims I did. That's not now i write single-line comments :) 

...is how they managed to name all 16 rows without repeating the word "brown"