Guide: Siege University - 207: Non-Interactive Sequences

==Introduction==
The "Non-Interactive Sequence", or NIS, is our technical name for the in-game movie sequences. They are so named because they denote parts of the game where the player, sitting in front of his computer, has no control over what is happening on the screen, i.e. it's "non-interactive". These NISs were used as story devices to dramatize certain important events, and to help summarize the "story so far" at the end of each Chapter. 
===The Typical NIS===
During the typical Dungeon Siege NIS, the screen view changes from full-screen to a cinematic wide-screen format, the user interface (UI) disappears, and the camera departs from its orbit around the selected character to move about the world. The camera focuses on the important action taking place, and scrolling text may sometimes appear at the bottom of the screen--depending on whether the NIS has a Narrator or speaking Actor. Finally, at the end of the NIS, the camera returns to the player character, the UI reappears, and the view transitions back to full-screen. 
===NISs are Real-Time===
It is important to note that all Dungeon Siege NISs happen in real-time; they are not pre-rendered. The action on-screen is no different than at any other time in the game-the only differences are the wide-screen format and the fact that the player cannot control his characters. As such, the action on-screen is not always 100% predictable: party members may take a different path to get to their destination, monsters may wander and be standing in a different place than they were before, or they may attack a different target… it may even be a different time of day when the NIS is activated. Accounting for this variability will be a necessary skill in making NISs, and we'll touch on some ways to reduce the randomness you may encounter in your creations. 
===NISs are Single-Player Only===
It is also important to note that NISs in Dungeon Siege occur solely in the Single Player game. NISs don't work in the Multi-Player game, so if a map is meant to be played in both Single and Multi-Player, a Multi-Player non-movie version of the encounter is usually required. Luckily, this is relatively simple to do, and the MP encounter can usually be the SP encounter without camerawork. 
===What This Tutorial Will Teach You===
All in all, making a NIS is actually pretty simple--it's what happens DURING the NIS that is the hard part. In this tutorial, we'll focus mainly on making the NIS: what gizmos to use, how to set the cameras, the parameters involved, and other relevant issues. The stuff that happens in FRONT of the cameras will be mostly up to you for now, and can be as simple or as complex as you have the ability to create. 
===What You Need For This Tutorial===
:Dungeon Siege (of course) 
:Siege Editor 
:Siege Editor Manual (siege_editor_manual.htm comes bundled with Siege Editor.)
:A test map you can practice with. You can create your own in the Siege Editor; a large, flat square will do. 
===What This Tutorial Assumes You Have Already Learned===
:Guide: Siege University - 100: Tutorial
:Guide: Siege University - 200: Concepts and Terminology
:Guide: Siege University - 203b: Triggers II
:Guide: Siege University - 203a: Triggers I
:Guide: Siege University - 208a: Non-Player Characters - This is useful in learning about conversations. Conversations behave a little differently during a NIS, and while we touch on those differences here, we don't cover conversations in full. 
==Anatomy of a Non-Interactive Sequence==
===Overview===
There are four gizmos that form the backbone of NIS construction, found in SE under /Game Objects/gizmos/commands/nis: 
* cmd_enter_nis 
* cmd_camera_command 
* cmd_camera_waypoint 
* cmd_leave_nis 
The structure of a NIS is basically a chain. The start of the chain is the "enter nis" gizmo (cmd_enter_nis), which takes control away from the player and forces the wide-screen view format the first time it receives a "we_req_activate" message. The "enter nis" gizmo is linked to one or more "camera commands" (cmd_camera_command) in sequence, which defines the actual path the in-game camera will take during the NIS. The end of the chain is the "leave nis" gizmo (cmd_leave_nis), which returns the camera to its original location above the player and returns the view format to full-screen. 
The "camera waypoint" (cmd_camera_waypoint) is an extension of the camera command-it must be linked AFTER a camera command, and cannot exist by itself. We'll talk more about these later (see Camera Commands vs. Camera Waypoints below). 
===NIS Gizmo Properties===
Before we actually create a NIS, let's go over the properties of each gizmo, found on the "Template Properties" tab. 
====Enter NIS (cmd_enter_nis) ====
* next_scid: (SCID) This will be the SCID of the first camera command in the NIS sequence. This should never be the SCID of a camera waypoint. Default: 0. (SCID)
* widescreen_delay: (# seconds) Time in seconds it takes to go from full-screen to wide-screen mode. 0 is instant. Default: 1.
* widescreen_enabled: (true/false) Determines whether wide-screen mode is used for this NIS. If "false", the NIS plays in full-screen mode. Default: "true".
* widescreen_fov: (# degrees) Angular field-of-view during the NIS. The default FOV in-game (non-NIS) is "60". Default: 80.
* widescreen_width: (0.0-1.0) Normalized screen width during wide-screen mode. A value of "1" is 100% screen width, whereas a value of ".5" is 50% screen width. Default: 1.
* widescreen_height: (0.0-1.0) Normalized screen height during wide-screen mode. A value of "1" is 100% screen height, whereas a value of ".5" is 50% screen height. This is what makes the black bars at the top and bottom of the screen. Default: ".75".
* select_catalyst: (true/false) If true, the catalyst of the NIS-start trigger is selected (exactly as if the player had selected him), which centers the frustum on his location. This prevents NISs from trying to view potentially unloaded space. Default: false. NOTE: This is an important flag. To see why, create a NIS that starts from a party_member_within_bounding_box trigger, then approach it with 2 characters. Select the first character, and click beyond the bounding box trigger, so he'll eventually walk through it. Then select ONLY the second character, and walk in the opposite direction! As soon as the first character walks into the trigger, the NIS will start, but since the SECOND character is selected (with the frustum centered on him), the NIS cameras may be looking into unloaded space, or the space will unload during the NIS, hanging the game. Setting this flag to "true" will cause the game to force-select the character that walked into the trigger (the party_member_within_bounding_box), assuring that the NIS will exist completely in the frustum.
* game_speed: (-1, 0-1) Forces a particular game speed during the NIS, where "1" is normal game speed, and "-1" does not change game speed. Values less than "1" can result in "Matrix"-like slow-motion sequences. Forcing a game speed of "1" is usually desired, since it will avoid timing errors when players are running at a game speed other than 1x and you are using time-critical speed-locked elements like .wav files (e.g. narration) in the NIS. NOTE: Camera commands have a "game_speed" value that overrides this one, and their default is "1". Unless all cameras are set to "-1", the value set here will have no effect. You can either change all the camera game_speed fields to your desired value(s), or set them all to "-1" and set your desired speed here… your choice. Default: 1.
* music_volume: (0-127) Volume of the music track during the NIS. Default: 127.
* music_fade_time: (# seconds) Duration in seconds for the music to fade to the new volume level. Default: 1.
====Camera Command (cmd_camera_command) ====
* next_scid: (SCID) The SCID of the next camera command or waypoint in the sequence. Do not leave at "0", since the NIS will stop at this camera view and never end, forcing a reboot. Default: 0.
* duration: (# seconds) How long this camera command is active. If there are camera waypoints (cmd_camera_waypoint) AFTER the camera command, this duration determines how long the entire sequence (camera command + waypoints) is active. Default: 5. 
* order: (cor_pan / cor_snap) This field determines how this camera will be transitioned TO from the PREVIOUS camera. "Cor_pan" indicates that the view will slide in a straight line from the previous camera position to this one, over a number of seconds equal to the "duration" field. "Cor_snap" indicates that the view will "snap" immediately to this position, and then hold this position for a number of seconds equal to the "duration". 
* game_speed: (-1, 0-1) Identical to the same field in the "enter nis" gizmo, except this field overrides the "enter nis" gizmo for the duration of this camera command only. Default: 1
====Camera Waypoint (cmd_camera_waypoint) ====
* next_scid: (SCID) The SCID of the next camera command or waypoint. Default: 0.
====Leave NIS (cmd_leave_nis) ====
* normalscreen_delay: (# seconds) Time in seconds it takes to go from wide-screen to full-screen mode. 0 is instant. Default: 1.
* duration: (# seconds) Time in seconds the camera view pans from the last NIS camera view to the location of the player camera before the NIS began. Default: 2. 
* music_fade_time: (# seconds) Time in seconds it takes for the music level to return to normal. Default: 1. 
==Making a Simple NIS==
Let's put together a simple NIS to become familiar with the motions involved. In this example, we'll use two camera commands to move the view around the player character. We'll leave all values at their defaults, but you're more than welcome to experiment with them. 
As previously mentioned, the NIS begins when the "nis enter" gizmo receives a "we_req_activate" message. This message can technically come from anywhere, but because we want our cameras to focus on the player character, we need to know where the character will be-so we'll send an activate message from a "party_member_within_sphere" trigger. 
===Place the Gizmos ===
1. Open your test map and place the following gizmos nearby: 
* trigger_generic
* cmd_enter_nis
* cmd_camera_command (x2)
* cmd_leave_nis
===Wire the Trigger ===
2. Place the trigger_generic somewhere your character will walk.
3. Open the trigger_generic's "Template Properties" tab and edit the following: 
:a. dev_instance_text: As mentioned in the Trigger tutorials, it is always a good idea to label your triggers for later comprehension. Since this trigger will kick off our NIS, enter "START NIS" here.
:b. is_multi_player: Set to "false". NISs don't exist in MP, so this trigger gizmo doesn't need to exist (and take up resources) in MP either.
4. Open the trigger_generic's "Trigger Properties" tab and do the following: 
:a. Create a new trigger instance.
:b. Trigger Properties: Uncheck Multi-Player. We're doing this for sanity only. Because the gizmo's "is_multi_player" flag is "false", this trigger instance won't exist in MP. However, it is all too easy to look at these trigger instance flags and assume that they match the gizmo's settings. Always set these flags accurately, and you won't regret it when you're sifting through dozens of triggers in a complicated sequence.
:c. Trigger Properties: Check the One Shot flag. All NISs are essentially one-shot since camera commands delete themselves on completion. Since you can't run the NIS again in the same session, there's no reason for this trigger to be hanging around (again, taking up resources).
:d. Conditions: Add the "party_member_within_sphere" condition with a Radius of ".5". This ensures we know exactly where the player character will be standing when the NIS begins. The Boundary Check should already be "on_first_enter" since it's a one-shot trigger.
:e. Action: Add the "send_world_message" / "we_req_activate" Action, and copy the SCID of the "cmd_enter_nis" gizmo into the "Send to Object" field. Label this action with something like "start nis" in the "Doc" field.
5. Click OK.
6. Save Objects (Save the game with "Save Game Objects" checked). 
Now we have our trigger gizmo that kicks off the NIS sequence. When a party member walks into that tiny circle, the "enter nis" gizmo is activated. Now we need to define what we see during the NIS, and that will be accomplished by placing our cameras. 
===Place the Cameras===
There are multiple ways of placing and adjusting cameras (see Issues in Camera Placement below), but we'll start with the easiest way. 
7. Move both camera commands near the trigger gizmo, so they will be visible for the next step.
8. Zoom your view of the world close to the trigger gizmo, looking down at it from a 30-45 degree angle. Center the trigger gizmo in the SE's view area, not the center of your monitor. This will be the center of your first NIS camera view.
9. Select the first camera command, and right-click on it. Select "Set Game Object to Camera". The camera command gizmo will snap its position and orientation to the exact position/orientation of your current view.
10. Use the mouse wheel or camera view commands to zoom the view back. You will see the camera command gizmo in the exact place your view was before you zoomed. 
:NOTE: If you saw the camera snap but don't see the gizmo when you zoom out, you may have run into a small bug. Mouse over the area where the camera should be, and you'll see a selection outline. Left click and hold on it, and move it slightly right or left. If the camera gizmo doesn't appear, increase the distance you move it. Sometimes you will have to zoom far away from the camera gizmo and move it a little for it to appear. In-game NISs may not work correctly if some camera gizmos are present but not visible in SE. 
11. Now do the same with the second camera. Move your view to the desired camera location/orientation, select the second camera command, right-click on it, and select "Set Game Object to Camera". The camera will snap to the location of your current view.
12. To double-check the view through any camera, select then right-click on it, and select "Set Camera to Game Object". Instead of snapping the gizmo to the camera view, the camera view will snap to the position/orientation of the gizmo. Any subsequent movement of the camera view will snap it back to its original location (i.e. it will not stay at the location of the gizmo). 
===Link the NIS Cameras===
Our two cameras are now placed. All we need to do now is link them so our NIS knows in what order to use them. Right now, both cameras have default "duration" values of 5 seconds and "order" values of "cor_pan", so the NIS will last at least 10 seconds and will consist of the camera view panning from one camera to the other. 
13. Select the "enter nis" gizmo (cmd_enter_nis), right-click on it, and select "Link Object".
14. Move the mouse over the first camera (cmd_camera_command) in the sequence. You should see a tiny black "chain link" icon next to the mouse cursor.
15. Left-click on the first camera command to "link" the "enter nis" gizmo to the first camera command.
16. Select the "enter nis" gizmo again, and you will see a green line connecting it to the first camera, with an animated arrow running from the cmd_enter_nis to the cmd_camera_command. 
:NOTE: All this really did was copy the SCID of the camera command into the "next_scid" field of the "enter nis" gizmo. It's a graphical and easier way to copy and paste the SCID for NIS gizmos. 
17. Select the first camera command, right-click on it, select "Link Object", then left-click on the second camera command. 
===Finish the NIS by Linking to the "Leave NIS" Gizmo===
18. Link the second camera command to the "leave nis" gizmo (cmd_leave_nis). 
NOTE: Every NIS MUST end with the cmd_leave_nis gizmo. If not, the game will never transition out of wide-screen mode, the UI will never return, and the player will not be able to control anything. If the player hits ESC, the screen will go black while it tries to resolve all the actions of the NIS in compressed time… but since the last camera command isn't linked to anything, the game will seemingly hang on the black screen. Either way, the player must forcibly break out of the game or reboot. 
19. Save Objects. 
===Test the NIS===
Our NIS chain is now complete. Make sure you have saved (with objects), and load up your test map in the game. Walk your character to the party_member_within_sphere trigger and step inside. 
If you left all gizmo properties at defaults, the following should occur: 
* 0 seconds: NIS mode is engaged. The UI disappears, the screen begins to transition to wide-screen mode, and player control input is suspended. The first camera command is activated.
* 1 second: Wide-screen mode is fully engaged. (The "widescreen_delay" field on the cmd_enter_nis gizmo is 1 second.)
* 5 seconds: The view has smoothly panned from the position of the camera when the NIS was entered to the first camera command position (the first camera command has a delay of 5 seconds and a "cor_pan" order. Because there is no previous camera gizmo to pan from, the view pans from the location of the player camera view at the point the NIS began.) The second camera command is activated.
* 10 seconds: The view has smoothly panned from the position of the first camera to the position of the second camera (the second camera command has a delay of 5 seconds and a "cor_pan" order). In addition, we begin to transition back to full-screen, since the cmd_leave_nis is the next gizmo in the sequence.
* 11 seconds: We have returned fully to full-screen mode. (The "normalscreen_delay" value on the cmd_leave_nis gizmo is 1 second.)
* 12 seconds: The camera view has returned to the same location it was in when the NIS began, and the UI has reappeared. Player now has control of his characters. (The "duration" value on the cmd_leave_nis is set to 2 seconds.)
So the full duration from when the NIS began to when it ended was 12 seconds. As you can see, the full duration is calculated from the durations of all camera commands PLUS the duration on the cmd_leave_nis, which determines how long we transition back from NIS to normal mode. 
===Didn't Work?===
If your NIS didn't work, check the following: 
*Make sure you're playing in SP mode. 
*Make sure all gizmos and trigger instances exist in SP mode. 
*Make sure the trigger gizmo is using a "party_member_within_sphere" condition, and make sure this sphere is actually touching the ground. 
*Make sure the trigger gizmo is sending a "we_req_activate" message to the cmd_enter_nis gizmo. 
*Make sure the NIS chain is linked correctly (cmd_enter_nis -> first cmd_camera_command -> second cmd_camera_command -> cmd_leave_nis) 
*Make sure that all NIS gizmos are in the frustum. 
===Camera Commands vs. Camera Waypoints===
At first glance, it might not be obvious why camera waypoints are useful. In fact, after you use them, it STILL might not be obvious why they are useful. In further fact, we only used them once in Dungeon Siege: in the Chamber of Stars "activation" NIS (map_world/gd_a_r1). 
The camera waypoint essentially adds multiple camera positions (waypoints) to a single camera command gizmo, all of which share the same parameters of the "parent" camera command. To elucidate: 
Camera waypoints MUST be appended to a camera command, and the ENTIRE chain (camera command + all appended waypoints) share the same "duration". The entire chain also shares the same "order", which, to have any visual effect, must be "cor_pan" (if the entire chain is set to "cor_snap", then the NIS view will immediately snap to the last waypoint in the chain, which negates the purpose of the chain). 
The duration of the entire sequence is divided evenly between each gizmo: the camera command and its waypoints. So, if you have a camera command plus 4 waypoints, and the duration of the command is 5 seconds, then each gizmo in the chain is allocated a 1-second duration (command + 4 waypoints = 5. Five objects divided by 5 seconds is 1 second per object). The motion between such waypoints won't look smooth and continuous unless the command and waypoints are exactly equidistant from each other; otherwise, if the distances are different, the view will speed up and slow down in its quest to arrive at each gizmo at 1-second intervals. You can see this yourself by placing a cmd_camera_command and 4 cmd_camera_waypoints roughly equidistant from each other and running the NIS, then wildly changing the distances between the gizmos-some short, some long. 
So why use a camera waypoint? 
The biggest value in waypoints is in editing long camera sequences that contain cameras at equidistant separation. In the Chamber of Stars NIS, the camera slowly pans around the inside of a circular room, constantly focused on the center. The nine cameras that comprise this sequence are at even distances from each other for the circumference of the room. The timing of this circular sequence depended entirely on events happening in the Chamber, which were always changing during development. Every time the timing changed, the durations on 9 cameras had to be changed, which also pushed the timing off on the cameras further down the chain in this ~80 second NIS. Having to constantly change 9 camera durations, and also having to individually count them to re-figure the total duration of the entire NIS became tiresome. Changing the circular sequence to use a single camera command, with a single duration, and multiple waypoints, simplified editing just a little bit, and was slightly more efficient. 
That was a lot of text to explain a small increase in efficiency for a rare NIS case. If you can find better uses for the camera waypoint, don't hesitate to let us know. : ) 
==Issues in Camera Placement==
One of the most difficult tasks in making NISs is placing the cameras "just right". As of now (SE v1.09b), our tools for placing and fine-tuning camera views leave a little to be desired. Placing cameras may be a bit clumsy and frustrating at first; but like anything else, if you stick with it, you'll develop your skills and learn your own tricks to make it work for you. 
=== Placing and Manipulating Cameras ===
There are three basic ways to place and manipulate camera position: 
# Match View: Snap the camera command gizmo to the current camera position/orientation (Set Game Object to Camera).
# Eyeball: Physically move/rotate the camera with mouse/keyboard and/or adjust pitch/yaw/roll with the "Rotation" tab of the camera's Object Properties sheet.
# Define: Directly enter values into the "orientation" and "position" component fields on the camera's "Template Properties" tab.
Each one of these approaches has their benefits and drawbacks.
====Match View: Set Game Object to Camera====
This method consists of moving the SE camera view to the desired location using your mouse, then selecting a cmd_camera_command gizmo, right-clicking on it, and choosing "Set Game Object to Camera". The camera gizmo will snap to the exact location and orientation of your current SE camera view. 
Controls
* Right Mouse Button (Hold): Move camera view on the horizontal plane (forward/back, left/right)
* SHIFT + RMB (Hold): Move camera view on the vertical plane (up/down)
* Middle Mouse Button (Roll): Zoom camera view in/out.
* Middle Mouse Button (Hold): Rotate the camera around a fixed point in space. Where this fixed point is actually located is sometimes a mystery.
* Camera Controller: This tool can be found under the "View" pull-down menu, allowing more accurate movement of the SE camera.
Pros: 
Using the mouse is by far the easiest way to get the "perfect" position for a single camera, since all you need to do is snap a camera command to your view with the "Set Game Object to Camera" command. It's basically WYSIWYG (What You See Is What You Get). Note that the actual view in-game will be slightly higher and wider than the view in SE, especially since the cmd_enter_nis gizmo changes the FOV from 60 to 80 by default. 
Using the Camera Controller can offset some of the difficulties in placing multiple cameras after the first (see below). 
Cons: 
Using the mouse is the least precise method of placing multiple cameras. That is, if you need to place your next two cameras at the same exact height as the first, or at the same pitch angle but 20 feet forward and turned 90 degrees to the left; this is a difficult (if not impossible) way to do it. It is impossible to select another object immediately after the snap, since you are now "inside" the camera object, and are always clicking on it no matter what. You also can't hold down the right mouse button to pan the camera away, since you will be right-clicking on the camera object, bringing up its menu. You will usually have to use the mouse wheel to zoom out, or hold it down to rotate away, but since the rotation origin can be close or far away, you are rarely positioned well enough to place a second camera. 
Using the Camera Controller may assist in precisely placing multiple cameras in relation to the first, but otherwise it is a time-consuming way to choose a camera view. 
Bugs: 
The "Invisible" Camera: When snapping a camera object to the view location in SE, sometimes the camera object will be invisible after the snap, or it will only be visible when the SE camera is at a certain angle relative to it. If you run the NIS with a camera in this state, it may not function correctly-the duration may be incorrect, it may be pointing in a completely different direction, or it may travel along a different track than intended. To fix this, mouse over the position of the "invisible" camera, or, if you don't know its exact location, draw a box over the area you think it's in. You will see a wireframe selection box when the camera is selected, even if the gizmo itself is not visible. Left-click and hold on the selection box, and move it slightly to the right or left. If the gizmo suddenly becomes visible, it is "fixed", and you can return it to its original location. Sometimes you may have to zoom far away from the camera gizmo, then select and move it a little bit, or sometimes you may have to move the camera gizmo all over the screen before it appears. Once it appears, SE knows the camera is there, and the problem is corrected. 
NOTE: Some gizmos, including cameras, will vanish if the SE camera gets too close to them. This is normal, and doesn't indicate an "invisible camera" problem. 
====Eyeball: The Mechanical Method====
This method consists of using the keyboard/mouse and the "Rotation" tab of the camera's Object Properties page to maneuver camera objects into position. To check the view of the camera, you can select the camera object, right-click, and choose "Set Camera to Game Object". 
Controls
* Left-Click and Drag: Move the object on the horizontal plane (forward/back, left/right)
* SHIFT + Left-Click and Drag: Move the object on the vertical plane (up/down, left/right)
* Arrow Keys (Movement Mode + Rotation Mode ON): Left/Right controls YAW, Up/Down controls PITCH. SHIFT + Up/Down controls ROLL.
* Arrow Keys (Movement Mode ON + Rotation Mode OFF): Left/Right/Up/Down nudges camera on the horizontal plane. SHIFT + Up/Down nudges camera on vertical plane.
* Rotation tab: This tab is found on an object's Properties page. There are 4 different ways to set the pitch/yaw/roll of the object here. You can drag indicators around the circle, you can use the arrow buttons, you can use the drop-down list to select a number, or you can directly enter a number into the fields. The Rotation Snap Increment setting determines how many degrees of rotation are added per button press, AND keyboard arrow keypress.
Pros: 
This is the easiest way to fine-tune the location/orientation of a camera object once it has been placed. You can tweak the values a bit, look through the camera to check position, and tweak it again. You won't screw up what you're doing if you move the SE camera view. 
Cons: 
The biggest problem is the fact that pitch/yaw/roll isn't measured from the front of the camera, like an airplane, but from a fixed vector in space. If you set the pitch/yaw/roll to 0/0/0, the camera will point to this vector. All pitch/yaw/roll values entered will always be relative to this vector, and not the current vector of the camera. This makes it extremely difficult to apply your desired adjustments to the camera object if it is pointing in a wildly different direction than the zero-vector. 
====Define: The Mathematical Method====
This method consists of explicitly defining the position and orientation values found on the camera gizmo's Properties sheet. The above two methods ultimately provide values for these fields anyway, so sometimes it is easiest to directly enter values or copy/paste them from another camera. 
Orientation: This field has a 4-number value. According to James Loe, one of our engineers: "The 4 numbers represent a quaternion. You won't be able to type numbers in yourself and have them make any sense. Or probably even understand anything that comes out." Given that, how can we use this field? By copy/pasting the orientation value from another camera object. If your second camera needs to have the exact same orientation as the first, copy/pasting this value is as exact as you can get. 
Position: We can actually edit this field with some knowledge, and it is documented well on the tab. Each object has an XYZ position (in node-based meters) relative to a particular Node. 
Pros: 
Absolute precision on orientation and position. 
Cons: 
Directly editing orientation and position can be time-consuming and not very intuitive. Can only use "orientation" by copy/pasting from another object's "orientation" field. 
Bugs: 
When copy/pasting an orientation or position value into a new camera, something odd happens: the gizmo aspect (the actual camera mesh) will jump to the new location/orientation, but the selection box stays where it is. To further edit the camera in this session, you must use the selection box, not the visible camera object. To fix, save, quit SE and reload the region; and both the camera object and its selection box will be in the correct place. 
===Copying and Pasting Camera Objects===
There are two other useful techniques that bear mentioning: 
*Copy/Pasting
*Drag Copying 
====Copy/Paste====
Performing the standard copy/paste on a camera object can be useful, but it's a little buggy. When you copy (CTRL-C) a camera object, and then paste it (CTRL-V), the new camera object will appear directly above the spot on the ground where the cursor rests, AT THE EXACT HEIGHT AND ORIENTATION AS THE FIRST CAMERA...usually. 
Sometimes the new camera will be located at the same height, but will be turned 90 or 180 degrees from the original. Sometimes the new camera will appear so far above or below the ground, you'll think you didn't paste it. Just be aware of these issues when using copy/paste and it should remain a useful operation. 
====Drag Copy====
"Drag Copy" uses the default key "C" to 'clone' the object in place, on exactly the same spot. You can then move this clone relative to the first object. This is highly useful for placing secondary cameras with the same orientation as the first, with a specific relative position. 
However, "C" is too easily pressed for me, sitting as it does next to "V", which is the default key to bring up an Object's Properties. Therefore, you might find it safer to assign Drag Copy to "ALT+C" or something similar (View | Keyboard Shortcuts). Otherwise, you may accidentally populate your region with multiple superimposed copies of objects without realizing it. 
The only real problem with Drag Copy is that, after you clone the first object, you usually still have the first object selected-NOT the new clone. This can screw up your wiring if you're not careful. Pressing the "Objects - Rotate Selection" key (Q) will cycle your selection through multiple objects under your cursor, allowing you to select the clone. 
===Technical Issues in Camera Placement===
Now that we know how to place camera objects with impunity, it would help to be aware of some technical issues and guidelines. We'll touch on five subjects: 
#Game Performance and Immersion (Showing the Horizon/Sky)
#Fog Distance
#Out-of-Frustum Cameras
#Linking Cameras Across Regions
#Sound
====Game Performance and Immersion (Showing the Horizon/Sky)====
During a NIS, you never want to show more objects on the screen than the engine was intended to handle. The easiest way to "get in trouble" with this is by flattening your camera angles toward the horizontal when outdoors. The effect of this is to exponentially increase the number of objects the engine is obliged to render, drastically slowing performance. A similar case occurs when the camera is looking down at the ground from a high elevation. When outdoors, it is best to use similar camera angles to the normal camera system. 
In addition, certain camera angles will destroy a sense of immersion in the world: 
* There is no horizon. When looking horizontally, the camera will see the mood's fog that obscures the edge of the frustum. 
* There is no sky. When looking on an up angle, the camera will again see fog. 
* Many objects are not textured on their under-side, simply due to the fact that they were never intended to be looked at from below. These textures instead appear transparent. 
Lots of fog doesn't look very good (unless it's the intended effect...but fog is never interesting). Also, breaking the illusion of the world by showing the transparent underside of an object should be avoided at all costs. When indoors, there is a lot more leeway with camera angles, especially if there is a real ceiling (like the Chamber of Stars). 
====Fog Distance====
Every mood defines the neardist (near distance, or 1% fog) and fardist (far distance, or 100% fog) of the fog. The neardist is the distance, in meters, from the selected character to the beginning edge of the fog. 
When entering a NIS, the neardist/fardist is calculated from the position of the camera, not the character, so the fog travels WITH the camera. This is nice in that you don't have to worry about moving the camera into fog, but you DO have to worry about showing the edge of the frustum. Since the frustum is still centered on the selected character(s), the fog will no longer hide its edge if you get near it with the camera. 
You also have to worry about moving the camera too far above the terrain or away from a particular object, since those objects will eventually be covered by the fog. This is easily fixed, however, by using different moods with larger neardist/fardist values inside a NIS. 
The Fog Bug: Finally, there is an unfortunate bug with NISs and the neardist/fardist calculation, drastically reducing their values. The net effect is that the fog seems MUCH closer during a NIS than during normal gameplay. This can be fixed by calling a different mood during the NIS that has larger neardist/fardist values, if necessary. 
====Out-of-Frustum Cameras====
When the NIS begins, the frustum is centered on the selected player character. It is okay to have camera objects in the NIS chain placed outside this frustum, AS LONG AS THEY WILL BE INSIDE THE FRUSTUM AT THE TIME OF THEIR ACTIVATION. This can occur when the player characters are commanded to move during the NIS, effectively moving the frustum. 
If a camera object is outside the frustum when the previous camera is finished, then the NIS will hang, exactly as if the previous camera did not have a "next_scid" value (i.e. it's not linked to anything). Essentially, this is true, since the next camera is unloaded and does not yet exist in the game world. 
====Linking Cameras Across Regions====
As long as a camera object is in the frustum at the time of its activation, it doesn't matter what region it is in. However, since SE can only work on one region at a time, linking the two cameras that cross the region boundary is slightly more work: 
# Open the second region in SE and copy the SCID of the second camera. 
# Close the second region and open the first region, and paste the second camera's SCID into the first camera's "next_scid" field. 
# Save Objects. 
SE may give you an error every time you re-open the first region, since the first camera is linking to a SCID that doesn't exist in this region. This is a normal error, but doesn't actually point to something broken in this case. 
====Sound====
During normal gameplay, the "virtual ear" that determines the volume/location of a particular sound effect is relative to the party members. Volume is determined by how close the effect is to the party, and location is determined by where the effect is playing relative the camera's view of the party (e.g. if the sound origin is to the left of the party, as viewed by the camera and NOT their facing, the sound plays in the left speaker). 
During a NIS, the "virtual ear" becomes the camera itself. 99% of the time, this is the desired behavior, and what you see on screen and what you hear will seem to match. However, you might find yourself in a situation where you have a long shot of the action, and a loud noise is supposed to play from a sound emitter near the party. Instead of hearing the loud noise, you may barely hear it or not at all, since the camera is too far away from the sound origin. In these cases, you may have to move the sound emitter or create a new one at the position of the camera. This was done during the Gom NIS for the sound of the elevator hitting the ground (map_world/gom2). 
==Subtitles==
Subtitles are the scrolling blocks of text that appear at the bottom of the screen during certain NISs, like the intro NIS at the very beginning of the game, or the Merik NIS. 
===Subtitles are Conversations===
Subtitles are extremely easy to accomplish, because they are simply normal conversations--the exact same kind of conversations that appear when you talk to any NPC in the game. The only difference between a normal conversation and a conversation that produces subtitles in a NIS is that the NIS conversation has the "nis = true;" flag contained in its [text*] block. For an example of this, see the [conversation_narrator] block in "\world\maps\map_world\regions\fh_r1\conversations\conversations.gas" 
What usually happens is that an Actor (some kind of NPC), with a NIS-only conversation assigned to him, receives a we_req_talk_begin message from a trigger instance. Sending this message to an actor with a conversation is the equivalent of clicking on a speaking NPC in the normal game. When the actor receives this message, the conversation .wav file begins playing and the conversation text begins scrolling at the bottom of the screen. The speed of the text scroll is determined by the scroll_rate value in the conversations.gas file. 
For more information on conversations, see Guide: Siege University - 208a: Non-Player Characters. 
===The Narrator===
Late in the Dungeon Siege development process, NISs were added that were narrated by an off-screen voice. When it came time to add subtitles, we were in a bind, since there was no easy way to add subtitles to the NIS without an actor and conversation, and there was no time to implement a code solution. 
So, the "Narrator" was born. The Narrator is an invisible actor who simply provides a source for a conversation, which prints text to the screen and plays the voice file. Since the character narrating Dungeon Siege is the King of Ehb, we added the "narrator" template underneath "base_king" in the npc_king.gas file. 
When placing the Narrator in SE, you will see a gizmo aspect, not the King mesh. Otherwise, running a conversation with the Narrator is exactly the same as any other actor. 
The Narrator was used at the end of each Chapter (except Ch9), and at the very beginning of the game (fh_r1). See fh_r1 for a typical example of how the Narrator is used. 
==The Party Wrangler==
===Solving the Death Problem===
There is a major problem with NISs that we haven't talked about yet. The problem lies in the fact that NISs are just normal gameplay with a wide-screen view, no UI, and lack of player control. Because it's normal gameplay, the party members can still attack monsters, monsters can still attack party members, and the packmule can run all over the earth. In addition, the party members can DIE during a NIS, and the player is powerless to help them. 
Obviously, you should never, ever put the player in a position where he has to watch his characters get hurt or die when he can't do anything about it. 
To solve this problem, the Party Wrangler was created (/Game Objects/gizmos/commands/specialized/cmd_party_wrangler). To avoid combat and character death during NISs, the Party Wrangler does the following: 
*Changes the party's alignment from "Good" to "Neutral".
*Issues a "stop" command to all party members and monsters.
Neutral creatures do not attack Good or Evil creatures, and Good/Evil creatures do not attack Neutrals. As soon as the party is changed to Neutral alignment, new monsters will not try to attack them. The "stop" command stops all party members and monsters from fighting, and because the party is Neutral, neither the party nor the monsters will re-engage the other. 
To return the party's alignment to "Good", the Party Wrangler is sent a "we_req_deactivate" message, usually at the end of the NIS. 
Nearly every NIS in Dungeon Siege uses the Party Wrangler to cease hostilities for the duration of the NIS. 
===Solving the Fidget Problem===
A less immediate problem was the fact that party members, when not attacking, run a "fidget" animation. This sometimes gives them the effect of looking bored or aloof, which is usually not a problem EXCEPT when they are supposed to be listening to a very important speaker, like Merik or the King. When the King is making his grand speech, and the NIS camera is panning around his cell, it looks extremely odd to see Farmgirl put her hand on her hip, tilt her head and look off to the side, like she couldn't wait until he was done with his yammering. 
Instead of creating a "standing still" animation for every character and explicitly running it during NISs that require listening, the Party Wrangler was given the ability to "freeze" characters in place. When done correctly, party members will be frozen looking directly forward, seemingly attentive to the speaker. The King NIS in "/map_world/cd_r1" is a good example of this. 
===Using the Party Wrangler===
The Party Wrangler actually has three Properties, for three functions. Each function is activated as soon as the gizmo receives a "we_req_activate" message. Each function is immediately deactivated on reception of a "we_req_deactivate" message: 
* neutralize: (true/false) If true, changes the party to Neutral alignment.
* freeze: (true/false) If true, freezes the party's current animation in place.
* invisible: (true/false) If true, makes the party invisible. This was never used in Dungeon Siege.
The Party Wrangler is an extremely easy gizmo to use, but is also very dangerous. If you make the party "Neutral" and never change them back, the party will play the entire rest of the game unable to attack or be attacked. If they are never unfrozen, they will appear to "skate" everywhere in the world. This, obviously, breaks the game. :) Caution is advised. 
In almost every NIS, the Party Wrangler is activated at the same time as the cmd_enter_nis gizmo. It is deactivated at the very end of the NIS, AFTER the final delay of the cmd_leave_nis gizmo (if the Party Wrangler receives its deactivate at the same time the cmd_leave_nis gizmo is activated, there is usually a 1-2 second "delay" while the camera finishes transitioning back to the pre-NIS point. The player still has no control during this delay). 
There are many examples of the Party Wrangler being used in Dungeon Siege's NISs, but "/map_world/fh_r3" has a very simple implementation. 
==Other Stuff to Know==
We've covered most of the information necessary in understanding NISs, but there's a couple items you should know that don't fit anywhere else. 
===Hitting ESC During the NIS===
NISs can be "bypassed" by hitting the ESC key. When the player does this, the screen turns black for a second or two, and the game resumes after the NIS would have ended. 
What really happens, from an engine perspective, is that the NIS keeps running, but is no longer rendered to the screen. The game pushes through the NIS as fast as it will go, and tells the game that .25 seconds elapsed each frame, even though it doesn't render any of them. When the NIS reaches the cmd_leave_nis gizmo, rendering resumes. 
===Cameras Delete Themselves===
This was mentioned earlier, but just to be clear: cmd_camera_command gizmos automatically delete themselves after finishing. This makes it impossible to re-use camera objects again for the same or a different NIS. 
===Triggering from Camera Objects===
As you should already know, a trigger instance can live inside any object, not just trigger_generic gizmos-including cameras. If you would like to trigger an Action from a cmd_camera_command gizmo, add a "receive_world_message" Condition that listens for the "we_camera_command_done" message. Every camera sends this message when it is finished, i.e. when its duration has elapsed. 
Several Dungeon Siege NISs trigger events from camera objects to ensure correct timing. The intro NIS does this (/map_world/fh_r1 and fh_r1a), and so does the Gom NIS (/map_world/gom2). 
===MP Versions of NIS Areas===
If your map will be played in both SP and MP modes, you'll need a MP version of what is a NIS in SP. What form this takes is up to you. Some NISs in Dungeon Siege (like the camera pan over Castle Ehb) has no MP "version", since it was unnecessary. None of the narrated NISs had a MP counterpart (game intro plus all Chapter ends). What WAS necessary was to include MP versions of NISs that forwarded the plot in some way, like Merik, the Goblin Inventor, and Gom. In MP, the events that take place attempt to mimic the events in SP as closely as possible, or at least contain the most important elements. 
Creating a "MP version of events" is just making sure, through triggers, that what needs to happen will happen even through no NIS is taking place. You may need to have trigger gizmos that are only SP or only MP, or you may need trigger gizmos that exist in BOTH SP and MP but have trigger instances inside it that are either SP or MP. 
For examples of this, see the following NISs (locations listed in Appendix below): Intro, Gloern, Merik, Goblin Inventor, Gresh, King, Swanny, Chamber of Stars, Gom.
==Conclusion==
We've covered everything we're going to cover in this lesson on Non-Interactive Sequences. You should have a basic understanding of building NISs and some of the related issues and concepts. By far, the best things you can do to further your understanding of the practical workings of NISs is to study each NIS in Dungeon Siege, and experiment on your own. Following this section is an Appendix that lists the location of all 19 NISs in the game, each of which has its unique properties. Even though you will encounter many gizmos and configurations you may not yet be familiar with, they will reveal themselves to you with investigation. 
Remember that there are FAR more possibilities for NISs than have been explored so far in Dungeon Siege. While the 19 NISs in the game are certainly good to learn from, you might find much better ways to create your own. New technologies may emerge to make NIS-building even easier and more powerful. Never hesitate to share what you learn with other aspiring movie-makers! 
==The 19 Non-Interactive Sequences in Dungeon Siege==
All NISs take place in the map_world map ("Kingdom of Ehb"). The regions where these NISs appear and the trigger SCID(s) involved are listed below. You can search for the SCID in the designated region to find the start of the NIS. 
# Game Intro / Norick (fh_r1, fh_r1a): Narrator hints at backstory, Norick speaks and dies. Begins when player is detected by party_member_within_sphere trigger (s:0x01C0078D in fh_r1).
# Chapter 1 End (fh_r3, bt_r1): Narrator. Player enters Stonebridge. Begins when player enters a bounding box trigger (s:0x01E006BF in fh_r3).
# Gloern (path2dm): Krug kill dwarves, Gloern appears and fights. Begins when player enters a bounding box trigger (s:0x03300144).
# Chapter 2 End (nt_r1): Narrator. Player enters Glacern. Begins when player enters bounding box trigger (s:0x0270064D).
# Merik (lc_r5): Player frees Merik from the ice crystal. Begins when crystal (s:0x04B001B5) is struck AND after a bounding box (s:0x04B001B1) is entered.
# Chapter 3 End (lc_r5): Narrator. Player continues after freeing Merik. Begins when bounding box (s:0x04B001E9) is entered AND Merik NIS is finished (see previous).
# Goblin Inventor Start (gi_r3): Goblin Inventor appears, gives speech, and emerges with the Robosuit. Begins when player enters bounding box (s:0x05100037).
# Goblin Inventor End (gi_r3): Goblin Inventor suit is destroyed, and Merik's staff is revealed. Begins when Robosuit is killed (s:0x05100020) AND when player enters a node range (s:0x05100263).
# Chapter 4 End (gi_r3_b): Narrator. Player leaves the Goblin Inventor Hideout. Begins when player enters bounding box (s:0x0530010B).
# Gresh (cf_r1): Gresh taunts the party then summons a bunch of skeletons. Begins when player enters bounding box (s:0x00900566). This NIS is interesting because it changes the mood for the entire region, including the mood triggers at the region borders. Killing Gresh flips the mood triggers back to the original configuration.
# Chapter 5 End (cf_r1): Narrator. Player enters Fort Kroth. Begins when player enters bounding box (s:0x0090053E).
# Chapter 6 End (dc_r1): Narrator. Player leaves the Droog Village. Begins when player enters bounding box (s:0x00A00962) AND after player has talked to Nonataya (s:0x00A0000A).
# Castle Gates (ce_r2): Player arrives at Castle Ehb. Begins when player enters bounding box (s:0x0460086E).
# King/Chapter 7 End (cd_r1): King has long speech, drops Star Key. Begins when door (s:0x05B00188) to King's cell is opened AND player is in bounding box (s:0x05B00368).
# Swanny (gd_a_r1): Swanny the Mad Jailer is released, speaks, and attacks. Begins when button (s:0x01F00257) to lower Swanny's cage is pushed AND the cell door (s:0x01F002FA) is broken.
# Enter Chamber of Stars (gd_a_r1): Short introduction to the Chamber. Begins when player enters bounding box (s:0x01F0032E).
# Chamber Activation (gd_a_r1): Long sequence where the Chamber powers up and manifests treasure chests. Begins after all 4 statues (s:0x01F0037A, s:0x01F00363, s:0x01F00364, s:0x01F00365) are turned, and player is inside bounding box (s:0x01F00360).
# Chapter 8 End (gd_a_r1): Narrator. Player leaves the Chamber. Begins when player enters bounding box (s:0x01F0032F) AND Chamber Activation NIS has finished (see previous).
# Gom (gom2): Player descends elevator to meet Gom, Gom gives his speech and attacks. Begins when player enters bounding box (s:0x002001BD).
==Navigation==
Category:Dungeon Siege Editor