With triggers, you can make a door that doesn't simply open when you walk up to it, but only in response to some other event, such as when you pass cross a certain point in a corridor and an ambush opens up behind you. In this tutorial we'll first make a triggered door that functions as a trap: when Corvus walks under it, it lowers & does some damage. Then we'll do a more complicated one, where Corvus pushes a button to open the door. We'll also talk about some other stuff that can be done with triggering.
For the trap, our `door' will be a thin slab, sitting in a position high enough over the floor so that Corvus can walk under it. We need to set its angle-field to -2 (for downward motion), its height-field to something big enough so that it will hit Corvus when it comes down, and its dmg-field to something that isn't totally wimpy. And finally we need to give it a targetname-value, which will be a string that identifies it to its trigger, which we'll turn to next. Let's say the targetname-value is `bonk' (no quotes in the actual value, of course).
Now for the trigger. A trigger is another brush-owning entity, but the brush is not visible in the map. Instead, when the player (or in many cases a monster) touches the trigger, it `fires', and the entities that it `targets' do something. For our trap the most appropriate trigger entity would be a trigger_multiple, which fires every time an appropriate entity touches it (an alternative would be a trigger_once, which is just like a trigger_multiple but disappears after its first use). So follow your editor's procedures for introducing a trigger-multiple with its brush, and put the brush underneath the `door', arranged so that the player can't walk undeneath the door without touching the brush. Now give the trigger_multiple entity a target key, with value `bonk' (the same as the targetname-value of the door). Now the trigger `targets' the door: when the trigger is fired by the player walking into it, the door will lower. So now you should test your map and see if it works.
Before proceeding, there is one significant point about HereticEd. This editor has a special `Connect Entities' (Ctrl K) command for targetting: if you select two entities in turn, and then give this command, the first entity selected will be made to target the second. Other editors might have similar shortcuts of their own (I'm thinking of doing something like this for Quark, which supports user-developed plugins).
The trigger entities have quite a number of keys and flags to modify their behavior. For trigger_multiple, one of the more important ones is wait. You may have noticed that when you walk under the trigger, the door comes down again and again, doing a little bit of damage each time. This is because it is triggered by your being in the trigger-brush, and by default fires every .2 seconds while this is true. You can use the wait key to specify a longer interval, such as 3 (seconds).
A more complex kind of trigger door is one activated by a button. These are typical of the doors where Corvus says `I'll have to open this elsewhere' when you walk up to them. These doors have a targetname key, so if you make an ordinary-looking door like this and walk up to it, you'll notice that it does not open. This is because doors with a targetname-value don't automatically spawn a `trigger-field' in the map that makes them open when somebody impinges on it. A door that is to be opened by a button or level normally would have the message-value 45, which causes the text "I'll have to open this elsewhere" to be displayed and said by Corvus when he walks up to the door. Look here for more on messages, including a list of their numbers. So give the key targetname the value `open' for your door, and also add the message-value 45, and run the map. When you walk up to the door, it doesn't open, but you do see and hear the message.
Now turning to our button, we introduce it as a Func_button entity. Buttons are rather like doors, having a brush that moves when you bump into it (or fire the appropriate animation trigger, as we'll see sson). So the button has a brush, and an angle key, with a value telling it what direction to move in, including -1 for up (maybe useful for a ceiling-button that you shoot at) and -2 for down (a floor-plate that you step on to activate). A button also has a target key, whose value should be the same as the targetname-value of the entity that the button is to fire. So put a suitable button into your map, and give it the target-value `open', and test the map. Now when you push the button, the door should open (and then reclose, unless its wait-value is -1).
Although occasionally useful as a floor-button, a button that just pushes in when you bump into it is a bit amateurish in a 3P game. Sometimes you might want the button to be activatable by being shot at; you can do this by giving it a health-value (1 will do; if you give it a high value it might take several hits to activate, which would be nasty for the player). But for ordinary buttons you're likely to want to do something a bit more sophisticated, namely have Corvus push it with an animation.
To achieve this, put a trigger_playerpushbutton entity into your map. This entity has a brush, which should be placed so as to include the area around the button's brush where Corvus might be able to push the button from. It doesn't matter if it's too big: Corvus will only actually go thru the button-push animation when he's in appropriate place and orientation. The trigger_playerpushbutton entity should also target the button. Now when you test your map, nothing should happen when you just bump into the brush, but if you hit your USE key while standing next to the button roughly facing it, Corvus should perform the button-push animation and the button should push in.
I don't know of any additional useful fields for trigger_playerpushbutton, but func_button has a number of additional ones that you should investigate and experiment with.
And of course there's lots more that can be done with triggering. Basically, if there's a situation where something done to one entity ought to cause something to happen at or to another, the first should target the second. For example suppose we want to make a trap whereby when you walk over a section of floor, it explodes and drops you into a pit. This can be done by having trigger_once sitting over a floor-segment, which will itself be a breakable_brush. And so on and so forth, to the limits of your patience and imagination.