Vlatitude Archive: Trigger_camera Tutorial Last edited 5 years ago2019-04-25 02:41:04 UTC

Half-Life is a very stable game overall. There are no blatant bugs that just jump in your face anywhere in the game. However, there are some bugged areas that simply weren't in the game very much. Trigger_camera is the most bugged entity I have ever used, and one of the coolest also. This mixture sometimes gets very frustrating, but over time I was able to make sense of it, and now I don't have as many problems. I'm guessing that the reason that it's not very stable is that Valve only used it in a few places in the game, so they didn't have the need to fine-tune it. In this tutorial, I'll explain how to use trigger_camera to create breathtaking cinematic effects, and how to get around its bugs and shortcomings. I strongly suggest that you read the func_train, multi_manager, and teleporters tutorials before you read this one.

Let's start out with the usual question, "what does it do?" A trigger_camera is an entity that enables you to take the point of view of the player away from the 1st person perspective and control it like the level-designing emperor that you are. What does this mean? Well, using a rather grotesque analogy, you take the player's "eyes" and control them like you would a movie camera, moving them and pointing them anywhere. Pretty cool huh? Well it's not unless you know how to use it. Have you read the func_train tutorial yet? If not, go and read it. Otherwise, let's get to it!

Basic Use

Trigger_camera is a standalone entity, no brushes are involved here. Go ahead and put one in your level just so you can follow along, but you'll definitely be moving it around later on. Remember, this entity is the "eyes" of the player. Did you create it? Good, let's look at its properties. You should be able to tell from the attributes that this entity must be triggered in order to be activated, so give it a name. The target attribute is not like the target attribute in other entities, it does NOT trigger something with a name tag. Instead, the target should contain the name of the entity at which the camera will be looking. Here we get to our first bug: the target attribute will always work if the targeted entity is an info_target. It should also be able to look at any entity with a name attribute, but this isn't always the case. All the times I've tried it, it can look at named monsters, but some entities just aren't valid targets. Point-based entities are usually safer to use than brush-based. Some brush-based entities will work, func_train for example, but more on this in a bit. This is also important: if you put "player" without the quotes into the target field, the camera will be looking at the player. Now let's cover the rest of the attributes before we get into more technical stuff. Hold time is how long the camera will be active before returning the view to 1st person, and you will have to play around with this value to get it just right for your purpose. The path_corner (did you read the func_train tutorial yet?) is the first path_corner at which the camera will start. Yes, the camera is pretty much a func_train, and you can get it to move using the exact same idea. Therefore, you should already know what initial speed is, and I bet you can guess what acceleration attributes do. The flags are pretty self-explanatory also, and most of the time you will want to freeze your player so he doesn't go walking around and getting killed while the camera is viewing something in another room.

Controlling the Camera

Okay, first thing is camera movement. In the previous paragraph I said that it acts exactly as a func_train, so you can either keep it stationary (make only one path_corner and tag it to the path_corner attribute), or have it move the exact way you'd have a func_train move. One way to keep it stationary is to not enter anything in the path_corner attribute, but this will lead to bugs, so don't do it!

Now let's talk about targets for the camera. The easiest and the most surefire way is to make an info_target, name it, and have it be the cam's target. However, this can get boring, because the info_target will just sit in one position, and as an aspiring cameraperson, you demand control! A good techniue is making a monster be the cam's target. This is like having them be the lead actor in a movie, it gives that monster an aura of importance. Of course, this is best used in conjunction with scripted_sequences, but you already figured that out. What if you want to move the camera's viewpoint around without using a monster? This is where we get to the most versatile, and sometimes a little buggy feature: the invisible train! Eh? Didn't I say that you can get the camera to target most named entities? In order to have the camera's viewpoint move around, you need to create a func_train (why did you think I wanted you to read that tutorial?), and check the non-solid flag. Giving it the AAATRIGGER texture also helps. If this texturing method doesn't work, use the "blue" texture and set the Render FX to Solid 255. You already know how to control a func_train, so I won't talk about that. I will mention, however, that your trigger_camera and your func_train can follow the same set of path_corners. Hey, the path_corners are like Monica Lewinsky, anyone can use them!(ahem) [Editor's Note: Yes, I am an idiot] Just make sure that the func_train starts one path_corner or more ahead of the camera, and that the speeds correspond to the desired effect: if the func_train ends up behind your trigger_camera due to faulty speed settings, the camera will flip to look at the train. Sometimes though, this can be a pretty cool (although slightly nauseating) effect. Important Note: The func_train must have an origin brush as part of it. An origin brush is of course a brush that has the Origin texture on all sides. Group with this with your invisible train brush before making it a func_train, or else your camera won't target it correctly. This was pointed out by a very frustrated reader, thanks Adam! Just one more thing before I move on: you have probably already figured this out, but you will definitely need to use a multi_manager to control your cinematic sequence. There are a few entities being triggered involved already, and I'm about to introduce even more. If you haven't done so already, read Brian's multi_manager tutorial to familiarize yourself with this entity, because making a cinematic sequence without it is either impossible or a giant pain in the ass (neither of which should be in your level-designing experience).

A Big Ugly Bug, and How to Kill it Dead

Here we get to a pretty major complication with the trigger_camera. In order for the trigger_camera to work, the game engine has to be able to "see" from the camera to the player. For example, you can't press a func_button in one end of the level to activate a trigger_camera in another end unless the engine can see the player in a straight line from the cam. There are 3 common solutions to this problem, let's look at them.

The Wimps' Way Out

The most obvious solution is to place the trigger_camera and its trigger, along with the player in the same room. This should be fairly simple, but limiting. I mean you won't always want to point your camera at something in the same room as yourself, that's why I suggest my alternative solutions.

The Kinda-Easy Yet Good Way Out

Remember how I said that it's the engine that has to be able to see from the trigger_camera to the player? If you have read my other tutorials, you should know that the engine can see right through entities, such as func_wall. Therefore, if the player and the trigger_camera are in adjacent rooms, or not very far away, you can make a func_wall separate the two rooms. That way, the engine can see through your wall between the two points.

The Hard but Most Effective Way Out

The most foolproof solution to this problem is teleportation. You'd better have read Brian's teleporter tutorial, as well as his multi_manager tutorial because without them, you'll be lost like an Amish guy at E3. I mentioned earlier that you will pretty much always be using a multi_manager to manage the entities in your cinematic sequences, like the func_train, the camera, etc. Well, now you will also need to use the multi_manager to teleport the player to the room with the camera, and then back. Make sure that when the player goes to the room with the camera, the camera can't see the player directly (this is different from the engine being able to see between the two), otherwise you'll end up with really confused players (uhh, how did I get there!?). If there are monsters in your cam room and you don't want them to go goat-style apeshit on your player, put the player in a small room right next to the cam room, with a func_wall separating the two. Nifty, huh? Here's the next problem: won't the player see that he is being teleported somewhere? Yeah, so what's the logical solution? Stop the player from seeing anything! Here is our first introduction to the env_fade entity. This entity will make the player's view fade to black (tweak its properties for more options) when it's triggered. After the teleportation there and back, use an env_fade again to bring back the view, and your camera should start moving by that time. Here is one of the variations of the multi_manager sequences for this effect. Unless you've read the tutorial on multi_managers, this won't make any sense, so go and read it.

1. env_fade is activated, the screen is now black
2. trigger_teleport is activated (read the teleporters tutorial!), the engine can now see from the player to the camera
3. invisible func_train is activated if that's the effect you're going for
4. trigger_camera is activated, it starts looking at its designated target
5. another trigger_teleport is activated, and the player is back where he's supposed to be
6. env_fade is activated, the view fades back from black to normal, and we watch as our camera does its stuff

Make sure you don't set long delays here, so as not to confuse the player. Now you can see why i called this the most complicated solution to our problem.

To Fade or Not to Fade?

In the devilishly long explanation of teleporting and fading, I've introduced you to the concept of fading the player's view before activating the camera. Some level designers preach that this is the only way to go, and that unless you fade the view in and out, the transition will look choppy and fake. I disagree. I use both methods and for different reasons. When you use an env_fade with your trigger_camera, it gives a sense of closure, like ending a paragraph in a novel. When you don't use it, and the view switches straight from the player's to the camera's (not to be used in conjunction with the teleport method, you don't want the player to see himself being teleported), it conveys that the action shown by the camera is impending, and you jump right into it. Remember though, if you use the teleport method, always use an env_fade.

Example map: none

By Vlad (Link: mailer.php?uid=2)

Printer Friendly Version (Link: print_tutorial.php?tutID=23)

To Fade or Not to Fade?

In the devilishly long explanation of teleporting and fading, I've introduced you to the concept of fading the player's view before activating the camera. Some level designers preach that this is the only way to go, and that unless you fade the view in and out, the transition will look choppy and fake. I disagree. I use both methods and for different reasons. When you use an env_fade with your trigger_camera, it gives a sense of closure, like ending a paragraph in a novel. When you don't use it, and the view switches straight from the player's to the camera's (not to be used in conjunction with the teleport method, you don't want the player to see himself being teleported), it conveys that the action shown by the camera is impending, and you jump right into it. Remember though, if you use the teleport method, always use an env_fade.