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. 

But I'm still curious. Just moved the bars away from the doors, which of course does the trick. Would still like to know what I'm doing wrong to make them work while they're still touching.

Here's the .map with the doors/bars touching and set to Don't link. 

Use "r_showbboxes 1" and you can visualize the trigger volume for your doors. 

I'm having some issues with textures :
https://dbr.ee/TmMu
I tried with wally and texmex, it seems to come from j.a.c.k. (which is on default). I never had this problem with goldsrc/wad3 & hammer. Ideas ? 

looks like its missing the palette and using some greyscale thing instead. specifically the 'gfx/palette.lmp' file.

make sure that your editor's basedir+gamedir paths are correct (as well as just the wad+map paths). 

I've loaded the quake.pal from j.a.c.k. folder, still it doesn't work (I see white textures).
Would it be possible to bypass quake.pal and use wad3 instead ? (ericw/quakespasm)
Many thanks 

If I remember the screenshots correctly, since you are so off the "path" of a normal texture just use it as external/replacement. In the editor it will still look messed up but ingame it will be fine. 

Aha, I don't get it.
I tried to keep the install fresh & minimal.
Why do these things tend to get obscure ?
However I got it : the Base Game Directory wasn't set on the right folder (quake main folder, instead of id1).
Those "happy" victories remains me when I was learning how to configure worldcraft 1.1 in the year 2000' without internet connection, at the age of 10. I'm so happy the quake community exist! 

Can anybody give me examples of well thought out combat in long hallways? I'd like to learn how set up a good encounter. Are enemies too weak for open areas, apart from Vores or Shamblers who pose a real threat regardless of placement.