Escalator

Tutorial collection, comprehensive listings on main site.

Escalator

Postby Tutorial on Mon May 15, 2006 5:32 pm

category
General Half-Life 2/Entities

description
Create a moving stairway.

keywords
escalator, moving, stairs, stairway.

This tutorial will teach you how to create a working escalator, the "moving staircase" often seen in malls and airports. It's a relatively easy process--most of the actual brush and entity work is simple cloning. If it looks long, don't worry; it's just the way I write. I hate tutorials that don't give you enough information, so I have decided to be very descriptive and let you decide if you need all of the info or not. The only thing that is out of the ordinary is that you have to modify the FGD, which we will do first.

Step 1: Modify the FGD

If you mapped for Half-Life, you will probably remember a very common and useful entity called a func_train. We will need that entity to construct the escalator. It's still supported, but isn't in the current Half-Life 2 FGD, so we will have to put it there ourselves. Open the FGD file using Notepad (the default location is C:\Program Files\Valve\Steam\SteamApps\(user)\sourcesdk\bin\halflife2.fgd). You will see a long list of entities and their characteristic descriptions, keyvalues, and flags within Hammer. Scroll down to the bottom of the list and copy/paste the following text into halflife2.fgd:

Code: Select all
@SolidClass base(Targetname, Origin, RenderFields) = func_train
[
   spawnflags(flags) =
   [
      8 : "Non-solid" : 0
   ]
   texframeindex(integer) : "Initial Brush Frame Index" : : "Use this to set the initial frame of materials with multiple frames in the brush"
   target(target_destination) : "First path_corner"
   noise1(sound) : "Movement Sound" : : "The sound to play when the train moves."
   noise2(sound) : "Stop Sound" : : "The sound to play when the train stops moving."
   speed(float) : "Speed" : "50.000000" : "Speed at which the brush moves."
   volume(float) : "Sound volume [0.0, 10.0]" : "0.000000"
   dmg(float) : "Crush Damage" : "0.000000"
   input Toggle(void) : "Toggle movement"
   input Start(void) : "Start movement"
   input Stop(void) : "Stop movement"
   input Use(void) : "Toggle movement - has a different functionality than Toggle"
]

There is a section of the FGD devoted to other entities of this class, but I prefer to add this new entry to the end. This way I know it was manually added and can easily remove it later if I wish. You can put it somewhere else within the FGD if you want. After you have put this new entry into the FGD, close the file and save it when prompted to do so. Now we can start the construction process.

Step 2: Construct the stairs (func_train)

Open the Hammer editor and create a new map. I advise doing it this way, rather than within an existing map, because soon we are going to have a lot of entities in a relatively small space--which can be confusing if the construction area is already filled with geometry and other entities. I would also advise turning off entity names (under the View tab) to reduce clutter while we build.

The first thing you will need to do before you begin is decide how tall your escalator needs to be to get from one level to the next. This determines how many steps your escalator will have. In my example, I have constructed an escalator that can raise the player 160 units--that is, 10 steps, which are each 16 units tall. How many steps you will need will vary, but keep in mind that anything more than 16 units will probably not only look strange, but maybe make it difficult for the player to walk up if he doesn't want to wait for the escalator to raise him by itself. Also, smaller step sizes will require more steps to reach the top level, which means your escalator will get longer and longer as step size decreases.

Our first brush will be one of the steps. Create a brush that is 16 units wide, 48 units long, and 16 units high. Next we need to create an origin brush, which will tell the func_train how to orient itself as it moves. Go into the textures and type origin into the filter. A green texture with the word "ORIGIN" should appear. Select this texture and create another brush, this time 4 units wide, 52 units long, and 4 units high. The brush must be completely covered in the ORIGIN texture to work properly! Take this brush and skewer it directly through the center of the step we created. Make sure it is exactly through the center, or there will be problems later.

Step 2, Figure 1: Step alone, orgin brush alone, step and origin combined

Image

Next, we will turn our step-and-skewer into a func_train. Select both brushes at once and click toEntity. In the Class: box, select func_train. The only keyvalues/flags you need at this point is the Speed, which should be set to 16. For a basic escalator that will start on and will not be able to be turned off, your steps don't need names. You don't want to set a movement sound, either, because if you do this for all of them you will have quite a racket--better to create an ambient_generic to handle the sounds later on.

Now that we have one step, we can make the rest. Clone this one func_train into as many steps as you will need, plus one extra. You'll see why in a bit. (If you've never used the clone tool, it's easy. Just hold shift while you drag the original object to where you want the next one to be, and it will create a copy automatically.) Place the steps so that they are sitting like a staircaise. Make sure there aren't any gaps between them, or it will ruin our illusion. Set the extra step you created off to the side for now.

Step 2, Figure 2: A series of steps and one extra

Image

Step 3: Create the path of movement

A func_train uses path_corner entities to not only tell it where to go, but where to start off in the world. We need to create some places for our stairs to start. We could have done this part first, but it's easier to visualize where you need to put the path_corners if you can already see the steps. First, create a starting point for our first step. Select the point entity tool, then in the Objects: box, select path_corner. Create a path_corner directly in the center of the first step of our staircase. In the Object Properties, give it a name of step1. This is the only keyvalue you need to worry about right now. Using the clone method, create starting points for all of your other steps AND four extra path_corners, placed like so:

Step 3, Figure 1: Path_corners alone, path_corners with their func_trains

Image

These extra path_corners, along with the extra func_train we created earlier, will be vital to pulling off our illusion. Take note that in the example there are fourteen in all! Ten for the steps themselves, one to the right of the top step, and three down below the first two steps. Also note that to place step13 correctly, you will have to drop your grid size down to 1 and move it from there. Make sure that the last path_corner in your set has step1 set as its next stop target. If you cloned them correctly, all of the others should have this part of their Object Properties filled out automatically.

Step 4: Tell the steps where to start

So, we have func_trains and path_corners, but we have to tell each stair where it will begin. Select the first stair in your escalator and under the Object Property keyvalue First path_corner, select step1 from the drop-down list and apply your changes. Do this for each of the other step, matching up each one with where it starts in the world--the fourth step will begin at path_corner step4, the tenth one at step10, and so on. In the example, the mysterious extra step will have a starting point of step13, which was the one path_corner we had to drop the grid size all the way down to place. Now that you know where the extra step will start, you can move it there if you want, for visualization purposes--it won't matter in-game where the func_trains begin in the world, because when the map spawns they will immediately teleport to their first path_corner.

Step 5: Create the illusion

This is the fun part, where we get to pull the wool over the eyes of the player. When we are finished, they will have no idea that we have constructed a fully-functioning escalator with only the number of steps that can be seen at any given time, plus one. If you were to place your escalator in a map right now and run it, you would see your stairs gently moving along the path we created, everything looking good until--that's right, until the steps run out! After all, there are relatively few and it takes a while for the first step to cycle around to its start point again. By tweaking some settings, we are about to change all of that.

The first thing that needs to be done is that the path_corner right before where our infamous extra step begins needs to have the flag Teleport to THIS path_corner checked. This will make the stairs cycle around to the start point faster than would otherwise be possible. Now if you ran the map, you would see a continuous flow of steps that move normally on the front side, but speed around the back. Our extra path_corners (the ones that are not part of the series of starting points) now serve a useful purpose. At the top, they allow the stairs to move into a position where they can teleport to the bottom unseen. At the bottom, they slow down the stairs before they go through the cycle again so that you can't see them teleporting into place. Also, the purpose of our extra step now makes sense. It fills in a gap while the top step moves into place to be teleported back around to the bottom.

Unfortunately, you would also notice that as the steps go around, some of them get little gaps between them. This is because the teleport movement screws up the timing of the steps a little bit. This is where we will fix that. First, we must edit the Object Properties of our extra step. It needs to have a starting speed of 17, instead of 16 like the others. This will fill in one of the gaps, since it will move a little more quickly to find its place behind the first step as it moves up. However, to keep it from eventually overtaking all of the other stairs in the escalator, we have to edit the properties of the next path_corner (the one right before the first step's starting point) to have a New Train Speed of 16. This makes the extra step return to a normal speed after it intially hurries to get into place.

The next thing we have to do is fill in the gap that emerges behind the extra step, the one from the top step getting screwed up as it teleports. To do this, we must set the top step's starting speed to 18. We also have to change its starting point to reflect a New Train Speed of 18. This will make our top step, as well as every step that passes through this path_corner, temporarily speed up to 18 units/second as it prepares to go to the teleportation area. The increase in speed will be imperceptible to the player, unlike a big gap between the steps, which would be easy to notice. Now if you run the map, assuming you placed everything correctly, you would see the steps smoothly cycling, with no gaps. Good job! We're almost done.

Step 6: Complete the illusion

These will be the final touches. First of all, a set of moving stairs alone doth not an escalator make. The steps need a texture, obviously. You will probably want some detail brushes that will make it more realistic-looking, like some guards on the sides to keep people from falling off. In the example map, all of the detail brushes are made of glass so that you can see what's going on "behind the scenes". In real life, it's very common for escalators to have glass side-guards like that.

You will also need to make sure that the player can't see where the steps come from or where they go. At the bottom, this is easy. Just take the whole escalator (and all the entities!) and place it so that the very first step starts one unit above the floor. The extra step will start almost completely in the floor, but that's not going to hurt the operation of the escalator at all. You can make the bottom of the first step start flush with the floor, but this will produce texture flickering in the steps that cycle up through the floor.

At the top of the escalator, you need a brush that will make a landing, somewhere for the steps to move that will cover up the teleportation. This is also easy. Just create a brush that starts off flush with the back side of the top step and is at least one unit taller than it. The steps will slide into place and nobody will know where they go.

And, last but not least, a sound. Place an ambient_generic somewhere near the escalator and give it a pleasant sound, like one of the elevator noises that gives the impression of smooth, steady operation. Make sure it starts on.

Step 6, Figure 1: Completed escalator with side-guard removed to show inner workings

Image

Other things you can do

Besides looking cool and actually working, this escalator starts off pretty plain. Sound and detail brushes complete the illusion, but there is always more you can do.

If you want, you can create moving hand-rails like they have on real escalators by turning a brush into a func_conveyor and setting it to move at the same speed that the steps do. Of course, if you are using the regular Half-Life 2 textures, you will have to create one or turn an existing one into a scrolling version--otherwise your conveyor will still move things, but it won't look like it's going anywhere.

With a little tweaking, you could make an escalator that runs the other way, as they often have the up and down versions near one another in real life.

You could even set it up so that the escalator can turn on and off. All you would need to do give all of the steps the same name, and set up a button or switch with the desired settings and and Output of OnPresed, (escalator name), and Toggle.

A warning

Things can block this escalator! Occasionally something can get wedged in it somehow and will disrupt the interval of the steps and create gaps, which can only be fixed by restarting. It shouldn't happen, as long as at the top of the escalator the player has room to move away (not closed in by a low ceiling or obstacle). But if it does, you can always set the func_trains to have crush damage so that if the player or objects get caught they will be gibbed immediately. For single player, this is probably a bad idea--if I were rolling along it would annoy me to suddenly have to reload my last save because Gordon got his big toe caught in "some stupid mapper's faincy movin' staircase". But for escalators set up in multiplayer maps, it's probably important that getting stuck in it kills you right away to avoid the escalator being screwed up for everyone else in the game for the rest of the round. It's possible that you could also construct the steps so that they overlap slightly, which might prevent things from getting caught in them.

Also, I haven't tested this escalator with different-sized steps or different numbers of steps, so don't be surprised if you have to do some manual tweaking of settings in order to get everything to work just right. However, all of the basic principles should be the same no matter how tall your escalator or what size your steps are.

tharawdeal
- Don't send PM's to this user -
Tutorial
Not A Real User
 
Joined: Sun Mar 06, 2005 11:00 pm

Postby Sauce on Fri May 19, 2006 7:36 am

I thought this was how you would do it, but i dind't want to waste my time trying it... anyways, why edit the fgd? HL2 has func_tracktrain which does the exact same thing.
Image
Blink wrote:Do you watch porn and decide you don't need to have sex because you've seen the ending? :-D

zombie@computer wrote:what retarded countries measure in stones anyway?
or feet? or inches? Your dick is a lot longer in cms
User avatar
Sauce
Senior Member
Senior Member
 
Joined: Sat Nov 26, 2005 4:36 am
Location: Australia

Postby tharawdeal on Sat May 20, 2006 5:54 am

There was a reason, but I don't remember what it was. I started with func_tracktrains and switched, maybe because it was easier to just cut and paste into the .fgd than to have to screw around with all of the keyvalues and flags in order to get things working how they should. It was also very late at night, so I might have done it without really needing to.
tharawdeal
Member
Member
 
Joined: Thu May 11, 2006 12:01 pm

Postby Sauce on Tue May 23, 2006 10:50 am

compiled the other day and hl2 crashed on load. That why?
Image
Blink wrote:Do you watch porn and decide you don't need to have sex because you've seen the ending? :-D

zombie@computer wrote:what retarded countries measure in stones anyway?
or feet? or inches? Your dick is a lot longer in cms
User avatar
Sauce
Senior Member
Senior Member
 
Joined: Sat Nov 26, 2005 4:36 am
Location: Australia

Postby tharawdeal on Tue May 30, 2006 6:13 am

No, it had something to do with the way the steps moved, but I don't remember what. Either something to do with the teleportation aspect or something to do with the orientation when traveling, I don't really recall.
tharawdeal
Member
Member
 
Joined: Thu May 11, 2006 12:01 pm

Postby Alminie on Tue May 30, 2006 7:22 am

tharawdeal wrote:No, it had something to do with the way the steps moved, but I don't remember what. Either something to do with the teleportation aspect or something to do with the orientation when traveling, I don't really recall.

it can't be the orientation, inless you didn't check off "Fixed Orientation"
in the Func_tracktrain.
Image
User avatar
Alminie
Sir Post-a-lot
Sir Post-a-lot
 
Joined: Mon Dec 19, 2005 3:55 am

Postby tharawdeal on Wed May 31, 2006 2:04 am

I don't know. It was late, I was tired. I just posted the tut for what worked for me... If you guys can find ways to make it work without having to modify the .fgd, that's cool--I was probably just too loopy to realize what was going on. Let it die, dammit! ;)
tharawdeal
Member
Member
 
Joined: Thu May 11, 2006 12:01 pm

Postby devil_dog on Fri Nov 03, 2006 5:01 am

I'm trying to make this work for CS:S and having a hell of a time.

Some of the properties are named different, but I was able to figure that part out. The issue is the timing of the steps and gaps that happen. When mine first starts, there is single step gap followed by four steps then another single step gap. Then eight steps later there is a one unit gap, barely noticable, but still there.

I've read this tutorial backwards and forwards. I've revisited the issue many times and various days. I can't figure this crap out.

I really want one of these in my map. Can anyone help? I can provide a test map file if interested.

dd
dd
devil_dog
Regular
Regular
 
Joined: Wed Nov 23, 2005 1:17 am

Postby AnusMcBain on Thu Nov 23, 2006 1:18 am

Is it possible to crank up the speed of the brush movement, to fling / shoot the player in a certain direction?
Just a thought anyway.
A solider without a body, isn't much of a solider at all.
AnusMcBain
Dumpling
Dumpling
 
Joined: Tue Nov 21, 2006 11:46 pm
Location: Brisbane, Australia

Postby devil_dog on Thu Nov 23, 2006 1:40 am

Tried that. He suggests this in the tutorial, but there are some pieces or details missing in the tutorial because I get a bit lost sometimes.

dd
dd
devil_dog
Regular
Regular
 
Joined: Wed Nov 23, 2005 1:17 am

Re: Escalator

Postby Mage_ofOld on Sat Aug 09, 2008 10:26 am

I think to prevent problems you should put a clip brush over the steps and add a push entity. Making the steps not solid could also solve spacing problems.
Mage_ofOld
Member
Member
 
Joined: Sun Feb 17, 2008 10:27 am

Return to Tutorials

Who is online

Users browsing this forum: No registered users