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" 

 

Hey there, I've heard about the q3map2 option -keepLights that is supposed to stop the compiler from stripping out light entities. Though, it never seems to work for me whenever I try it, what's the most correct usage? 

That is a worldspawn switch 

So what should I do to use it? What process do I stick this thing on? 

What about worldspawn's "_sunlight_color" key? I'm using tyrutils v0.15 qbsp, vis and light, getting only bland white sunlight. It seems to ignore that key. I tried 64 192 255 and it's still white. I'm on Worldcraft 3.3, but that shouldn't matter. What am I'm missing? 

Sorry, I'm mapping for Quake 1. Here's light.exe output:

---- light / TyrUtils v0.15 ----
running with 4 threads
BSP is version 29
Colored light entities detected: .lit output enabled.
4 entities read, 0 are lights.
0....1....2....3....4....5....6....7....8....9...
Lighting Completed.

lightdatasize: 1989
0 switchable light styles
Writing BSP version 29
0.0 seconds elapsed

The level shows sunlight, but it's always white, no matter how I set _sunlight_color 

Make sure to copy the both the .lit and .bsp to your maps directory, if you're compiling in a different directory.
Does your engine have .lit support? Most do, except the original winquake/glquake.