Vlatitude: Scripting Tutorial Part 4 - the Seesaw of Death Last edited 2 years ago2022-09-29 07:56:32 UTC

Download example

The first thing I'd like to say is that if you haven't read our previous three scripted sequence tutorials, 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.

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 exercise 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.