"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. 

#16 - How does that work exactly; could you post an example entity? Is it also possible to override a monsters existing th_missle function, e.g. to let scrags shoot voreballs and hellknights shoot Chthon etc? 

because the th_ functions are set in the monster spawn functions. you'd have to 'build' the monster you want from scratch and then modify from there. 

"build" in quakec or in a .map hack? 

similar to how does one build a killable Chthon with info_notnull hackery?

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

i was referring to the post a little while ago about building a monster with an info_notnull 

As we all know, having large amounts of health can never be wrong, but unfortunately the Megahealth item doesn't like us to be enjoy our surplus very long. Time to change it:

"classname" "info_notnull"
"origin" "# # #"
"think" "PlaceItem"
"nextthink" "0.2"
"touch" "health_touch"
"healtype" "2"
"healamount" "100" // up to 250
"maxs" "32 32 56"
"model" "maps/b_bh100.bsp"
"modelindex" "#"
"noise" "items/r_item2.wav"
"targetname" "mh"
"killtarget" "mh"
"delay" "0.1"

Now, what's so special about this? The killtarget actually prevents the item from rotting down to 100 like normal Megahealth packs do. This way, nothing will be wasted if one doesn't engage in battle immediately.

You could also do this at map start, for example, by creating an info_notnull brush entity with the same fields except "maxs", "model" and "modelindex", and changing "think" to "InitTrigger" 

A neater way (for some situations, e.g. secrets) of using the BackpackTouch hack mentioned earlier in this thread:

"classname" "info_notnull"
"origin" "# # #"
"think" "PlaceItem"
"nextthink" "0.2"
"touch" "BackpackTouch"
"model" "progs/backpack.mdl"
"modelindex" "#"
"ammo_shells" "20"
"ammo_nails" "50"
"ammo_rockets" "10"
"ammo_cells" "25"

This will create a backpack that looks and behaves exactly like those the monsters (or players in DM) drop. Of course you can also put some weapons in, with "items" "#" and "netname" "Weapon name". Just don't squish the sandwiches, though. 

Ooh, love the backpack idea! Neat stuff, negke!