http://mortisville.quakedev.com/tele.zip

This example shows how to place teleporters for a creature to have alternative routes depending on the route a player takes. The creature here is hidden inside the center block, and all the relevant entities are close by that area. 

http://mortisville.quakedev.com/tele2.zip

I added a crude logic gate to the original map that will give one of four results, two telefraged creatures, one telefrag and one creature, or two more creatures in addition to mr tough stuff from the first demonstration.

It isn't difficult to refine this technique to suit your needs. Look in the extra box room to see how it is done. 

Is this safe to use as a door opening trigger? I know that doors will create their own triggers, but it's too large for my purposes... 

While this trick does work, it's not really that necessary. Using one of the equations of motion:

v*v = u*u + 2*a*s

and rearranging for s (distance)

s = (v*v - u*u) / (2*a)

then plugging in the relevant numbers: u (start velocity) = 250 (we are only concerned with the vertical here); v (end velocity) = 0 (when you reach the peak of the jump); a (acceleration) = 800 (due to gravity); and you get

s = -39.0625

Now add the height of a fiend (88), and see that it will miss a 128-high ceiling by just less than 1 unit. Except for 2 small problems. Firstly, the qc adds 1 to the z component of the fiend's origin juszt before it jumps (so it will brush the ceiling very slightly), and secondly, it's possible for v_forward (the direction that fiend will jump in) to have a z component (if the player jumps at the right moment).

Still, it's something more to play wih... 

It should work as long as you don't want a message for the player on that trigger. Just remember that firing nails through the trigger will also op - not just monsters. 

But I decided that it's not worth spending the brushes on in this map, so I'll save it for next time... 

Probably obvious from Preach's post but just as a reminder:
Monsters don't cross gaps in the floor and more often than not this is a disadvantage. Apart from monsterjump triggers, this can be fixed by filling the gaps with skip-textured func_walls which have their "owner" fields set to "1" (player), so they're invisible and don't block the player's projectiles but allow monsters to walk on them.
The downsides are that they block monster attacks (unless the monsters' owner fields are set to the entity number of the func_wall - however, then they won't be able to walk across the gap, I think) and also coop players' projectiles. 

Is it possible to make a door not open until it's touched? I imagine the obvious way is to make a trigger brush 1 unit wider than the door, but I was wondering if there's a method that doesn't use any additional brushes apart from the doors. 

"touch" "door_use"
and give it a targetname so it doesn't spawn a trigger

that's a good idea to save models, actually. does it work? :) 

the triggers automatically spawned by doors don't have models, just bounds.

and door_use will only work if you set the door's owner to itself. I think. Shit, I don't know, I'm posting from work and browsing the progs src on inside3d, don't listen to me. 

The trick here is to start with a func_wall, not a func_door. Add the following keys:

touch door_fire
state 1
speed 100
pos2 'x y z'
owner *edictnumber*


where pos2 a vector describing the offset that you want the door to move by, '0 0 128' makes it open upwards by 128 units. You need to set sounds using the noise1 and noise2 fields, and precache those sounds elsewhere. The wait and speed fields work as before.

One weird trick you can do with this set-up is to set pos1 to a different vector. Then when your door closes, it will go to a position offset from it's original location by the value of pos1. There might be one other nice thing you can do, but I haven't quite worked out the details yet, will post later if anything comes of it... 

While you're at it, how does one make a secret door that moves up first, then in the specified direction? 

I should have added to the above post that *edictnumber* needs to be replaced with the actual edict number of the func_wall - in other words you need to make the func_wall its own "owner".

To make a secret door move up first, and then in the direction specified, I think that setting the SECRET_1ST_DOWN flag and then setting the third component of the angles vector to 180. Remember that map editors only give you y axis control(apart from the up/down hack) in the angles field so you'll need to put this angle in with a text edit.

The aim of this is to set the angle such that when you perform makevectors on the angle, the V_UP vector points downwards. Since the first two components specify the V_FORWARD vector, I'm pretty sure the last one then just rotates the V_RIGHT and V_UP pair about that vector. If the angle has no pitch(x component) then V_UP is straight up when the roll(z component) is 0. It makes sense that changing that to 180 would invert it. 

It seems the owner hack doesn't work in DP - at least with my button-gugattack setup. 

Are you use that you've specified the correct entity number? It's not a hack per se to make something the owner of itself, that's what a regular door does as long as it's not linked to any other doors. The only hack is specifying a number in an entity field. 

I guess the way I used it doesn't work in any engine. I had the edict number of a shootable button assigned to a Gug in order to prevent him from accidentally fire it with his bile attack. It seemed to work in BJP but I just tested it again and in fact it doesn't. 

That's because the gug's bilebomb will have a different entity number than the gug itself, and so the number in the button won't make any difference. There's no hierarchy of ownership in quake, if A owns B and B owns C, then A and C can still collide. In addition, blast radius attacks still hurt the owning entity, the main idea behind the ownership is so that the projectile can be spawned inside it's owner without it blowing up from the contact. It's actually quite a neat way of preventing out of bound glitches with the projectiles. 

And by that, I mean an ambient_drone from off to on. Any ideas? 

You obviously tried swapping the sounds around from that same solution? 

Let's just blame that one on lack of sleep, shall we? 

Works with the standard sound hack.
A trigger with "use" "train_wait" and "noise" "ambience/drone6.wav". It will start looping the sound after being fired (the sound has to be precached). Afaik, turning it off again is not possible, though. 

once the player moves out of range of the new sound, it will no longer be looping if the player goes back into range.

it's unfortunate, but afaik, there is no way to have a true ambient sound be customizable. it can only be hard-coded. :( 

Surely you can use trigger_relays to force the ambient to start every 5 seconds (or at some multiple of it's length). Sounds a little bad if you hear it suddenly start, but it will keep it playing... 

you get clipping artifacts when the sound restarts, since even if you made the sound loop perfectly, quakec is not going to reliably time the cut at exactly 5000ms or whatever. 

It does keep looping infinitely regardless of where the player goes.