Have a continuous trap spikeshooter attacking a func_button wih health tucked away in a box far off where the player can't hear it.

Put a func_wall blocking the shooter.

Add a killtarget to your monster that kills the func_wall.

There might be a simpler info_notnull hack but I can't remember one atm. 

Are you serious? Over 20 years of Quake mapping and no simple workaround for more than one target? 

but the id1 progs.dat isn't going to change.

If you include customs progs, then lots of them have supported target1, target2..... etc. 

I still know nothing of progs. Just figured out how to map with Quoth today so you can see how little I know of Quake mapping. How could I set up progs to add targets to entities? 

https://tomeofpreach.wordpress.com/quoth/tutorial/multiple-targeting/ 

Thanks. I thought Quoth would have something for it. Preach to the rescue as usual. 

Preach's article makes no mention of how to actually use the feature. Do you just add the key manually to the entity or what? I tried adding target2 to my monster to the path_corner but it doesn't work. 

path_corner is handled differently to usual targeting - try just using the default "target" field for the path_corner and the extended "target2" (etc) fields for things that trigger on monster death. 

Thanks. Why or how are they handled differently? 

A target field can always trigger multiple entities that share the same targetname, right? I think the issue there is probably just with the path_corner... if it's not the first entity with that targetname that find() comes across, then the monster won't patrol.

I wonder if that particular multiple target situation would work even in id1 progs if you could guarantee that the path_corner was lower in the edict table. 

I posted that before refreshing to see the other two posts above.

More for sevin:

When a monster is first "initialized" in the QuakeC code (progs) that shipped with Quake, one of the things that happens is as follows. If it has a target specified, it looks for the first entity it finds that has that targetname. If the entity is a path_corner, it starts patrolling.

Later when a monster dies, if it has a target specified, it triggers any trigger-able entity that has that targetname.

So in the original Quake game code they didn't think about supporting the case where a monster is BOTH patrolling and is ALSO meant to trigger stuff on death.

It sounds like that in Quoth only the original "target"/"targetname" fields are used for that patrol behavior, but all of the new additional target/targetname fields can do other triggering stuff. 

When a monster is spawned, it checks to see if self.target is a path_corner, or something else. If it's a path_corner, it makes the monster start walking straight away, otherwise the monster is told to just stand, which is also the default behaviour if it has no target.

I can only assume (without looking at the quoth QC code) that quoth only does the path_corner check for self.target. This sounds reasonable because you do not need to target multiple path_corners, so there's no need to overcomplicate things. target2, 3 and so on are thus assumed to be regular targets, not path_corners. 

I posted that without seeing Johhny Law's posts above 

two ships passing in the night ;) 

This can actually be done in vanilla id1, at least for the given scenario- no map hacks needed, just some prior knowledge of entity priority. No idea how it'd work with other entities being targeted, but enemies can be set to both patrol a path and activate a relay or counter on death by simply creating the path_corner first, then creating the relay with the same name. As long as the path_corner comes first in the entity list, the monster will follow the path, but still trigger the relay on death.

Basically, the enemy should target two entities with the same name- a path_corner and a trigger_relay placed in the map after the corner (so be careful if you're deleting or remaking things constantly). If the relay comes first, the enemy will still activate it on death but won't patrol to the path_corners. Here's a webm of an example map (ignore the "holy shit I figured out how to get custom conchars working" kludged HUD) and here's the .bsp and .map themselves. The left and center Grunts have the corner loading first, with the leftmost Grunt also having multiple path_corners (it takes a while for him to get there, though); the right Grunt has the relay first so he just stands there like a dork. All three function properly for the counter. 

Because I just got ninja'd something fierce, goddamn. 

and yeah, like Johnny Law says, it does appear that a "hack" is possible in id1 where it *would* work when both the path_corner and other targets share the same targetname, if you can guarantee the path_corner comes before all the others in the edict list.

On a related note, ever been killed by a monster who was not previously on a path, but then starts walking towards something after killing the player? That's a monster who had a target, which wasn't a path_corner. When his enemy dies, he starts walking towards this. It's a harmless bug, caused by the rather dumb way in which the "is target a path_corner?" check is performed when monster spawns. 

posted that without seeing Spud's post. I probably din't need to mention the id1 hack a third time :p 

Great info above, thank you all! To clarify, I figured that setting the first path_corner and the trigger_counter to the same targetname would allow them both work (thought I didn't know entity priority matters in this case), but I didn't want to do that. I like keeping my named entities descriptive of the entity and its relevance to other entities, so doing it another way would be better. 

Do func_doors trigger themselves at close proximity? I have a func_door set of bars with the GK spawn flag that cover another func_door. Finding the GK lowers the bars, but it also opens the door behind it. Why is this? They are not connected through I/O. I just want the bars to lower so I can walk into the door and have it open as normal. I've tried giving the actual door a targetname connected to a trigger_once that enables once you find the GK, but that didn't work. 

If the doors are physically touching each other, they'll act as linked doors, normally used for double doors that open sideways. Tick the Don't link spawnflag on both and test it again. 

Cool. Yeah it should have clicked with me that the beeping meant you were hitting a wrong key. My bad. :)

Yep just dig into the docs for the tools and youll start to piece things together. Qompilers cool for compiling multiple maps at a time, a bit overbearing for single maps but works all the same. Try getting comfy with JACKs compiling UI before relying on Qompiler. 

But if I set Don't link on the left and right doors and the bars, the doors don't open when I walk up to them. The bars lower separately, but I can't go through the door. 

Does the center door (not the gold key one, the double doors you go through after?) have a targetname? If it does, get rid of it- a door with a name will only open upon being triggered (i.e. by a button), not by the player walking up to it. It's an easy mistake to assume that every entity needs a targetname, but as a general rule, unless it's specifically being targeted by something else and requires one, leave it blank.

A screenshot or .map upload might help too, sort of hard to visualize this in the brain without a reference point to what the door setup actually looks like.