That download seems unbelievably slow, can you put it on shub-hub or something? It stalls at 1% here repeatedly. 

Sorry for that crappy (free) host

http://shub-hub.com/files/maps_singleplayer/progref.zip 

I dont know how usefull it will be, the toggleble trigger_multiple could be a usefull reference. Also the pentegram of lightning - I had a look at the map file in notepad, and it didnt really make sense to me how you managed to get all of the correct angles for each lightning bolt, but I'll have a look at it later again!!

Cheers 

Good idea. Comments:

- can you make all doors wait -1 or remove them?
- can you use a uniform texture theme?
- func_train message is misplaced
- could you make the messages more descriptive?
- perhaps use floor switches, those posts are a bit in the way.
- perhaps add breakables?
- add Than's moving floor gun turrets?
- add glass?
- make trigger_multiple and triggered lights more obvious?
- add monsters dropping guns, or alternate ammo

Quoth demystifies many of those things, luckily, like respawning items, custom traps, and hordespawn. Plus more nice things. No moving water or statues though. 

I've just thought of a trick that might not work, as I haven't been able to test it. It also requires Quake 1.07 (I think all custom engines these days are derived from 1.08)

If you set the "gravity" field on an entity, the effects of gravity on it change. 1 means normal, 2 means doubled, etc... 0 is taken to mean 1, otherwise everything would not be affected by gravity by default.

So what can be done with this? Well, in theory, any monster that jumps can be made to jump further (or not as far). Unless you're using trigger_monsterjump, which is configureable by the mapper already, then the use is really limited to fiends. Giving them a gravity setting of about 1.2 may help to make them more effective in indoor areas, by making them hit the ceiling less.

I'd be interested to know if this actually works... 

You can set multiple teleport triggers on each monster entity, and randomize by using Fitzgibbon's patented shooter trigger randomizer, or make the teleporters trigger at different locations depending upon the route the player decides to take. (HeadThump replying to Ankh in another thread)

Can anyone explain this one for me? 

Give me a few minutes and I'll construct a simple map that illustrates
the second method, the first method with the logic gates is a bit more complicated and I wanted to make a fairly playable map to illustrate it. 

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?