The runes don't actually set anything on the player, they set the bits of a global float called serverflags. So this can't be caught directly by a door. There is a roundabout way of using runes to trigger things, but it involves a system of "logic gates". You have a trigger_multiple at the door that targets the following info_notnull:

use func_episodegate
spawnflags [1-15]

This info_notnull is positioned as a blocker in the first logic gate. This is then inputted into a NOT gate that will target the door open. Kinda round the houses though, as you could basically do the same thing by using a spawnable trigger for the door (using the info_notnull hack) that is spawned when you pick up the rune.

However, it is still possible to make extra keys, they just won't have an indicator on the HUD. Simply use item flags that don't indicate any weapons. 128 represents IT_EXTRA_WEAPON, so it's unused. You can also go a few powers of 2 higher than 4194304(IT_QUAD). So just making a BackpackTouch that gives you one of these dummy items will give you a new key.

The main edge this method has over the two ways of doing runes is that it'll work properly in coop, ie. only players who have taken the key will be able to open the door. The downside is that if they die, the key may be lost forever, as the BackpackTouch works only once.

The way round this is, strangely enough, to use the actual key_touch function instead of BackpackTouch. Just set the items, netname and noise as you desire, and it'll just work.

You'll probably need to have a seperate entity to represent the key visually, that gets removed when the key_touch info_notnull is fired, but not in coop mode. So that's a combination of the coop trigger hack, and one of those dynamic func_illusionary things from the mapping help thread. Phew, and all that to get things working in coop.

If you don't care about coop, you might as well just go down the route of spawning the door's trigger when you "pick up" the key, it's easier and fewer entities for the same result. 

For those of you who want to emulate Half-Life, here's how to make monsters mad at one another. You really need to script fights carefully though, you aren't creating alliances between groups of monsters, you're just selectively annoying them as if they shot one another. So after they kill their one target, they'll just stand around unless attacked again, even if others are fighting.

Perhaps a good way to choreograph a bigger brawl would be something like
ogre 1 gets mad at fiend 1
fiend 1 gets mad at ogre 2
ogre 2 gets mad at fiend 2
fiend 2 gets mad at ogre 3
...
fiend n gets mad at ogre 1
that loop should make sure everyone fights.

Anyway, getting ahead of myself, what you do:
Set up your monsters, run the map, type edicts in the console and note down the entity numbers of the monsters you want to fight.

Add a brush over each monster, and convert to info_notnull with the following settings

owner n
use InitTrigger
targetname que1
touch spike_touch

where n is the edict number of the monster you want it to get mad at.

Then two more triggers to set the thing going, a trigger_once with target que1, and an info_notnull with

use teleport_use
targetname que1

In fact, this is such a minor thing, you could even tag it onto the info_player_start you use and save an entity.

Of course, the way it works is that the triggers behave like a nail fired from the monster in the owner field into the target monster, so it gets mad according to the infighting code. You don't have to use trigger brushes, spike_touch and teleport_use if you don't want - voreball and ogre grenade explosions set off from point info_notnulls with owner set have the same effect, if more dramatic in execution. Be warned, this will fail on monsters of the same type - for a minute there I used two knights to test it and thought the hack wasn't gonna work! 

I want a trigger_once that is not 'switched on' for use until some other pre-defined action has taken place; perhaps by a monster dying or a button being activated. This trigger will be in an oft' used area and may be 'touched' many times before I want it to become a trigger_once. The player must remain unaware of the trigger.

I don't want to use doors or buttons, or add any extra brush work, so no 'logic-gate' scenarios.

Is this achievable through some clever use of the trigger_once fields or spawnflags. Or will I need to resort to QC? 

http://www.celephais.net/board/view_thread.php?id=4&start=4469&end=4469
highly useful hack 

hmm, on a second thought i always used
"use" "trigger_once"
"touch" "SUB_Null"
probably just another way (without apparent downsides). 

Thanks for the speedy reply, I'll get on to it. 

Great stuff! 

Surely logic gates are a better choice than creating a new progs.dat for this one thing.

But I am curious to know if there is a simply one-entity hack to do this; that would be useful. 

I must have had this page open for like an hour before commenting :P 

...I can open a .qc file, fiddle with it and recompile in less time than it takes me to build brushwork. My editor compile GUI can then re-run the map in one click with -onlyents selected to run the map with the new progs.dat in about three seconds. So, apart from the fact that I'm not too good with QC, I would find it easier.

My map will have to have my progs.dat to play as it has a mixture of monsters, so again, it is easier for me.

But I am not a 'wheel inventor' so the notnull thing suits me fine.

Having no professional interests in gaming, programming, IT, web-design etc, all of this mapping lark is just a bit of fun that takes an hour or so of my time every other day when I'm at home. And I enjoy poking around in Quake's inards even if I get lost every now and then:-) 

FrikaC posted a killable Chthon on I3D:

http://forums.inside3d.com/viewtopic.php?t=475 

Ok, this DOES work. He's how to make an invisible barrier that stops monsters but not players. This only works for monsters that don't swim or fly, and if the monster jumps or is pushed, they may pass the barrier.

First build a 32unit high step where you want the barrier to be. Apply a regular solid texture to the brushes. Now make a clone of this brush and position it above the existing brush. Make it 64 units high - it can actually be as high as you like, but lets use 64 units for now. Apply the clip texture to this. Select both brushes and make them into a func_wall entity. Now move the whole thing down into the floor slightly so that the solid brushes are 16 units below the floor (if this doesn't work, try 8).

Compile the map and run it in Quake... hey presto! The monsters should be stuck behind the barrier. Hopefully, you should be able to walk through the barrier without problems.

Turns out I used this weird trick in apsp1 after all. It was reused twice in dm3rmx when I rediscovered how it was done, though I killed the barriers in that to allow the monsters to pass after a certain time. 

Here is an example map of stupid test things which happens to also contain the trick I mentioned in the above post: http://than.leveldesign.org/files/invisBarrier.7z

Ignore all the stupid shit I put in there, and just watch how the enforcer won't come out of his little box. Try the same thing with a fiend... you'll be in for a shock. 

You are simply a one-man repository of l33tness. This'll come in big use with my base map =D 

A trick I use is even simpler -- players can cross any gap in the floor that is 32 units or less across, becuase they have a 32x32 bounding box and use hull1 to do their collision.

Monsters, on the other hand, use hull1 or hull2 for collision, BUT they use hull0 to do their pathfinding. Since there's a gap in hull0, they think they can't cross it. So just like cattle guards at the entrances to pastures, you can simply put grates or other gaps where you want the monsters to be blocked.

Gratuitous cattle guard picture: http://www.3rf.org/album/ComancheSprings/slides/cattle%20guard.jpg

And an example in antediluvian: http://www.celephais.net/shite/ant2.jpg 

That's pretty nifty. They will come at you one the floor is "filled" like with a func_door, right? 

http://forums.inside3d.com/viewtopic.php?t=475

FrikaC explains how to make a Chthon that can be killed by the players weapons rather than electrodes, without doing any qc coding or using another progs.dat 

very well written, too. Helped me understand certain aspects of the coding process more intimately (though we're still 'just friends' at this point).
But since I can't test it, I'd like to clarify one thing... he won't pop out and start going? almost immediately after starting the map he'll begin tossing his loud fireballs around? or am I confused? 

is there a way to make a monster invulnerable until a certain point, at which he'll become vulnerable to weapons/lighting/smooshing? 

this is possible. simply add a "invincible_finished" "#" field.
the awkward thing is that the # seconds start counting down when the map starts, so events involving such monsters have to be carefully planned. 

i hear that FrikaC has a way to make a killable Chton without quake-c? or was it marcus sklar. . . 

you're thinking of that level from 1997, called "THEFLY" or something... I think it was by this guy Marcus Klar... 

no way to trigger it huh? that takes alot of the fun out of it... 

I know this is probably getting annoying, but how do you get monsters to drop weapons/ammo? when making a floating weapon, do you simply place it on a func_wall and then kill it upon starting the map? Any other "widely known" hacks? 

as far as i know, you trigger this cthon the normal way. I'd have to re-read the tutorial to be sure, though.

And yes, you kill the func_wall immediately after map load, using a trigger on the start point or something. At least that's the traditional way to do it. I wonder if this would work instead:

"classname" "func_wall"
"nextthink" "0.1"
"think" "sub_remove"

or would that not work because func_walls already have a think function?