If there's something more to do with doors that you can't figure out, email HexenWorld message board.
A door, any door, consists basically of two things; an `entity' that describes how the door behaves, and some brushes that are owned by the entity, and provide its visible and touchable shape in the map. This `ownership' concept is called different things in different editors, in Worldcraft for example a brush is said to be `tied to' an entity, which is its owner. So you will first need to know how to produce the entity plus owned brush combination, in a decent editor this will be easy. One entity can own lots of brushes (so a door can have a very complex shape, that of a grating, for example), but each brush can have only one owner.
Turning to the entity, this is made up of a number of `fields', often called `keys' or `specifics', which provide the actual information about how the entity behaves. Each field has a name (kind of information) and a value (the actual information provided). The one field that always appears is classname, whose value says what kind of entity it is. All map-editors will provide some kind of menu whereby the entities are listed by their names (classname-values), so you can do something like double-click on the name in order to insert the entity into the map, complete with its classname, and hopefully some other fields to fill in.
For a basic door, the entity you want is func_door (many but not all of the entities that are `active' and actually do something have names starting with `func_'), and there's only one additional field you need to produce a basic, functioning door. This is angle, and what it does is tell the door which way to move when it opens. The angle is specified in degrees counterclockwise from East (righwards on you screen). E.g., if the angle-value is 90, the door will move Northwards when opened). If you don't specify anything, zero will be filled in by default, and your door will move Eastward to open.
So now would be a good time to make a little map, consisting of a room with a func_door entity, with the entity's brush sitting in the middle of the room. When you've made all this, start your map and walk up to your door. It ought to move in whatever direction you've specified in the angle-field, and then move back after about three seconds (unless you're standing in the way blocking it).
So if that worked, there is one more thing to know about angle, which is that you can also specify it as -1 to make the door open by going up, and -2 to make it open by going down. So you should try both of these out now. The angle field works the same for various other entities, such as buttons, so it's good to learn it.
There are quite a number of additional fields you can add to the basic door. Two that you should try right now are wait, how long (in seconds) the door stays open before closing (with a value of -1 meaning it stays open), and soundtype, the noise it makes. The soundtype values are basically numbers, which some editors will let you select with some sort of drop-box, but others will require you to fill in the numerical codes, which are listed here.
A variety of additional fields are listed on the reference page for doors, I hope that at this point the explanations will make sense down thru health.
Triggered doors don't just open when you walk up to them, but are made to open by some other event, perhaps quite far away, such as as the pushing of a button, the taking of an item, or other more complex circumstances. What we'll use for our first trigger is a simple button, since they're very similar to doors, and quite useful.
A button is made with a func_button entity, which is like a door in consisting of the entity proper and some brushes which it owns, which constitute the visible shape of the button. Like doors, a func_button also has an angle-field, which specifies how the button moves when it's activated, 0=default being Eastward movement, other angles being degrees counterclockwize from Eastward, -1 up and -2 down (this last one is often used for buttons on the floor that you activate by stepping on them).
So a thing to do first would be to add a func_button to your map, with some angle field. Set things up so that you can watch what the door does when you press the button (tho it won't do anything yet). Now start the map, and walk up to the button. It should go `clunk', move in the appointed direction, and return after about three seconds. This illustates one of the differences between buttons and doors, which is that buttons always make a noise (like doors, they have a soundtype field, but with fewer and different values, listed on the reference page for buttons). But there is also a similarity, buttons also have a wait-field to specify the time before the button pops back, with a default of 3 and -1 meaning `never return'.
Now return to editing, and add (or fill in, if your editor has already provided it) a target field for the button, giving it a value such as "door" (leave out the quotes). Then add to the func_door a targetname field that also has "door" as it's value. Now the button `targets' the door. So play the map again, and go up to the button so that it clunks. When the button is finished travelling its direction of motion, the door should then start moving in its direction of motion (making an appropriate noise, if you've given it a soundtype-value). You might at this point notice a difference between the button and the door, which is that the button moves at a constant speed, while the door accelarates (this can be changed with a spawnflag, see the reference page for doors). Now go up to the door and push yourself against it, you'll notice that nothing happens. Only pushing the button again will make the door open again.
Another field that is useful for triggered doors is message. Its value is a number, the message number of a message which gets displayed if you approach a triggered door (or one that opens from being hit or shot) that hasn't been opened yet. A useful value for message is 267, the message number for "This door opens elsewhere". So add a message field to your door and check it out. Notice that once the door has opened once, the message doesn't get displayed again, so triggered doors with a message-value should probably have a wait-value of -1.
There are also several spawnflags that are useful for triggered doors. The spawnflag field is a number that codes a variety of entity properties in an on-off manner. Each property is represented by a power of two, and the first eight of these (1, 2, 4, 8, 16, 32, 64, 128) are used to code behavioral properties of entities, while the rest indicate what difficulty levels and game types the entity appears in. Your map editor ought to have nice little checkboxes that you can tick or not tick to set the spawnflag bits, but sometimes things are messed up or left out, in which you can calculate the spawnflag value by adding up the numbers for the properties you want. I.e. to set the first and third spawnflags to 1 (yes) and the rest to zero (no), set the spawnflag-value to 5. This can be tedious, (especially when combined with settings for difficulty levels, so if your map-editor doesn't make it easy to revise spawnflag support for entities, it might be worth considering using a different one(QuArK and Qoole are both OK in this regard).
For func_door entities, the first possibly useful spawnflag is 1 - STARTOPEN. If this is set, the door will start out in its open position, and close when it's triggered. This is only useful for triggered doors. The other useful spawnflag is 8 - TOGGLE, which means that the door won't close on its own (regardless of its wait-value, but must be triggered again (not necessarily by the same entity) in order to close (then the next triggering opens it, and so on).
There are many things other than buttons that can trigger doors. In fact one way or another, almost anything can, including the opening of other doors. For example, a door can itself have a target-value, which is triggered when the door is finished opening, and in the Mission Pack, a closetarget-value, which is triggered when the door closes.
A more plausible example would be an artifact such as a Krater of Might
art_manaboost). Give it a target-value of "door", and the
door will be opened when you acquire the item (thereby perhaps revealing
some monsters for you to use the mana on). Go
here for more on targetting.
Puzzle Doors
Reference Pages: Doors,
Puzzle Pieces.
Most of the remaining fields and spawnflags have to do with doors whose use involve `puzzle pieces' (keys, in Quake terminology). If you've had enough of sliding doors for now you could go straight on to Rotating Doors, and look at this later.
Puzzle pieces are basically just things you have to have in order to make something happen, they involve the same fields and spawnflags for all the entities that use them. A puzzle_piece entity doesn't own brushes, but instead has a model (the puzzle-piece models are in the models/puzzle subdirectory of the .pak file or game directory). A puzzle_piece needs two fields. One is puzzle_id, which is just the name of its model. Here's a list of the ones that appear in the game (but it's not too hard to make new ones). The other is netname, which is the name that is displayed when the puzzle pieces is picked up. You need it because what is actually displayed is `You possess the ' followed by the netname-value, which looks pretty lame if there isn't one. If you look at the puzzle_piece reference page, you'll see that there's a bit more to puzzle pieces, but actually not a whole lot more.
So put a puzzle_piece, perhaps the Tailor's key (puzzle_id of "takey") into your map, and put "Tailor's Key" (without the quotes) into the netname field. Then when you play the map, you should see the puzzle piece floating there, and when you acquire it you should see the message "You possess the Tailor's Key", and when you hit the <TAB> key, a graphic of a key should be visible in the collection.
So now back to the door. There are five fields and two spawnflags that are relevant. The first four fields can be used to specify a puzzle piece that the player must have in order to open the door, and are puzzle_piece1 thru puzzle_piece4. Any of these can be used, or several together if there is more than one puzzle_piece required to open the door (not plausible for a door, but one could imagine a potion requiring several ingredients; each would be a different puzzle_piece). The values of these fields on the door are just the puzzle_id-values of the required puzzle_piece (which are themselves just the names of the models, so it's not too hard to make new puzzle-pieces).
So now remove the targetname field from the door, and replace it with a puzzle_piece1 field with value of "takey". Now the door won't open if you approach it without the piece, but will if you have the piece. But also, when you don't have the piece, you won't get any explanation of why the door isn't opening. To get one, you need to add a no_puzzle_msg field, whose value is the message # of the message (the line-number of the message in the strings.txt file) we want to be displayed when the player approaches the door without the required puzzle-pieces (I don't know why the programmers didn't just use the `message' field for this purpose, but they didn't). Puzzle-doors have a further property, once opened, they stay open, regardless of their wait-field.
This leaves the spawnflags, which are 64 - REMOVE_PP, and 128 - NO_PP. If the REMOVE_PP spawnflag is set, the puzzle-piece is taken away from the player when the door opens (so you could for example confront a player with an irrevocable choice by having two REMOVE_PP puzzle-doors with the same puzzle_piece1 fields). The second, NO_PP, causes the door not to open when the player has the piece(s), and reverses the display of the no_puzzle_msg message. Something you could do with this is have a (new) `wizard's cowl' piece, possession of which would block off easy access to the next area of the map, so that the player holding the piece would have to solve harder puzzles to gain access by other paths.
There is one more feature of ordinary doors that we haven't covered yet, `linking' but this is more useful for rotating doors, so we'll deal with it in the next section.
Rotating doors are made with the func_door_rotating entity, which has a lot in common with the func_door entity, but is a bit more complicated.
A rotating door needs two things that an ordinary door doesn't have, an `origin' and a flags field. The origin tells the door what axis to rotate around, and it can be specified in two ways, either as a triple of numbers in an origin field, or as an `origin brush', which is a brush that is owned by the door, textured with the `origin texture', which is a mostly white texture with ORIGIN written on it lots of times in red letters. The flags field tells the door how many degrees (counterclockwise) to swing when it opens.
If flags is omitted, the door will do nothing (it thinks it's supposed to rotate 0 degrees), while if the origin isn't specified, it will move in some sort of bizarre and unsatisfactory manner. Rotating doors have most of the fields and spawnflags of ordinary ones but there are two interesting differences. First, rotating doors can take a frags2 field that causes damage to a player that only touches the door, regardless of what it's doing. Second, the angle field has nothing to do with how the door moves, but rotates the orientation of its brushes in the horizontal plane, which can be useful for making trapdoors at odd angles (not a topic I'm going to cover in this tutorial, but maybe you can figure it out from the stuff on the reference page). Note also that the puzzle-piece spawnflags have different numbers, althtough the REMOVE_PP and NO_PP functions are preserved.
The last topic I'll mention in this tutorial is `linking'. If two doors (rotating or sliding) touch, they are by default `linked', which means that if one moves, so does the other. This behavior isn't always desired, so there's a DOOR_DONT_LINK spawnflag to turn it off, and when it is desired, one usually wants the doors to move in opposite directions, so there's a REVERSE spawnflag which offsets the movement angles by 180 degrees. So now you can experiment with these for both rotating and sliding doors, if you want to.