SiN Doors part I - func_door by BlindTypist
|
1. Introduction
|
There have been many questions by level designers in regard to doors. It can get confusing trying to create a door to your specific needs when there are three different door entities, with at least 16 Key/Value pairs and 8 SpawnFlags each. But the fact is, doors are a important part of level designing, so I wrote this tutorial to "hopefully" simplify the task and help you gather an understanding.
Throughout the tutorial I try to maintain a consistent terminology to reduce the chance of confusion. This is often difficult to do when you have to explain things like a "key Key/Value pair". So I provide a few images to show you exactly what I am talking about.
Part I of this tutorial focuses soley on the func_door entity, and it provides a detailed explanation of the SpawnFlags and Key/Value pairs common with all the door entities in Sin. Gaining a strong understanding of these common elements will help you better understand func_rotatingdoor and func_scriptdoor. So even if you are not interested in making a func_door, this is the basic fundamentals of ALL three door types.
Of course, I'm assuming that you are familiar with the basics of map editing with SinEd: making brushes, texturing them, using surf inspector and that you at least know how to make a basic room. It isn't important that you know how to create an entity and change it's attributes since I will show you how to achieve this.
Also, I'm assuming you have SinEd installed and running plus a text editor for your script (which will be used in Part II). Any text editor will do of course but I highly recommend using UltraEdit32 and Eutectics custom Uedit wordfile for command coloring. This is really useful to help you avoid typos and for debugging.
|
2. First Things First
|
Before we start, I would like to point out the SpawnFlags, Key/Value pairs and script commands that do not work. That way, we can get them out of the way and forget about them. There isn't anything more frustrating than trying to get something to work, only to find out an hour later it isn't even supported.
Don't worry if you don't know what a SpawnFlag, Key/Value pair or script command is yet. I'll explain them in a few minutes.
SpawnFlags- START_OPEN
START_OPEN, and the flag right below it, x, don't do anything. The x flag actually doesn't work on ANY entity because it's not really a flag, but a placeholder.
Key/Value pair- health
Depending on which version CPP file you have, there may or may not be a reference to a health Key/Value pair for func_door.
Script Commands- joinTeam and quitTeam
The script language contains two defunct commands, joinTeam and quitTeam.
The new CPP is very thorough about making a note of these, but I felt the need to point these out so they are not overlooked.
|
2. Getting Started
|
Okay, now we can get down to business. Create a room using the methods used in the basic room tutorial, except increase the dimensions to 512 x 384 units and 192 units high. Add in a light entity and an info_player_start entity.
Instead of using a single room, I joined two different sized rooms to make it easier to visualize where the doorway is going to be in the XY View. It's not necessary for you to duplicate it exactly for this tutorial. If you feel more comfortable splitting a single room, that's up to you.
|
In the middle of the room, build a wall about 24 units thick that extends wall-to-wall. This needs to accomodate a doorway big enough for a LARGE 256 x 128 door . You can use CSG subtraction to create the doorway, or draw three brushes and align them manually.
|
Now we will add the classic doortype, the sliding door. This is the ONLY style of door that func_door can create, but it has many customizable attributes. There are at least three ways to make an entity, but we will focus on the two easiest:
|
Method 1
Right click in the 2D XY view window and a menu will pop up. Select func > door from the menu, and a func_door entity will appear. Position and resize the door (if necessary) so that it fills up the doorway.
Method 2
Create a brush to fill up the doorway. While your brush is still selected (make sure it is the only brush selected), right click in the XY view window. Select func > door from the menu and your brush will change into a func_door entity.
|
Your door brush should now be notated in the XY view, with the func_door classname. Reduce the thickness of your door to 8 units and add any texture you like.
You already have a fully functional door, but there are a few things you should get into the habit of checking to ensure proper operation. While your new func_door is selected, press N to bring up the Entity window. This is where we can change the attributes of ANY entity.
|
The most readily noticable attributes are the SpawnFlags (highlighted in red). They only have two states, ON or OFF, like a light switch. All SpawnFlags are OFF by default. They are turned ON by checking the box.
Another type of attribute is the Key/Value pair (highlighted in green). The Key/Value pairs can carry a number, filename or word(s) as their value. Because of this, they are a far more flexible than the SpawnFlags. Right now, the only Key/Value pair is classname func_door.
|
angle is the most important Key/Value pair for any door type. In the context of a func_door, this is not really an angle, but rather the direction the door will slide open. This value can be changed by clicking one of the angle buttons (right), or entering text into the field of a Key/Value pair.
|
To make it easy, we will just click a button. First we need to know which direction the door needs to move. We do this by comparing the door position in the XY View with the angle buttons. In the exploded view on the right, the blue arrows show which way the door will slide open if the corresponding button is clicked.
|
In the XY View to the left, the acceptable angle would be 90 or 270. Click the 270 button to set the angle. Look at your door in the XY View and you'll notice a little arrow in your func_door. That is the direction the door will slide. In the example, I exagerated the arrow a little (okay, ALOT) and highlighted it blue so you can see it.
The default angle is 0, and it doesn't show an arrow in the XY View. An angle of 0 would have caused our door to slide in the wrong direction.
It is a good habit to ALWAYS check the angle key when you create a door entity.
|
NOW you have a completely functional sliding door. Compile your map and test it out. Walk up to your door and use it. When the door opens, pay attention to whether it completely disappears into the wall. It doesn't; there is a small 8 unit lip of the door exposed. That's normal.
If you are in the path of the door it won't close, so step away from the door. Watch how long it takes to close on its own. It should take about 3 seconds.
|
3. Making Things A Little More Interesting
|
Let's go back to SinEd and make this door a little more interesting.
We have alot of SpawnFlags and Key/Value pairs at our disposal, so lets check a few of them out. There is a short definition of each of these in the CPP, but I would like to expand on them a bit.
Key/Value pairs
targetname: no default
This is the unique name you can give your entity, so it can be controlled by a script command or triggerable event. In order to operate this door from a script or triggerable event, this key MUST be set.
time: default 1
This controls how fast or slow the door moves. Since the value is measured in seconds, this means that no matter how big the door is or how far it has to move, it will complete the operation in one second (if the Value is 1). With a very large door like ours, this is pretty fast. Setting this key to 2 will open at double speed while 0.5 will open at half speed.
speed: default 100
This key performs the same function as time, but in a different way. The amount of time it takes for this door to open depends on the length of the door. So a larger door takes longer to open than a small door, even though they have the same speed.
Setting this key to 200 will open at double speed while 50 will open at half speed. If this Key/Value pair is set, it will override the time Key/Value pair, so it serves no purpose to use both.
wait: default 3
This tells the door how long to wait before closing by itself. Its value is measured in seconds. If the value is set to -1, the door will never close on its own.
lip: default 8
Remember that little lip that was still visible when the door was fully open? That's what this is. It's measured in units. I usually prefer to leave it at it's default setting. The door just doesn't look right if you try to eliminate the lip by reducing it to 0, IMO.
dmg: default 0
This is the amount of damage to inflict on an actor that is blocking the door.
message: no default
This displays a message when the door is used. It doesn't "do" anything, but can be used to supply the player with additional information. It only works when opening a door, not closing it.
There are more Key/Value pairs, but let's experiment with those before we tackle the rest of them.
|
Editing Key/Value Pairs
|
With your func_door entity selected, Press N to bring up the Entity window. To change a Key/Value pair, enter text into the appropriate field. We'll start with the Key field by entering Speed and pressing enter.
* NOTE- The Keys are case sensitive, so targetname is NOT the same as TargetName.
|
The cursor will move down to the next field in Value. Type in 50 and press enter. You just assigned a new value to the speed key! This will slow the door down to simulate a large heavy door.
|
Now edit the the dmg and message Key/Value pairs the same way:
dmg = 1000
message = Caution: misuse of this door \n can result in injury \n or DEATH
|
* NOTE - I highlighted the peculiar \n in blue to point out special considerations when formatting a message. I used this pair of characters to force the text to the next line, like a carriage return.
The game can display about 38 characters per line at 320 x 240 resolution (the lowest res). If the message exceeds this limit, the text becomes a jumbled mess, unless \n is used. Of course at higher resolutions, you can have more characters per line, but it is better to accomodate the lowest resolution just to be safe.
|
SpawnFlags
Now we will look at all the Spawnflags that are specific to doors. We will ignore the seven flags on the far right (!Easy, !Med, !Hard, etc.) since they don't have any specific door functionality.
DOOR_DONT_LINK:
If two doors are touching, they automatically link together. In other words, they synchronize their opening and closing to operate as a unit. If this is checked, they work independently.
NOT_MONSTERS:
This prevents the door from being operated by a monster.
NOT_PLAYERS:
This prevents the door from being used by players.
TOGGLE:
The door remains open or closed until it is triggered by a player, monster or other triggerable event. Setting this flag and a wait Key/Value pair would be pointless, since a toggled door does not close by itself.
AUTO_OPEN:
This door will automatically open if an actor walks near it. The door doesn't have to be touched or used for this to work.
TARGETED:
This door can only be operated by a trigger or script command, which means the targetname must be set.
TOGGLE is the only SpawnFlag we need for our door right now, so check it. Compile your map and lets see what we accomplished.
|
Walk up to the door and use it. Notice how the message and speed Key/Value pairs affect the door. It won't close by itself because we set the TOGGLE Flag, so use the door again to close it.
Open the door again. When the door is completely open, walk up to the lip and stand directly in the path of the door to block it. Close the door.
At first, the actor is pushed by the door, but it doesn't inflict any damage. When the actor can't be pushed any farther, he is crushed and instantly killed. The reason this happened is because the actor isn't enough to block a moving door, so he is pushed instead. Only when the actor can't be pushed any farther will the dmg Key/Value pair take effect.
|
4. That's interesting, but can the door have cool sounds?
|
Okay, maiming the player is only slightly amusing. We still have a few more Key/Value pairs to cover, so lets move on to our next experiment.
I'm sure you noticed the sounds the door makes? It doesn't sound much like a large metal door, does it? That's because they are the default sounds of a wooden door. But we can fix this by changing a few more Key/Value pairs. But first lets get an idea of where the sounds come from.
The default wooden door sounds are precached in a file called global0.scr in the Sin\Base\Global folder. We don't have to go as far as writing our own script, nor do we have to parse through the global0.scr to find the alias for a particular sound. We can set a Key/Value pair to play any WAV we want, as long as we know the path and file name. You can use any Sin WAV file you want, or you can create your own WAV. Creating your own WAV is beyond the scope of this tutorial.
|
MORE Key/Value pairs - sounds
sound_move:
The sound when the door is opening or closing.
sound_stop:
The sound when the door stops moving. This sound is played both when it opens and closes.
sound_locked:
The sound when the door is locked and the player attempts to use it. A door can be locked through a script or by setting the key Key/Value pair, which we will discuss later.
sound_message:
The sound played when a message displays. the message Key/Value pair MUST contain a Value for sound_message to work. sound_message takes priority over sound_move. In other words, when the door is opened, you will hear sound_message, but NOT sound_move. When the door is closed, sound_move will be played as normal.
Edit the following Key/Value pairs just like you did before:
sound_move = environment/doors/airlock/openlk3.wav
sound_stop = environment/doors/airlock/close2.wav
Both of these sounds can found in the Sin\base\sound\environment\doors\airlock folder.
* NOTE - The game assumes that the sound path starts from Sin\base\sound. Also, notice how SinEd requires the use of "/" instead of the standard "\" to define a path.
Change the Flags
UN-check the TOGGLE Flag.
CHECK the AUTO_OPEN Flag.
Adding (a false sense of) security
|
Now we are going to add the classic element of locking and unlocking a door with a KeyCard. We can use any Inventory item, even cookies, as a security key. We're going to be boring and "normal" by using the BlueCard instead. I know, I know, you REALLY wanted to use the cookies to break into a high security building.
Creating a "keyed" door requires two steps: Creating the Inventory item and then assigning a key Key/Value pair. We'll start by creating the Inventory item first, and placing somewhere on the floor as depicted in the image on the left.
|
Creating a KeyCard
|
To create an Inventory item, right click in the XY View and a menu will pop up. Select Inventory > BlueCard and the Inventory item will appear in your map. Move the card off to the side so the player won't pick it up immediately, and make sure the it isn't stuck in a wall or submerged in the floor. Keep the KeyCard on the same side of the door as the info_start, otherwise you'll lock yourself out and won't be able to get the key.
|
the key Key/Value pair
|
Once we assign a key Key/Value pair, the door will automatically lock when the level starts.
Just as you edited the previous Key/Value pairs, edit key to:
key = BlueCard.
|
The entity is actually named Inventory_BlueCard, but it is truncated to BlueCard when entering it as a Key/Value pair. This is typical creating a key from most inventory items: eliminate Inventory_ from the name. The CPP file contains additional information on the few items that don't follow this rule.
|
Save your map, compile it and check out the new and improved door.
Walk toward the door WITHOUT the BlueCard and a message will appear with an Inventory_BlueCard icon. Approach the door WITH the BlueCard and it will open automatically, because you set the AUTO_OPEN Flag.
|
So that's pretty much the basics for doors. We didn't cover a few items like linked doors, targeted doors. Alpha Key/Value pair and such. They WILL be covered in the next tutorial, though. Now that you have a solid understanding, we can do some REAL COOL stuff NEXT.
|
Part II
|