Vlatitude Archive: Trigger_camera Tutorial Last edited 4 years ago2019-04-25 09:47:10 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).

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.