This article was recovered from an archive and needs to be reviewed
The formatting may be incorrect as it was automatically converted to WikiCode from HTML, it needs to be revised and reformatted.The first thing I'd like to say is that if you haven't read our previous three scripted sequence
tutorials (Link: tutorials.php), you should do so before attempting this one. In order to understand what this tutorial talks about, you absolutely need to play the example map first. Here it is:
So you played it. Pretty cool, huh? You might think that this is a difficult sequence to set up, but it's really quite simple. The reason it's so easy actually comes from Half-Life's limitations. Half-Life has a pretty weak realism when it comes to physics in the environment, and the point of this excercise is to work with and against these limitations.
Let's start out with the basic scientist setup. First, we'll look at the scientist standing on the wooden platform. As you can see from the picture, he's actually a
scripted_sequence triggered by a
trigger_auto. This is not crucial, and I could in fact have the real
monster_scientist stand on the platform, but a
scripted_sequence allows some more control over the
monster_scientist, and is less prone to bugs.
The scientist is standing on a rectangular
func_breakable platform whose name is
board. This
board is triggered by
scripted_sentence 1, which in turn is triggered by a large
trigger_once that the player absolutely has to walk through (not shown). So when the
scripted_sentence 1 makes the scientist on top of the crate talk, the supporting board breaks, with a set delay of 3. When this board breaks, the game's physics simulate gravity, and the scientist falls to the floor.
More advanced readers might argue that perhaps a
trigger_monsterjump would be a better tool to use in order to get the scientist off that crate. In theory, yes: the scientist would jump off the crate in a more realistic fashion, and we could just remove that strange-looking board. However, this does not work in practice. I've tried it, and the scientist goes sliding along the seesaw after he jumps, until he stands face to face with the other scientist, the seesaw remaining unmoved. I tried it in many variations, and it still didn't work. Close, but no cigar.
Here, we run into our first problem: getting the levered board to move in unison with the falling scientist. To make it realistic, I put a
trigger_once brush in the falling scientist's way. This
trigger_once targets a
multi_manager named
event_manager. Here are the values for mister
event_manager
- targetname=event_manager
- seesaw=0 (time delay of course)
- spring=0
- scream=.2
So to summarize, the multi_manager is launched by the falling scientist, it then immediately rotates the lever (which is a
func_rotating), and launches the second scientist. Let's examine that last part. As you can see, the seesaw(3) is constructed out of 3 simple brushes: a plank, a cylindrical base, and an
origin brush. These three were grouped, and made into a
func_rotating. The values were pretty tricky to get just right, and you can see them for yourself in the example map. Now in a game with a realistic physics engine, the plank would toss the victim up when the first scientist dropped on the opposite end. But since we've had to fool the plank into pivoting in the first place, we will employ the same sneaky methods to preserve functionality. The victim(1) is actually standing on a func_train(2) platform. If you look closely, you can see that his feet are not exactly on the plank. Our
multi_manager triggers this
func_train, whose name is
spring. Its first
path_corner is inside the plank and the entities in the screenshot, but if you've read the
func_train tutorial, you know that it must be present there, or else this catapulting wouldn't work. This
func_train goes straight up to the ceiling, where I have my nice fan, spinning happily (note the origin brush on the fan). The
multi_manager also triggers a
scripted_sentence, which entails screams of horror from the flying scientist.
If this map shows anything, it's that the designer has to work around the engine's limitations. Therefore, it should be apparent that the fan, even with massive damage set, will not annihilate the scientist. Unassisted, it will at best kill him, but his corpse will drop to the ground. This is unacceptable, mainly because
we want gibs. Also, sometimes an unassisted fan will spin the scientist around 1/4 of a turn, and let him fall to the ground unharmed! So, to fix these problems, our flying scientist will pass through yet another
trigger_once (1 in screenshot). This
trigger_once has a target of
shit_hits_fan. It triggers 2 things with that name: a
gibshooter (2) (it pretty much just shoots a healthy amount of gibs), and an
ambient_generic (4) that plays the gibbed sound. Another very important point, is that the
trigger_once has an attribute
Kill Target set to sci2 (the victim's name). This means that when the scientist's head touches the
trigger_once (1), he vanishes (because of kill target), makes a dying sound, and gibs rain upon the unfortunate bystanders' heads. To clarify the screenshot even farther, (3) is the final
path_corner for the
func_train, and (5) is the dreaded fan of death.
I have explained the vital workings of this sequence, so now you have enough knowledge to adjust it to your needs and make it better. You could make it look more realistic by adjusting the scientists' trajectory, making preceding sequences, or changing the
func_train's shape. The most important lesson is that sometimes we have to devise ways to make illusions that look realistic and believable.
This article was originally published on
69th Vlatitude.
TWHL only archives articles from defunct websites. For more information on TWHL's archiving efforts, please visit the
TWHL Archiving Project page.
