Editing Tools Documentation Overview

TRON 2.0

Editing Tools Documentation

Overview

Introduction

The documentation contained in this release is provided as reference material for anyone interested in creating custom maps or basic mods for TRON 2.0. Since the tools are nearly identical to those used for NOLF2, the NOLF2 tools have been used as a starting point. Anyone familiar with NOLF2 editing should have no problems getting started creating maps for TRON 2.0. The sections below include steps on setting up your TRON 2.0 installation for content editing and also provide an overview of the various documents in this release and their relation to one another.

Please note that these tools and their documentation are provided on an “as is” basis and are unsupported. Due to the complexity of the subject matter and the rapidly changing nature of the technology, some of this material is outdated. When working with attribute files, in particular, it is recommended that the headers be thoroughly reviewed before making any changes. That said, we hope you have a great deal of fun creating new worlds for TRON 2.0.

Installation

  • Copy the Tools directory to your TRON 2.0 directory

The Tools directory contains the applications needed to work with or create custom levels, models and special effects. Copy the entire Tools directory to your root TRON 2.0 folder. (C:\Program Files\Buena Vista Interactive\Tron 2.0 by default).

  • Extract the TRON 2.0 assets

The various assets used to create the game are compressed into large files called .rez files. To access these assets, they must first be extracted using a command line utility called LithRez.exe, which is found in the Tools directory. To learn the basic syntax for manually extracting or creating .rez files, explore to the Tools directory using the command prompt and then type “lithrez ?” without the quotes. The number of rez files found in your TRON 2.0 directory may vary depending on which updates were installed. Explore to your TRON 2.0 directory and make a quick list of the names of the rez files it contains. These typically include game.rez, game2.rez, gamep3.rez, gamep4.rez, sound.rez and gamedll.rez. To simplify the process of extracting .rez files, a .bat called LithRez.bat is included in the Tools directory that automatically extracts the .rez files to the appropriate directories. LithRez.bat main purpose is to provide a clear example of the syntax used to extract .rez files and it should be edited to reflect the .rez files found in your TRON 2.0 directory. Keep in mind that the .bat file assumes the program was installed to the default path - C:\Program Files\Buena Vista Interactive\Tron 2.0. If the game was installed to a different directory, the paths in LithRez.bat will need to be updated accordingly. All files should be extracted to *:\Program Files\Buena Vista Interactive\Tron 2.0\Game. LithRez.bat can be easily edited with any text editor by right-clicking on the file name and choosing Edit. Once opened, delete any lines pertaining to .rez files you don’t have (or add entries for any .rez files that are not listed there) and make sure that the installation paths are correct. Extracting the .rez files can take quite a while. While they’re extracting, you might want to move on to the other portions of the documentation. Once the .rez files are finished extracting, a Game directory containing all the extracted assets will exist in your TRON 2.0 directory.

Tutorials

  • Using DEdit to Create Worlds

This document will introduce you to DEdit, LithTech’s primary level creation tool. It covers DEdit setup and configuration, basic level design, adding objects and prefabs, lighting, and other skills you’ll need to know in order to create levels for TRON 2.0. This document also features a description of each of the objects that can be placed within a level.

  • Processing Your Levels

This document will answer the most commonly asked questions regarding how to use processor.exe to compile your DEdit worlds into usable levels.

  • Content Packs and Modifications

This series of short tutorials covers the basics of creating map packs and other mods.

  • Adding and Modifying Weapons

This document covers everything you need to know about modifying the TRON 2.0 weapons and adding new ones.

  • Working with character models

If you plan on modifying or adding character models, this document will show you how. It covers everything from exporting models from Maya to editing them with ModelEdit.

Reference Documents

  • Player Messages

On-screen transmissions, skill rewards, music, and other aspects of gameplay are achieved through the use of commands sent to the player as a message. This document details all of the possible player messages and how to use them.

  • AI Overview

This document serves as an overview of AI systems. It also includes details regarding AI Nodes, Goals, SmartObjects, and other systems you’ll need to become familiar with before adding AI to your levels.

  • AI Gameplay Setup

Once you understand the basic AI systems, this document will provide further information on how to use these systems to create gameplay with your AI.

  • FXed Reference

This document contains information regarding the use of FXed to modify and create special effects.

· Texture Scripts – Artist’s Reference

This document describes what textures scripts are for, and provides reference materials for artists who wish to use them.

Sample Maps

While the documentation provides a wealth of information, the best approach is often to carefully examine a production map after having played it several times. For that reason, a SinglePlayer map, a Disc Arena / Disc Tournament Multiplayer map and a SinglePlayer / Multiplayer LightCycle map have been included in the samplemap directory. Read through the sections on lithrez for instructions on extracting the .rez file to your Game directory so that the maps’ .tbw and .ltc files can be studied in the in DEdit.


Using DEdit to Create Worlds

Welcome to the DEdit overview and tutorial. DEdit is the tool created by the LithTech team that enabled the TRON 2.0 Level Designers and Artists to create the geometry and gameplay you experienced in TRON 2.0. DEdit allows you to build the ground, sky, walls, ceilings and shapes for your levels. You will then apply textures, props, prefabs, lights and sounds to give them a realistic appearance. TRON 2.0 was created using literally thousands of these assets, which you may appropriate to create the base for your own level. You may also add your own assets where applicable. Finally, you’ll add the game objects that allow other players to interact with your world.

Creating levels is an extremely complex and time-consuming process, and the following is merely the starting point for those who want to learn the basics of building worlds for the LithTech Jupiter engine. If you’ve done game design before on a 3D or near-3D game, you’ve probably worked with tools like DEdit. A separate document will cover ModelEdit, the companion to DEdit, which allows you to create characters and models for your world.

Basic Terms

These terms are relevant to a discussion of DEdit.

Project — A project in DEdit represents the sum of all the resources in the game: all the code, all the textures, all the sounds, all the worlds, and so on. Unlike other world geometry editors, DEdit first opens the project, rather than a world file.

World — When your players walk around in your game, it is a world that they’re standing in. Worlds divide your game up into sections where different parts of the game take place. In other games, these are sometimes referred to as maps, levels, scenes, or episodes. World editing is the primary focus of DEdit and each world is stored in a separate file on the hard drive.

Objects — Simply put, anything a player interacts with that moves, lights up, shoots, growls, or goes into the player’s inventory is an object. DEdit allows you to place any kind of object that your game’s code or the engine’s code can create.

World Geometry — Parts of the world that act as walls, floors and sky are generally made of world geometry. Such geometry is solid, immovable, and generally never changes.

Brush — The basic unit of world geometry. A brush is made up of planes that define its faces, lines that define its edges and vertices that define its corners. You can manipulate either an entire brush at once or any of the vertices, lines, or planes in the brush.

Polygon — A closed plane figure bounded by straight sides. Most of the geometry created in DEdit and used for the LithTech Jupiter engine is one sided. As a result most of the creation process involves working with polygons instead of entire brushes.

Primitive — A simple shape that you can add to the world as the foundation of a more complex shape. Typical primitives are things such as cubes, pyramids, and cylinders.

Prefab — A prefab is like a primitive, but more complex. If you build a street lamp complete with textures and a light source that gives off just the right shade of light, you can select the lamp and its associated source (or any group of objects and brushes inside DEdit) and save it as a prefab. Thereafter, you can copy and paste that streetlamp into your world without having to rebuild the whole object.

Unit — The basis of measurement in DEdit and the LithTech Jupiter engine. Units don’t equate directly to real-world values. Instead, the game designers can select a scale of game units to real-world measurements. As an example, in TRON 2.0 the following values are used: railings are 56 units tall, a chest-high box would be 64 units, and a typical doorway would be 128 units high.

Mode — DEdit has several different modes that allow you to change certain elements of your world (i.e. just brushes or just objects) without accidentally affecting others. They’re designed to simplify interacting with your world while editing, so it’s important to choose the right mode for your task.

Processing — When you process your world, DEdit creates a second version of the world with some information removed (parts only you need to know about), and other information added (parts only the game engine needs). Processing is a necessary step you’ll take in getting your world up and running in the game, and is often the first place where you will discover problems with your level.

Texture — In DEdit, textures are used like wallpaper, paint, or plaster to cover the raw plywood of your walls, floors, ceilings, doors and so forth. Without a texture, your brush will appear flat-shaded in the game, almost always with unpleasant results. Just as you wouldn’t want a house with raw plywood walls, you always want to apply textures to the brushes in your level.

LithTech Resource Types

Before starting, you should learn a little more about the structure of the resources that DEdit and LithTech can use in a game. The LithTech Jupiter engine can access and use a wide variety of file types and other resources. The list below is arranged by resource type, and each resource type includes a list of the sorts of files LithTech can use in that type, as well as a description of those files.

Project — As mentioned before, the project is the total of your whole game and all its resources. A .DEP (DEdit Project) file at the top of your tree of game resource directories serves as a guide to DEdit. The .DEP file is a pointer to the rest of the resources for DEdit and includes some of the information about your game resources. The rest of your game’s files exist in subdirectories of the directory where your .DEP file resides.

Directories — The subdirectories that contain your other game resources are a type of resource in themselves. The structure of these directories defines the tree views you see in many of the tabs in DEdit’s Project window. If you find a game’s .DEP file and look at the subdirectories in the same folder with it, you’ll see names such as TEXTURES, WORLDS, SOUNDS, and MODELS. These folders contain whatever resource they’re named for, so if you want to add new textures to a game or copy a world from one game to another, you should look in the directories named Textures and Worlds, respectively.

Worlds — Worlds come in two forms: .LTA files and .DAT files*. If you think of worlds as programs, the .lta file is the source code: Editable and understandable by the user and DEdit, but not executable. The .DAT file is like an actual program: it can be run in the game, but since it’s been “compiled” (processed, in this case), the user can no longer modify it. The .lta files are what you change and save changes to inside of DEdit, and the .DAT file is the output of Processor.exe, which prepares your world to run in the game and optimizes its performance.

*.LTA files can also be saved as .LTC and .TBW files. .LTC files simply .LTA files that have been compressed. .TBW files are a binary representation of the .LTA file. .TBW files load and process faster than .LTAs or .LTCs, so you’ll probably want to save your worlds as .TBW files in most cases.

Textures — LithTech uses its own form of texture, the .DTX file. Textures can be up to 32-bit images, although you can obviously choose to make lower-color textures. The .DTX files also contain flags for additional information used by the engine and the game. You can convert .PCX and .TGA files into .DTX files by importing them inside of DEdit.

Sprites — Sprites (.SPR files) consist of a series of .DTX files linked together as an animation with a set frame rate. They’re commonly used for animations and special effects such as smoke, bullet holes, and liquid droplets.

Sounds — LithTech supports standard .WAV files directly with no custom modifications.

Models — Models in LithTech are in a custom format, the .LTB file. This contains the mesh/geometry for the model and other information used by the game engine. You create these files in an external editor such as Maya or 3D Studio Max, and then save them in the .LTB file format using a plug-in. Use ModelEdit, to modify files in the .ltc format once they’ve been created.

Objects — Also known as Entities, these are objects that programmers construct using code. Some of this code exists in the engine and doesn’t appear in the project directories. However, many objects are created in code written for the specific game. These objects are called game objects (to distinguish them from the engine objects inside the engine code) and are stored in a file called OBJECT.LTO in the same directory as the project’s .DEP file.

Prefabs — A prefab is a collection of objects, both brushes and code objects that are stored in their own .ltc files (just like a regular game world) in a separate set of directories. Anything you make in a level can be exported as a prefab to make it easier to re-use later. Examples are benches, camera systems, hallways, doorways, and statues. Prefabs can be useful if your group needs a way to distribute standard-looking objects to its members.

Setting up the Editor

Once you have DEdit installed you will need to set the proper paths for it to work with the game. Click on DEdit.exe in the Tools directory and set up the following:

At the top of the editor select Edit/Options. This will bring up the DEdit options menu.

The paths are set under the Run tab.

The first box is for the executable and should point to the Lithtech.exe in the TRON 2.0 directory.

The second box is where you set your working directory.

The final box is for the program arguments. It is a set of commands for running the game and should be as follows -rez Game +errorlog 1 +runworld %WorldName%

Select ok to close that window. Now you need to open a project. At the top of the editor select File/Open Project. Browse for your TRON.dep file in your Game directory and select it.

This should set the editor up for the game. I suggest closing and reopening DEdit after this is complete to save your changes.

Setting up Preferences

Once you have DEdit working with the game you can adjust the preferences to suite your needs. These are also located in the DEdit options menu, which can be found by selecting Edit/Options from the top of the editor. The editor works fine as is, and changes are only recommended if you are having performance problems, or for advanced users who want to adjust their settings.

For better performance you can lower the Number of Undos stored, which can be found under the miscellaneous tab.

Lowering the Default far Z setting under the Viewport tab also has performance benefits. This is the distance the editor sees in the 3D window, the value is in units. This is best left alone if you aren’t working on a large and complex level.

Most of the other settings in the DEdit options menu are for preference.

There is also a list of key bindings with options to change them. This can be found by selecting Edit/Edit Key Configuration from the top of the editor.

The DEdit User Interface

The callouts in this screenshot illustrate the various sections of DEdit’s UI. Use the buttons in the Toolbars to make new worlds, switch modes, and run your world. You can learn an individual button’s function by hovering your mouse over it to get a Tool Tip.

In the Project Window, DEdit gives you access to all of the resources in the game. Most tabs represent a resource you can add to the game. There are two special ones (Properties and Nodes) that relate to objects inside your maps. We’ll discuss all of these in a later section and they’re documented in the DEdit Toolbars chapter as well.

There are four viewports that provide windows onto the world you’re building. Each one presents a different view of the world. The upper left window shows you a Perspective view shot from a movable camera point in the level. The other three views have a fixed-view camera that displays either Top, Front or Left view (going in clockwise order). You’ll spend a lot of time working with these views.

In the Status Bar, DEdit provides information about the level or about the view you’re currently in. We’ll get into the depths of the user interface in later chapters, although you’re welcome to stop and explore if you’d like. Use the Tool Tips and the Status Bar to learn more about what the controls do.

Building a Room

This will be a simple tutorial on building a basic room using the tools supplied with DEdit. Further detail and explanations of the elements can be found after the tutorial section.

Select the Worlds tab on the left side of the editor in the Project Window and highlight the Worlds folder. From the toolbar at the top of the editor press the New World button. Name the new world Test_1.

DEdit is divided by four viewports to work in. You can adjust the grid size in each view by holding the mouse cursor over it and pressing the + and – keys. The grid size is indicated on the bottom of the editor on the status bar. Keep the grid size at 64 units for now. Using the viewport on the top right of the editor. Move your mouse cursor to the top left corner of it and hit the spacebar once. This should have placed a point on the grid and left you with a line that is connected to the point and your cursor (Figure 1.). You can hit the backspace key at anytime in this process to remove the last point.

Figure 1.

Now move the mouse cursor to the top right corner of the viewport and hit the spacebar again. You should now have a straight line that draws across the top of the viewport with a point still connected to the cursor. Do this again in the bottom right corner, bottom left corner, and then over the first point you made to make a square. This should conclude your square and a new brush dialog window should pop up asking for a thickness value to make it a cube, 256 units is fine for now. You should now have a cube of some sort that is visible in all viewports (Figure 2.).

Figure 2.

Holding your cursor over the top right viewport, try holding the O or I key and move your cursor around. The O key will zoom your view in and out (your mouse wheel will also do this), while the I key moves your view along the plane. All three 2D viewports work like this. Move your cursor to the top left viewport, which is your 3D or perspective view. In this view hold down the O key and move your mouse around, this pivots the view from the point where your camera or view position is. If you hold down the O key and press the left or right mouse buttons it will zoom your view in and out. Holding down the I key in this view will allow the mouse to move along a plane, combined with pressing your right mouse button will move it vertically. The U key will deselect an object; you can simply click on the object with your mouse to select it again. With the brush selected you will notice it has handles on the corners, along the edges, and in the center in your 2D views. These are for sizing and positioning the brush. In the bottom right corner of the editor on the status bar there is a readout for the dimensions of the selected brush. By selecting the handles and stretching them in the different 2D views, make the brush measure 512x256x512. On the left portion of the editor in the project window there is a selection of tabs. Select the textures tab and pick a texture to place on the brush. Select a texture from one of the folders in the Prototype directory to apply to the brush. The texture should now show up in a window just below the selection menu. With the texture and the brush selected, press the Apply Texture button on the top toolbar to add this texture to the brush. With the brush still selected hit the F key to flip the normals on the brush. This turns the brush inside out basically so that there is now an interior space.

With the brush still selected press the Marker to Selection button, and then the Center View on Marker button. This should position your view on the space you created. Right click in one of the viewports and select Add/Object, This will bring up a Select Object Type window. From the Class Types menu select GameStartPoint and then select ok, this adds the starting point from where you enter the level when in the game, this is an object.

There are three modes for selecting and working in DEdit: Brush Edit, Geometry Edit, and Object Edit. You will need to press the appropriate button on the top toolbar for which mode you need to be in if you deselect your object at this point. Notice that when adding new objects they appear in the middle of the marker (the big green crosshair looking thing). You can move the marker in the 2D views by holding the X key and moving your cursor, or if you have something selected and you can press the Marker to Selection button to center up on it. At this point if you select the Nodes tab in the project window, you will notice you have two items in your node tree now. You can select from this list no matter what mode you are in. The node tree is a means of organizing your level in a manor that will make it easier to work on, as it grows larger in size and complexity. With the GameStartPoint object selected, move your cursor to one of the bottom viewports and press your down arrow key once.

In your top view using the right arrow key move it two spaces to the right. This will move the selected object one grid space down, which should leave it 64 units (one grid space) above the floor. The arrow keys are an optional way to move items in the editor. With the marker still centered on the brush right click on one of the viewports again and select Add/Object again. This time select the WorldProperties object from the ClassTypes window. The level will now run, but needs a light object placed in it or it will too dark to see anything. With the marker still centered on the brush, right click any viewport and select Add/Object again. From the ClassTypes window select the light object to add a light. Using the up arrow key in one of the bottom viewports, move the light up one grid space. It should now be one grid space from the top. What you should now see is a new box above the old one that is surrounded by a large sphere. The sphere is the radius within the level that the light will fill. Go to the Properties tab in the project window and look at the properties of the light. In most cases and entity’s properties are the most important tool used to control its behavior. In the case of lights, this is where you can change their size, brightness and color. The light’s current size (set in the LightRadius property) is 300. That’s probably a little small, so change the value to 600. In the viewports you’ll see the size of the light radius increase as well. Now it’s large enough to make a good-sized pool of light around the player. Now is a good time to save your level by pressing the Save Project button on the top toolbar. It’s a good idea to save your progress often when working on levels.

Before processing the level, a special brush needs to be added. This brush should be a box that contains all of the geometry and entities in the map. Using the steps above, create a large box shaped brush that easily encompasses the original room. With the brush selected, click on the Properties tab and change the Detail property from True to False. Each map should have a single Detail=False brush containing all other brushes and objects. Failure to add this brush or adding additional Detail=False brushes can result in unpredictable and undesirable behavior in the processed version of the map. It is often best to hide the Detail=False brush while editing and then verifythat it still covers all of the items in the map just before processing. When building a map, it is a good idea to keep a checklist in your mind of items that are essential for the map to process properly. This includes the GameStartPoint object, the WorldProperties object, some form of lighting, and a single Detail=False brush containing all of the other items in the map.

The level is now ready to process and run. Press the Process World button on the top toolbar, when the process window pops up select the Process button and press the Close button when it’s done. To run the world, press the Run World button on the top toolbar.

Adding a Second Room

This tutorial will guide you through the process of adding a second room to your level. This exercise requires that your grid size be set to 64 units in all your viewports.

Select your original brush you created in the editor either in the node tree or by left mouse clicking over it in one of the views while in Brush Edit Mode (found on the top toolbar). Select the Nodes tab in the project window, right click the top folder (Test_1) and select Add Container Node. This will create a new folder in the node tree. Name the new folder Room_1. You can name/rename a folder or item at any time by selecting it in the node tree and pressing F2 or right click the folder and select Rename. With your brush selected right click the new folder (Room_1) and select Move Tagged Nodes Here. This will move your brush into its own folder to make it easier to work with. Do the same with the light object you added to place it in the Room_1 folder.

Center the marker on the geometry that makes up the room. In the perspective you will need to position your view to the interior space of the brush. You will need to be in Brush Edit Mode (top toolbar) to work with the brush and the polygons that make up the brush. With the brush selected press Ctrl + J to disconnect the polygons that make up the brush. This should leave you with six individual polygons. In the 3D viewport select the wall on the right side of the room. If you’re not sure which one it is, keep selecting them until you see the line on the right side of your top right (top view) viewport highlighted with handles on it. With your wall (polygon) selected move to your cursor to the bottom left (side view) viewport. Move your cursor to the top of the polygon and one grid space left of center. Press the spacebar and it should create a point on the grid one space left of center. Move your cursor (making a straight line) to the bottom of the polygon and press the spacebar again. You should now have a straight line that follows one space left of center down your polygon. Press the S key to split the polygon. This is called a two-point split. You should now have a split down the left side of the polygon. In the 3D view select the polygon to the right (the right half of the wall you just split) of the split. With the polygon selected move the cursor back down to the bottom left (side view) viewport and make a split one grid space right of center (two spaces right of the first split) the same way you did the first one. This should leave your wall in three pieces (polygons). In your 3D view select the middle polygon of the wall and move your cursor back to the bottom left (side view) viewport. Your polygon should be two grid spaces wide and the full height of the wall. Grab the handle on the bottom center of the polygon by holding the left mouse button down on it and raise it up three grid spaces. There should now be an opening in the wall (Figure 3. shows 3D and side view).

Figure 3.

In your 3D view select all three of the polygons that make up the wall. You will need to hold down the Ctrl key while left mouse clicking each polygon. Holding down the Ctrl key while selecting allows you to select multiple items whether they are brushes, polygons, or objects. With all three polygons selected press Shift + J to connect or join them. You can now select anywhere on the wall and it will select the entire wall. With the entire wall selected move your cursor to the bottom left (side view) viewport and make a horizontal split across the entire wall that runs along the top of the opening you made (two grid spaces down from the top). You can do this the same way you made the vertical splits to create the opening. In your 3D view select all the polygons that make up the wall and join them again by pressing Shift + J. At this point the wall should be made up of five polygons that are joined (Figure 4.).

Figure 4.

In the 3D view select the wall again, the whole wall should select with one click since the polygons were joined. You will need to be in Geometry Edit mode for the next operation. With that wall selected press the Geometry Edit button on the top toolbar. Move the cursor to the bottom left (side view) viewport. The door opening is there but the geometry is incorrect. In Geometry Edit mode you will see at the corner of each polygon there is a little dot that highlights when you run the cursor past it, this is a vertex. For geometry to be clean, a vertex should always meet up with another vertex or be on a corner. If it sits an edge instead of another vertex, it creates what is called a t-junction and while the level processes, it will try to fix these on its own. It is better to build clean and avoid making the processor make the decisions on how to cut up the geometry for you. You will also get better lighting results if you build clean. With the wall selected and in Geometry Edit mode, in the bottom left (side view) viewport move the cursor over the vertex that is not in a corner on the left side of the wall (you should see it highlight). Hold down the M key and the left mouse button and drag the vertex up to meet with the one in the top left corner. Now using the same technique grab the top left vertex that meets the ceiling above the door and move it to meet up with the one in the far left upper corner (Figure 5.).

Figure 5.

Do the same thing for the ones on the right side, dragging them to the top right corner. The geometry around the door is now clean. The floor isn’t, but we won’t worry about it for now. At this point you can select all the walls in the room and join them using Shift + J to keep things manageable. You will need to be in Brush Edit (top toolbar) mode to select and join them.

We will now add a hallway. In the project window select the Room_1 folder in the node tree from the Nodes tab to highlight the room and press the Marker to Selection button on the top toolbar. This should center the marker on your room. Using the top right (top view) viewport zoom the view out (using the O key or mouse wheel) enough so that you could fit two rooms in the view. Using the same technique you used to create the first brush (Room_1), create a brush on the right side of the existing room that meets up with its edge and is centered. Make the brush two grid spaces wide and four grid spaces long (128 x 256). When the editor prompts you for the thickness after you connect the points to make the brush, 256 will work for now. You should now have a new brush that is highlighted, but doesn’t sit flush with the door opening. With the brush still selected, move the cursor to the bottom left (side view) viewport and drag the handles so that the new brush is the same size as your door opening. The brush will already have a texture on it since you selected a texture for the first room. At this point move your view out in your 3D window so that you can see the entire room and the hall (Figure 6.).

Figure 6.

With the hall still selected, press the semicolon ( ; ) key. This should have hidden everything except for the new brush you created since it was selected. To unhide all just press the apostrophe ( ’ ) key, but keep the other stuff hidden for now. With the hallway still selected press the Center View button on the top toolbar to center up your view on the piece you’re working on. Now press the Geometry Edit button on the top toolbar to go into geometry edit mode. In the 3D view, position yourself at either end of the hallway and hold the cursor over the polygon. You should see the edges of it highlight red when doing this. When all the edges around the polygon are highlighted red, press the Page Down button to delete it (Figure 7.).

Figure 7.

You can hit Ctrl + Z at anytime to undo your last action, you can also select undo at the top of the editor with Edit/Undo. Delete the polygon at the other end of the hallway the same way. You will now need to go back into Brush Edit mode (top toolbar). Once back in Brush Edit mode, with the brush still selected press the F key to flip the normals (turn it inside out). You should now have a hallway that is open on both ends. Press the apostrophe ( ‘ )key to unhide the rest of the level. In your node tree make another container like you did for the room and name it Hallway. With the hallway selected right click on that folder and select Move Tagged Nodes Here to place the brush in that folder.

Select the hallway and press the Marker to Selection button (top toolbar) to center the marker on it. In the node tree select the entire Room_1 folder, this should select all the geometry and the light object that make up the room. With the entire room selected go to the top of the editor and select Edit/Copy and then Edit/Paste Alternate. This will create a duplicate of that room sitting in the same world space as the original, folder and all. With the entire new room still selected move the cursor to the top right (top view) viewport. While holding down the Ctrl key press the right arrow key four times to rotate the new room into position. When you rotate items, the editor uses the marker center as the rotation center point. With the marker centered on the hallway the new room should rotate around it and sit right into the correct position. If things aren’t set up so handy, you can always rotate off any given point and manually move it into position by dragging it with the mouse, or nudging it with the arrow keys. Now in the node tree rename the new folder to Room_2 by highlighting it and pressing F2, or by right clicking it and selecting to rename it. You should now have two rooms connected by a hallway. Save your work, process it, and run it.

Applying Textures

Applying the proper textures to there surfaces is a key element in making a level feel like an actual place. This tutorial will guide you through some of the texturing basics in DEdit using the level you just created. It will also cover some basics in brush properties.

Select the Room_1 folder from the node tree and press the semicolon ( ; )key to hide the rest of the level. In the 3D viewport, move you camera view inside the room. You will need to be in Brush Edit mode (top toolbar) to start out. Inside the room, select the polygon that makes up the floor. Under the properties tab in the project window there should be some basic properties for this polygon. Select the dropdown for the lighting field and change it to lightmap. On larger polygons such as floors and ceilings changing the lighting to lightmaps will look better, but at a cost. Lightmapping is a performance hit to the engine and should be used sparingly. Select the polygons that make up the ceiling and walls, and do the same thing. Now select all of the walls that make up the room. At the bottom of the editor you will see the room size is 512x256x512. This means that your wall height is 256 units, and the SWSib030 texture that was applied to the room is 256x256 so it fits nicely. Right click in any of the viewports and select Texture/Map Texture Coordinates. This will bring up a new window that allows you to manipulate the texture size and position. The top portion of the window is for adjusting offsets. The wall texture should already fit correctly but feel free to adjust the offsets to see what they do. Just select cancel when you’re done so that the texture remains as it was. Press the U key to deselect any geometry and go into Geometry Edit mode (top toolbar). Explore to Tex/Prototype/M02/Courtney/BinM02X in the Textures tab in the project window, and select the texture M02X_W08. In your 3D viewport highlight the floor by moving the cursor over it, you will see the edges turn red. Press Ctrl + T while the polygon (floor) is highlighted to change the texture to the new texture. Do the same thing for the ceiling using the M02X_W08 texture. You can view all the textures in a set by right clicking on the list and selecting View Texture Palette.

Tip: In Geometry Edit mode you can highlight a texture on a surface by holding the cursor over it and press the K key to have the editor align it for you. You may have to press it a few times since it lines the texture per edge and may not pick the edge you want to use first try. You can also press Shift + C to have it fit the texture to a surface. Note that this will stretch the texture to fit and it may need to be manually adjusted in the Map Texture Coordinates window to adjust it to look proper.

Adding Prefabs

Prefabs are pre-assembled sets of geometry and sometimes include objects such as Lights or worldmodels. Prefabs are a quick way to bring a level to life if they are already made. They are a very efficient way to build for items that are going to be used more that once. Also, you can make changes to a prefab on its own, and it will update the changes across the level/levels globally for that prefab the next time the level is loaded in the editor.

Start with the existing Test_1 level. Select Room_1 from the node tree and hide everything else. Add a container node in the Room_1 folder and name it Prefabs. If you go to the node tree and highlight the new Prefabs folder and press F3, it will make this folder the parent folder. The prefabs you add will now automatically be placed in that folder. If you create an object such as a light fixture or control panel that will be used repeatedly in your maps, you can select all of its components and then choose Save as Prefab from the Selection menu to add it to the Prefabs directory for later use. Try creating a simple prefab such as a textured cube similar to the Datablocks used in TRON 2.0. Now go to the Prefabs tab in the project window and select your prefab. Double-click the prefab to add an instance of it to the map. You will need to be in Object Edit mode to select prefabs with the mouse in the editor. You can select anything from the node tree no matter what editing mode you are in. Once the prefab is selected, it’s position can easily be adjusted using the up or down arrow keys. You should now have a general idea how the prefabs are used and you can add whatever prefabs you choose to furnish the area at this point. Some prefabs may have objects in them to allow the AI to interact with them in game. If you place these and don’t have AI volumes in yet you will get runtime errors in game, but the level will still run. After an instance of a prefab is added, it can be customized by clicking the node and then choosing Disconnect Prefab. This option allows the prefab to be edited, but it will also stop it from inheriting changes made to the root prefab from which it was derived.

Adding a Sky

This will be a simple tutorial on adding a skybox to your level. We will be using the Test_1 level for this exercise. Set the grid size to 64 in your 2D views.

Holding the cursor over any viewport press the apostrophe ( ’ ) key to unhide all of your work. You will need to be in Brush Edit mode for the next step. In your node tree, select the top folder and add a new container to it. Name this container Sky and press F3 with the new folder highlighted in the node tree to make it the active parent folder. In the top view viewport, using the spacebar make a box around the level that has a one unit space between it and the rooms all the way around. When you complete the box and it prompts you for a thickness, 256 units will work for now. Position and size your brush so that there is a one-unit space between it and the rooms in your side view viewport (Figure 8.). You will now need to flip the normals on the brush by pressing the F key while it is selected to change it into an interior space. Your rooms should now be sitting inside of the new brush. With the new brush selected go to the Textures tab in the project window. Explore to the root Tex directory, select the Sky texture, and press the Apply Texture button on the top toolbar to give your brush the new texture. Now you will need to go to the Properties tab in the project window and change the brush Type from Normal to SkyPortal using the dropdown. This flags the selected item to use the information from a Skybox that we are about to add.

Figure 8.

In the top view viewport zoom your view out a bit using the O key or the mouse wheel. Move your marker using the X key so that it is positioned outside of your level (the rooms). Create a 512x512x512 unit box-shaped brush, flip the faces with the F key so that they face inward and then apply a texture of your choosing. With the brush selected, press the Marker to Selection button to center the cursor at the brush’s center, right-click, choose Add Object and add a DemoSkyWorldModel. In the Nodes tab, highlight the new brush and then drag it underneath the DemoSkyWorldModel. This action binds the brush to the DemoSkyWorldModel so that it inherits the properties of its parent. Select the DemoSkyWorldModel, click on the Properties tab, click on the SkyDims field and then change the dimensions to 256x256x256. This will expand the DemoSkyWorldModel so that it just encompasses the brush. The size of the DemoSkyWorldModel can be further adjusted by selecting it, going into Object Edit Mode by pressing Ctrl + H and then resizing the DemoSkyWorldModel in the same manner that you would a brush. Add a light to the center of the DemoSkyWorldModel to light the brush. Increase the light radius to 600 so that the brush is completely illuminated. These steps allow you to create a simple sky. To save time when building maps, try adding all the elements used to create the sky except the sky portals to a single node and then use the Save As Prefab option. To view the sky, disconnect the polygons of one of your rooms by pressing Ctrl + J, delete one of the wall polygons to create a window and then process the map. The sky should be visible outside through the window when the map is run.

Adding Basic AI

The TRON 2.0 AI systems are highly advanced and rather complex. Adding a complete set of AI that will behave in a realistic fashion under all conditions is beyond the scope of this document. However, the basics of adding AI are simple. This section will show you how to add a single patrolling AI that will attack when it sees the player.

First, load the Test_1 world, and then save it as Test_2. Then, select Room_2 from the node tree and hide everything else. Next, add an AIRegion object and place it somewhere in the room. It’s exact location is not important. Now add an AIVolume object at the center of the room, and expand its size until it almost fills the horizontal dimensions of the room without actually intersecting with any walls. Note that the AI use these Volumes to determine where they are allowed to go, so AI volumes that intersect with walls can allow the AI to walk right through. When done, click on the properties tab, and type AIRegion0 in the Region field.

Now that the volume is placed, add 2 AINodePatrol objects to the level and place them at opposite ends of the room. Make sure that the nodes are positioned within both the horizontal and vertical boundaries of the Volume, or the AI will not be able to reach them. At this point, you must modify the Next property of each node so that they point to each other (i.e. AINodePatrol0 points to AINodePatrol1 and vice versa).

Now that the AI environment has been established, it’s time to add an AI. From the World menu, select Add Object, then click on CAI from the object menu, and then select CAIHuman. Make sure that the AI is placed somewhere within the horizontal boundary of the AIVolume, or it will not be able to move when you run your world. When it’s in position, click on the Properties tab. For ModelTemplate, type in or select IC_Regular. For Brain select ICRegular. For GoalSet, select ICRegularPatrol. Finally, Next, click on the Attachments property, and select ICRegularDisc from the RightHand field. When done, click on OK to close the attachments window.

To learn more about working with AI, see the TRON 2.0 AI and TRON 2.0 AI Gameplay Setup sections of the TRON 2.0 help file.

Creating Multiplayer Levels

TRON 2.0 contains three multiplayer modes: Disc Arena, Disc Tournament and Lightcycles. When creating new maps for these play modes, certain objects are required and some conventions must be followed for the maps to function properly. Disc Arena and Disc Tournament maps can be identical and function properly in both modes. Below is a brief checklist of items needed to create maps for all modes.

Disc Arena and Disc Tournament

-Each map should have four separate arenas and a spectator area.

-Each arena should have a single Arena object at its center. It’s usually best to follow the naming convention of Arena_01, Arena_02, etc. If you have items that change during each match such as disappearing platforms or keyframed objects, a message should be sent to reset them to their original state after each point. The best way to do this is to put all of the reset commands into a single Trigger and then activate the Trigger by adding a message to the OnPointEnd field of the Arena object (i.e. “msg Arena1Reset trigger”).

-Each arena should have at least four ArenaStartPoints for each team. After adding an ArenaStartPoint, its Team and Arena can be specified in its properties by using the Type and Arena fields, respectively. In addition to the four ArenaStartPoints for each team that are in the Arena, four more ArenaStartPoints should be added in the spectator area for each team. The spectator ArenaStartPoints can be anywhere in the spectator area but it’s usually best to put them near the window that overlooks the arena in use. That way, when people respawn in the spectator area, they can easily watch the remainder of their team’s point. To create the spectator ArenaStartPoint, just set the Type field to Spectator and the Arena field to the appropriate arena.

-Each map needs to have a text file named “mapname”info.txt (without the quotes) in the same directory as the map. This text file defines the subroutines that will be available in the map. A sample is provided in the samplemaps.rez which can be copied and renamed to your map name. For example, if you’re making a new Disc Arena / Tournament map called Tronolith.dat, you would save the map to C:\Program Files\Buena Vista Interactive\Tron 2.0\Game\Worlds\RetailMultiPlayer\DiscArena. You could then make a copy of DiscArena01info.txt (from samplemaps.rez) and rename it to Tronolithinfo.txt.

-If you would like to eliminate falling damage from the game, this can be accomplished by creating a large brush that fits around the world and binding it to a SafetyNet object, which is a form of VolumeBrush. Similarly, if you want to make an instant kill brush for bottomless pits, it’s best to create a VolumeBrush that administers damage, such as the EndlessFall type, with a negative value (-1000) to instantly kill any player that enters it. Please note that the SafetyNet and EndlessFall brushes should not intersect, but should instead be adjacent to one another.

Lightcycles

-Lightcycle arenas should be set up so that all of the action occurs on a single plane. When a Lightcycle makes contact with a wall, another lightcycle or another lightcycle’s trail, it will be destroyed.

-At least eight GameStartPoint objects with their GameType set to MuliplayerLightcycle should be added to the map. They should be at least 128 units above the ground plane and be evenly spaced to give all players equal advantage. Each GameStartPoint should have “msg MPStart trigger” entered in its command field. See below for details.

-A number of Spectator objects should be placed in the map to provide good vantage points for players who have either been defeated or have not yet joined teams.

-Two triggers should be added to regulate any objects used to provide gameplay during a match such as powerups, speed zones or other obstacles. These types of items should be initialized at the start of each point. To do this, create a Trigger called MPStart. If the GameStartPoints are set up correctly, this Trigger will be activated at the start of each point. Messages can then be added to MPStart to activate any powerups, speedzones or obstacles that should be active during the point. Similarly, another trigger should be added named LANClean. This trigger is activated automatically by the game when the point is won and it can be used to remove any powerups, speedzones or obstacles so that they are correctly initialized when the MPStart trigger sends out its message at the start of the next point.

The steps above are the minimum required to create a custom multiplayer map working. Once the basics are set up, an infinite number of combinations can created by just using new geometry or textures or by integrating other game objects.

Lighting Basics

Working with Light Colors

A property you may want to modify is the light’s color. To change the colors, click on the color sample button next to the property name. Start by clicking the white button (LightColor). The dialog that comes up is a standard color picker dialog, and it allows you to pick from a standard palette or create your own custom colors. Choose one of the very light blue colors for something similar to a fluorescent light. You can use the slider on the far right to lighten or darken the color to your taste. When you’re done, close the dialog and you’ll see your new color in place on the LightColor button. Lastly, you can set the brightness of the light using the BrightScale property. At its default setting of 1.0, the light appears at a normal brightness. If you change the value of BrightScale to 0.5, the light’s brightness is halved. However, the radius stays the same. Thus, you can create a very large light that doesn’t overwhelm the area closest to its center. Likewise, if you want an intensely bright light, you can increase the BrightScale value to 2.0, which will make the light much brighter. For now, leave BrightScale as it is.

There is another useful type of light with very different behavior from the regular one: The DirLight. While a normal light throws light in a sphere all the way around it, a DirLight acts like a spotlight: It throws light in a cone, the diameter of which you can control.

The Dirlight

A DirLight is a directional or spotlight. You can aim a Dirlight using the object’s Rotation property. Click the button next to the property’s name and you’ll see a dialog appear. Within this dialog, you can control every aspect of the object’s facing. Each of the three aspects has a range between 0 and 359. Yaw controls the horizontal facing of the object, and is aligned identically to the Top viewport like a compass needle. You can use the preview display at the top of the dialog to see how the results will appear. A setting of 0 points the object straight “north,” towards the top edge of the Top viewport. A setting of 90 would aim “east,” a setting of 135 would point “southeast” towards the lower right corner of the viewport and so on. For now, set the yaw to 180 to spin the Dirlight around so it’s facing the opposite direction.

Pitch controls the vertical angle of the object. The Pitch preview display shows the result of your changes. Since the Dirlight is pointed at the proper angle already, there’s no need to change this.

The Roll control controls the spin of the object. This is useful mainly for props or cameras, where you want the object to bank or its viewpoint to sway.

World Ambient Light

You can add an overall ambient light value to your entire level. In the editor press Ctrl + W to bring up your World Info window. Enter AmbientLight R G B in the field with the R G B being light values for Red, Blue, and Green. An example for this would be AmbientLight 12 12 12. This would give the level a dim overall lighting with white light since the RGB values are all equal. It isn’t recommended to light the entire level like this without using the light objects. The world ambient lighting does not cast shadows and will give the level a flat overall look when used on it’s own.

Lighting Properties on Brushes

With a brush or polygon selected, you can change the way it is effected by lights in two ways. In the Lighting field generally Lightmap or Gouraud will be used for the basic lighting style. Gouraud lighting takes the light sample from the vertices to light the brush. This is the preferred method to light the majority of your world. On larger brushes or where a vertex meets an edge the results may not look very good. Keep in mind where your vertices are when placing lights in your level, and try to place the light source near them. Lightmapping creates better looking results on larger planes, but at a cost to perfomance. When a polygons is set to Lightmap you can optionally change the lightmap grid size. This can be found in the LightControl field. By selecting it, it will open a new dialog with a field in it named LMGridSize. The default value for the field is 20 and the shadows become more defined as the variable is decreased. Note that halving the value makes a quadruple hit to the performance. It is recommended only to decrease the value in isolated instances. Generally a value between 6 and 10 will give you a pretty defined shadow where you feel it may be necessary.

Glass

To create glass, simply bind a brush with a glass texture to a WorldModel object and adjust a few fields under the Properties tab in the Project Window. Set the DebrisType to Window, the SurfaceOverrride to Glass, and the BlendMode to Translucent. The Alpha field dictates the opacity of your glass, with 1.0 being opaque, decreasing the value makes the glass more transparent. Generally the Alpha on glass is set to about 0.5.

Occlusion

An occluder is a plane with the brush Type set to Occluder. Occluders are most effective when they are axis aligned (not set at an angle), it is not recommended to place them otherwise. Occluders are placed to block the engine from drawing geometry that is not visible to the player, thus reducing the number of triangles drawn by the engine. The geometry of a level is divided into renderblocks, with each renderblock containing 2,000 triangles. Any geometry that is associated with a worldmodel will draw it’s own renderblock regardless of the number of triangles within it. If a renderblock cannot be seen by the engine from the players perspective the geometry contained will not be drawn by the engine. When possible it is best to run them a good distance through the geometry if they lead to an area where the player couldn’t see in game anyways. This will assure they cover as many renderblocks as possible. Occluders do eat up resources at runtime, so the should be used sparingly and efficiently. Small occluders are not very effective since the majority of renderblocks are rather large and would not be hidden behind them. There are two types of occluders, dynamic and static.

Static Occluders - Static occluders are always on and occluding the geometry behind them. They are best suited placed in walls, ceilings, and other larger pieces of geometry, which the player could not see through anyway. If a static occluder has bad placement it is most likely you will see geometry popping in and out when running the game.

Dynamic Occluders - Dynamic occluders are set-up to work in conjunction with a volume. When a player is in the volume the occluder is active, it becomes inactive when the player leaves the volume. The dynamic occluder is valuable to hide large sections of geometry when the player is in an area where the geometry is not visible anyway. To make a dynamic occluder volume you can just create a brush that you want to act as the volume. Center the marker on the brush and right click any viewport and select Add/Object, from the Class Types menu select and add the DynamicOccluderVolume object. Select the brush you created for the volume, and in the node tree place the brush under the DynamicOccluderVolume object. With the DynamicOccluderVolume object selected go to the Properties tab in the project window. Notice there are fields for occluder names. Enter the name of the occluder/occluders you want to be active when the player is in the volume in these fields. It is best to give the dynamic occluders special names to make them easier to keep track of when using them. You can rename them in the node tree, and example would be Dynamic_01.

Objects

Below is a list and basic description of game objects used in the creation of TRON 2.0. If you have a question about the meaning of any of the available properties of an object, you may access the online help built into DEdit by placing your cursor over the property in question until the cursor is replaced by a question mark. Left click to display a definition of that property.

AIInfoVolume

Volumes placed to send information to the AI when a player is within the boundaries.

AINode

Nodes placed to relay information or instructions to the AI.

AIRegion

Objects used to group the AI volumes into regions of a level. This divides the level into unique areas for the AI’s search behavior.

AIVolume

Volumes placed for areas the AI can travel in. Some have special attributes to inform the AI of actions to take while in the volume.

AmbientOverride

You can assign an ambient value to brushes that are placed under this object in the objects properties. Note that individual brush ambient values are ignored when under this object.

AmmoBox

AmmoBoxes are placed in the world as a powerup. Each Ammobox can contain up to ten different kinds of ammunition. This item was not used in TRON 2.0.

Archive Bin

Archive Bins are placed in the world as a means for the player to acquire subroutines or e-mails. Each item can have a separate energy and permission set requirement.

Arena

The Arena object is used to identify one of the four arenas for Disc Tournament and Disc Arena. Typically one Arena object is placed at the center of each Arena.

ArenaStartPoint

ArenaStartPoints are placed in the multiplayer Disc Tournament and Disc Arena maps to identify points where players will spawn into the world.

Binary Bit

The BinaryBit object is a multi-purpose switch of sorts that can be used to trigger events, open doors or send any type of message. A permission set required for activation can be specified.

BuildNote

BuildNote objects can be aquired by the player to increase Jet’s version number.

CAI Human

This is the object used to place AI in a level.

Camera

Cameras show scenes in the world outside the player.

CameraPoint

Camerapoints are used to provide points to move the camera to during cinematics.

CinematicTrigger

This is a controller object used for cut scenes and in game dialog.

ClientLightFX

ClientLightFX allow for the quick creation of complex dynamic lighting effects. However, dynamic lighting must be enabled for these effects to be visible.

CommandObject

Objects placed to execute, track and time a series of events and/or commands.

Controller

This object controls properties of up to 8 objects.

CThorne

CThorne is a special object used to create the Thorne character during cinematics.

Decal

An object to place decal textures under, allowing textures with an alpha channel to be placed overlapping standard textures.

DecisionObject

An object placed to give the player multiple choices they can make.

DemoSkyWorldModel

DemoSkyWorldModels allow objects to render in the skybox in a single step. A DemoSkyWorldModel is an object that fuses a WorldModel and a SkyPointer. By doing this, binding a brush to the one object allows it to be rendered in the skybox without the need for any additional objects.

Dialogue

An object placed to message dialogue for the AI to use.

DirLight

DirLights act like a spotlight, shining only within an arc that you specify instead of in a sphere like a regular light. You can aim them to any angle you choose.

DisplayMeter

This is an incremental colored bar meter displayed on the screen. It is useful for “boss” fights.

DisplayTimer

This object displays a timer on the screen in game.

DynamicOccluderVolume

The object used to create a volume by placing a brush under it. When the player is in the volume, the occluders indicated in the volume will be active

EdgeGenerator

This object can be used to bevel polygonal faces. In practice, it was rarely used in the creation of TRON worlds as it created too many polies.

EventCounter

This object will store up to 5 different "events", with each event containing an integer value and two commands. The idea is that the game code can increment/decrement the EventCounter's value (by sending ”Increment” or “Inc” and ”Decrement” or “Dec” messages). When the counter’s value is equal to one (or more) of the EventXValue (i.e., Event1Value, Event2Value, etc.), either the EventXIncToValCmd or EventXDecToValCmd will be processes. In other words, how the counter gets to the EventXValue determines which command is sent. For example, if Event1Value = 2, and the EventCounter’s staring value is 0, if the EventCounter gets 2 “Inc” messages, the Event1IncToValCmd will be processed. If at this point the “Inc” message is sent again (so the counter is now at 3), and then the “Dec” message is sent to the counter, the Event1DecToValCmd will be processed. This object also understands the “Lock” and “Unlock” commands (Inc/Dec don’t have any effect on the counter if it is locked).

Explosion

This is an object used to place explosion effects in the world.

Fire

This is an object used to create fire effects.

GameStartPoint

This is the point that the player enters the game world.

GearItem

This is an object used to place gear power up items in the world.

Group

This is an object used when you wish to send the same message to several different objects at once. It acts as a simple relay.

InfoString

The InfoString object causes a line of text to appear on screen when the player’s targeting reticule is trained on the object. For the string to be valid, it must be contained within the cres.dll.

InsideDef

This object was not used in the creation of TRON 2.0.

IONode

This object was used for the IONode dialogue scenes in TRON 2.0.

JumpVolume

This object was not used in the creation of TRON 2.0.

Key

This is an object used to define a point in the path of a keyframed object.

KeyFramer

This is an object used to define a point in the path of a keyframed object.

Light

This is a basic point light, or omni light object used to light the world.

Lightcycle

The Lightcycle object is used to create enemy AI Lightcyclists.

LightcyclePowerup

This object is used to place Lightcycle powerups in the world.

LightcycleVolume

Similar to an AIVolume, the LightcycleVolume defines where Lightcycle AI can navigate in a map. Unlike regular AI volumes, these volumes define the areas that Lightcycles should not go. For example, if you build a map with a column sticking up in the center, a LightcycleVolume should be placed around it to prevent the Lightcyle AI from colliding with it. These volumes should be placed parallel to the groundplane and flush with it.

LightcycleVolumeCascader

When triggered, this object starts triggering the nearest Volumes, moving outward at a fixed rate.

LightGroup

This object was not used in the creation of TRON 2.0.

Lightning

This object was not used in the creation of TRON 2.0.

ModItem

This object was not used in the creation of TRON 2.0.

NodeLine

This object was not used in the creation of TRON 2.0.

ObjectiveSprite

This object was not used in the creation of TRON 2.0.

ObjectLight

This is a light that only affects models.

ObjectRemover

ObjectRemover contains several "groups" of objects. For each group, you may list up to 10 objects. Specify how many groups of objects you wish to keep in the "GroupsToKeep" property.

On the first update, the ObjectRemover will randomly select the groups of objects it will keep (based on how many were specified to keep), and remove all the objects in all the other groups, and then remove itself.

Optimizer

The Optimizer provides a means to upgrade a subroutine to the next level. Optimizers can be keyframed to follow paths or stationary.

OutsideDef

This object was not used in the creation of TRON 2.0.

ParticleSystem

Any time you want to spawn a large number of similar simple objects in one location or area, you probably want a ParticleSystem object. Particle systems create a cloud of objects, usually sprites or simple models. They can make the sprites move, determine the area where they appear and how long they remain after being created.

PatchRoutine

This object provides a way for the player to replentish Health or Energy.

PlayerLure

This object allows the player to be keyframed while still maintaining some degree of control.

Point

This object was not used in the creation of TRON 2.0.

PolyGrid

A polygrid is a grid of triangles that can have an animating surface. They’re used to simulate flags, curtains, water, force fields and many other effects.

PolyGridModifier

This object was not used in the creation of TRON 2.0.

Prop

The Prop object is used to place .ltb models into the game world. Props are typically things that would be too complex or impractical to be created from world geometry. Examples would be plants, telephones, detailed furnishings, etc.

PropType

This object is a subclass of the Prop object. This is a different way of managing prop placement in levels. We found that a lot of the props that we placed were set up the same as each other. Yet we still had to set all of the flags. The PropType object places props by way of a simple dropdown menu. The dropdown menu refers to a bute file where the all of the prop flags have been predefined. Since it is a subclass of the Prop object, it shares many of its properties.

RandomSpawner

The RandomSpawner is used to spawn objects randomly through multiple Spawner objects.

RenderGroup

Items placed under this object can be triggered to hide and unhide from within a DynamicOccluderVolume.

RotatingWorldModel

These are objects that spin on any given axis. The most common example of a RotatingWorldModel would be a spinning fan.

ScaleSprite

ScaleSprites are free-standing textures that don’t need a surface to appear on. ScaleSprites get compounded into a lot of other game objects, but they can be used on their own to make a lot of things happen too. ScaleSprites are used for all kinds of things — halos around lights, floating symbols, decals on walls and objects in the sky.

ScreenShake

The ScreenShake object shakes the camera when triggered.

SecRezzerPoint

ICs will spawn at these points when the SecRezzer alarm is activated.

SkyPointer

SkyPointer objects allow the objects that they target to render in the skybox of the level. Only WorldModel-derived objects and Sprites can appear in the skybox.

SoundFX

This object allows you to place sounds in the world.

Spawner

This is a generic object used to “Spawn” objects into the game world.

Speaker

This object is used in conversational dialogues in a cinematic trigger. If a character needs to have a conversation with a non-AI object such as an intercom, this is the object that will fill the position of that AI in the conversation.

SpecialFX

This object allows of the quick creation of certain special effects.

SpectatorObject

SpectatorObjects define viewing points for multiplayer Lightcycle players who have either not yet joined teams or been derezzed.

Sprinkles

This object was not used in the creation of TRON 2.0.

StartupCommand

Placed in a level to give commands to objects within the level when the level is loaded.

StaticSunLight

The StaticSunLight object supplies levels that have a skybox with light from a sunlike source. The light radiates into the level through all skyportal brushes as if from an infinitely far point. This sunlight’s direction is determined by the rotation of the StaticSunLight object. Its position doesn’t matter, since the emitted light acts as if it comes from an infinite distance. The StaticSunlight’s position is ignored.

Steam

The Steam object is a form of the ParticleSystem object that has been set up to more easily create particle effects resembling jets of steam. The effect created by this object travels down the forward facing vector of the object.

TeleportPoint

This object is used to define the position and rotation of a point in space that the player or an AI can be moved to instantly.

TextureFX

This object was not used in the creation of TRON 2.0.

Trigger

Triggers are placed in a level to send messages or commands to other objects when a player or AI enters or passes through them.

ExitTrigger

This object is a subclass of the Trigger object. This object is used to trigger the end of a level.

TronTurret

This object is a turret-style AI that was keyframed to create the Tanks.

VolumeBrush

Volume brushes are used for a number of effects — Water, damaging environments, ladders, and to relay physics instructions such as gravity changes to name a few. A VolumeBrush object is designed to bind to a brush and use the brush to determine its area of effect. If the effect is continuous, such as snow, it only occurs within the space defined by the brush. If the effect happens to players and AI’s, it only happens to them when they’re within the volume. The effects of the volume are triggered when the player enters the space and usually un-triggered when they leave.

VolumeEffect

Used to place ScatterVolumes and SnowVolumes.

WeaponItem

This is an object used to place Weapon power up items in the world.

WorldModels

General

The naming convention should be mentioned first. There are three basic types, WorldModels, Doors, and Switches. Each of these three basic types has different movement types as prefixes describing how they behave. “Rotating” means the objects will rotate around a point a specified number of degrees around each axis (much like the NOLF HingedDoor). “Sliding” objects will move a specified number of units in a specified direction (much like the NOLF Door), think of the behavior of a desk drawer. “Spinning” objects will spin around a point in a specified number of seconds on each axis (much like the NOLF RotatingWorldModel), think of a ceiling fans behavior. Each movement type has identical properties and behaves exactly the same so when you are learning how to use a RotatingWorldModel you are also learning the RotatingSwitch and RotatingDoor. However, even though a RotatingWorldModel can be used exactly as a RotatingDoor you should NOT put a RotatingWorldModel where a Door should go, and vice versa. Use a Door only for Doors, use Switches only for Switches, and WorldModels for everything else. Game objects, specifically AI and Players, need to know if they are interacting with a Door, Switch or something else.

Most basic functionality is shared for every new WorldModel object. All of the new objects have common features and properties that you can edit. They are all created the same way, they all move and rotate based on their local coordinate system and they can all receive certain messages. “Active” WorldModels, that is any Rotating, Sliding or Spinning objects, can also send commands to other objects and play sounds depending on what state they are in.

Creation

To create an instance of a WorldModel just bind a WorldModel object to a brush or a set of brushes. There are several property values you can edit to achieve the object you want. BlendModes is a property drop down list containing several blend operations for your WorldModel object. WorldModels can have Additive blending, they can be Chromakeyed, or they can be Translucent. None is the default BlendMode for newly created WorldModel objects. You can also edit several other properties such as visibility and solidity. If you have a fairly complex brush that the player will be walking on or moving around you may want to set the BoxPhysics flag to FALSE. You can override the surface flags set by the texture mapped to the brush(s) by simply selecting the desired surface in the SurfaceOverride property dropdown list.

Once a WorldModel is positioned and behaves as you would like you can rotate it by selecting both the object and all brushes it is bound to then select Rotate Object in the right click menu in DEdit. You can rotate the WorldModel on all axis, and in any direction. The WorldModel will now move or rotate with the same behavior around its own local coordinate system.

Damage

All WorldModels can handle damage. Each one has a subset property labeled DamageProperties. There are several different values and flags that can all be edited to define how the WorldModel behaves when damaged. Here is a list of the properties that are included in the DamageProperties subset and what each on means:

  • HitPoints: Number of hit points the WorldModel has when created.
  • MaxHitPoints: Max number of hit points the WorldModel can ever have.
  • Armor: Amount of armor that the WorldModel has when it is created.
  • MaxArmor: Max amount of armor the WorldModel can ever have.
  • DamageTriggerCounter: How many times the object must be damaged before the damage message will be sent.
  • DamageTriggerTarget : Name of the object that will receive the DamageTriggerMessage.
  • DamageTriggerMessage: Command string that is sent when the WorldModel receives damage from any source.
  • DamageTriggerNumSends: Specifies how many times the damage message will be sent.
  • DamageMessage: Command string that is sent to the object that caused the damage.
  • DeathTriggerTarget: Name of the object that will receive the DeathTriggerMessage.
  • DeathTriggerMessage : Command string that is sent when the WorldModel has been destroyed.
  • PlayerDeathTriggerTarget: Name of the object that receives the PlayerDeathTriggerMessage.
  • PlayerDeathTriggerMessage: Command string that is sent when the player destroys the WorldModel.
  • KillerMessage: Command string is sent to the object that destroys this WorldModel.
  • CanHeal: Toggles whether the WorldModel can be healed.
  • CanRepair: Toggles whether the WorldModel can be repaired.
  • CanDamage: Toggles whether the WorldModel can be damaged.
  • Mass: Sets the mass of the WorldModel within the game.
  • NeverDestroy: Toggles whether the WorldModel can be destroyed.

Attachments

All WorldModels can have attachments (you can attach models, props, and other WorldModel objects) much like Doorknobs in the NOLF Doors. When attached to a WordlModel, objects will move and rotate with the WorldModel. To have an object attach to a WorldModel when the game loads, add the object you want to attach and position it in DEdit. Enter the name of the Object you want to attach in the Attachments property field, you can have as many objects attached to a WorldModel as you want. List all the objects you want attached separated by a semicolon (ex. Prop1; Prop2; SlidingWorldModel0). During runtime of the game you can attach and detach objects through messages.

States

All “Active” WorldModel objects (Rotating, Sliding, and Spinning) have different states they go through. These states are: PowerOn, On, PowerOff, Off. Doors have similar states with different names: Opening, Open, Closing, Closed. By default, this can be changed in the Options property subset, all objects start in the ‘Off’ or ‘Closed’ state. When positioning and rotating the object in DEdit you are setting its ‘Off’ position. By entering in values for the Movement or Rotation properties you are setting how and where the object will move to when fully ‘On’ or ‘Open’. Sliding WorldModel objects will be moving in the direction you specified while in the ‘PowerOn’ state and when they have moved to the distance you specified they are considered ‘On’. While moving back to their original position and rotation they are in the ‘PowerOff’ state and when they have reached their original position and are at rest they are considered ‘Off’. Rotating and Sliding objects will stay still in their ‘On’ positions and rotations, but SpinningWorldModels will continue to spin at the specified rotations per second while ‘On’.

Messages

All WorldModels can receive “ATTACH” and “DETACH” messages sent from other objects. To send an ATTACH just send a message to a WorldModel like you would other objects and enter the name of the object you want to ATTACH:

(Ex. msg WorldModelName (ATTACH Prop0)). Only one object can be attached at a time using this method. When another ATTACH message is sent to the same WorldModel the first attachment is detached and the new object is attached. To detach the object you attached with an ATTACH message, send the object a DETACH message. DETACH takes no additional parameters.

(Ex. msg WorldModelName DETACH)

All “Active” WorldModel objects (Rotating, Sliding, and Spinning) can also receive messages to turn ‘On’ and ‘Off’. Messages that “Active” WorldModels can receive are:

  • ON: If not already in the On or PowerOn states, puts the WorldModel in the PowerOn state.
  • TRIGGERON: same as ON
  • OFF: If not already in the Off or PowerOff states, puts the WorldModel in the PowerOff state.
  • TRIGGEROFF: same as OFF
  • TRIGGER: Toggles the state. Basically the same as when a player presses use against this object. If the WorldModel is in the ‘On’ or ‘PowerOn’ state it will immediately switch to ‘PowerOff’. If it’s in the ‘Off’ or ‘PowerOff’ state, then it will switch to ‘PowerOn’.
  • LOCK: Locks the object. Once locked the object cannot be activated.
  • UNLOCK: Unlocks the object so it can now be activated by the player and messages.

These messages take no other parameters so an example to toggle a SpinningWorldModels current state would be: msg SpinningWorldModelName TRIGGER

Options

All “Active” WorldModel objects (Rotating, Sliding, and Spinning) have several options that can be changed in the Options property subset group. These control how interactive the objects are and set some behavior. PlayerActivate and AIActivate, these let the object know who, if anybody, can turn them ‘On’ or Close them. If these are FLASE then only other objects can interact with it by sending it messages, if PlayerActivate is TRUE then a player can trigger the object by pressing “use”. StartOn, when TRUE, puts the object in the PowerOn or Opening state as soon as the game loads. TriggerOff toggles weather or not the object can be turned off. RemainOn, if TRUE, will keep the object in its’ ‘On’ state until told to turn off, either by the player or another object. Locked, when TRUE, will start the object off as being locked. While Locked the object cannot turn on or off until it is unlocked through a message. Waveform is a dropdown list of movement types that the object will use to rotate or move.

Commands

All “Active” WorldModel objects (Rotating, Sliding, and Spinning) can send commands based on what state they are in. There are 5 commands listed in the Commands property subset group: OnCommand, OffCommand, PowerOnCommand, PowerOffComand, LockedComand. Doors have similar commands with different names: OpenCommand, ClosedCommand, OpeningCommand, ClosingCommand. Each command line can have multiple commands, separated by semicolons, entered and each one will be executed every time the WorldModel object first enters the corresponding state. To have a command executed as soon as on object is activated, either by the player pressing “use” or by receiving an ‘On’ message, simply enter the command in the PowerOnCommand or OpeningCommand line. If you would like a command executed at the end of an objects movement or rotation enter it in the OnCommand line. The LockedCommand will be executed if the object is locked and a player or message tries to activate it.

Sounds

All “Active” WorldModel objects (Rotating, Sliding, and Spinning) can play sounds based on what state they are in. There are 5 sounds listed in the Sounds property subset group: PowerOnSound, OnSound, PowerOffSound, OffSound, LockedSound. Doors have similar sounds with different names: OpeningSound, OpenSound, ClosingSound and ClosedSound. Other properties that can be edited in this subset group are the relative sound position, the radius the sound fades off to and weather or not the sounds will loop. The LockedSound will never loop. Each sound is a single .wav file that is easily picked through a browser. The sounds will start playing every time the WorldModel object first enters the corresponding state. To have a sound start playing every time the object starts to turn off or close enter it in the PowerOffSound or ClosingSound. The LockedSound will play if the object is locked and the player or a message tries to activate it.

Animated Lightmaps

All “Active” WorldModel objects (Rotating, Sliding, and Spinning) can have animated lightmaps associated with their movement or rotation. To create animated lightmaps you must first add a KeyframerLight object. Set the properties of the KeyframerLight as desired, position it close to the WorldModel object you would like to lightmap, if it’s a directional light then make sure the light is pointed in the right direction. Setting ShadowMap to FALSE typically looks much better. Once the KeyframerLight is set just type the name of the KeyframerLight object in the ShadowLights property. You can enter up to 8 lights in the ShadowLights property separated by semicolons. Now just enter the number of frames you would like have in the animation, up to 128. Sometimes less frames actually look better but experiment and use what works best. Remember that the more animations and the more frames in the animations is a real memory hog. Too many animated lightmaps is also a real frame rate killer!

WorldModel
Features

This is the basic “non-active” WorldModel object. It does not move or rotate, does not play any sounds and cannot execute any commands. Like all of the new objects this can handle Attachments, can have BlendModes, has Damage properties, and a surface type can be selected.

Use

Any place where you need a stationary WorldModel, this is the object you should use. An example would be a desk that you want to damage or to be able to handle attachments. This object is also very well suited for keyframing. If you want a keyframed WorldModel object you should use this object.

Creation

This object is created normally. Simply bind this object to a brush or groups of brushes and then edit the properties as fit.

Damage

This object can handle damage. Edit the DamageProperties subset to define behavior.

Attachments

This object can handle attachments. Enter all the objects you want attached to the WorldModel, separated by a semicolon, in the Attachments property.

States

None – This object does not move or rotate so there is no need for states.

Messages

WorldModels can receive these messages.

  • ATTACH: Attaches the object specified in the message
  • DETACH: Detach the object attached with the ATTACH message.

Options

None – The player and AI cannot activate this object. It has no movement or rotation properties.

Commands

None – This object cannot execute any commands.

Sounds

None – This object cannot play any sounds.

RotatingWorldModel

Features

This WorldModel can rotate around a point a specified number of degrees around each axis. The player can interact with this object or it can be controlled only through other objects. Sounds can be played and commands can be executed when certain states are reached. Like all of the new objects this can handle Attachments, can have BlendModes, has Damage properties, and a surface type can be selected. This WorldModel can also have an animated light map associated with it.

Use

Any place you want a WorldModel that should swing like it is hinged to a wall. Kitchen cabinets or window shutters are a good example of what these can be used for but of course there are many uses.

Creation

This object is created normally. Simply bind this object to a brush or group of brushes. To set its rotation properties just edit the vector labeled RotationAngles and either position the bound object where you would like to rotate around or link to a Point object positioned where you want the object to rotate around. Enter the number of degrees, positive or negative, around each axis you would like this object to rotate. Using the kitchen cabinet as an example you would create your brush in the closed position, bind a RotatingWorldModel to the brush, move the bound object to either the left or right edge of the brush, and then edit the vector (0.0 140.0 0.0). This cabinet door will now open out 140 degrees.

Damage

This object can handle damage. Edit the DamageProperties subset to define behavior.

Attachments

This object can handle attachments. Enter all the objects you want attached to the RotatingWorldModel, separated by a semicolon, in the Attachments property.

States
  • On: When the RotatingWorldModel as fully rotated to the degree amounts

specified in the RotationAngles property, it is considered ‘On’.

  • PowerOn: While rotating towards the ‘On’ position it is considered to be in the ‘PowerOn’ state.
  • Off: By default RotatingWorldModels start in the ‘Off’ position, and are considered ‘Off’ while in this position.
  • PowerOff: While rotating from the ‘On’ position towards the ‘Off’ position theRotatingWorldModel is in the ‘PowerOff’ state.

Messages

A RotatingWorldModel can receive these messages.

  • ATTACH: Attaches the object specified in the message
  • DETACH: Detach the object attached with the ATTACH message.
  • ON: If not already in the On or PowerOn states, puts the WorldModel in the PowerOn state.
  • OFF: If not already in the Off or PowerOff states, puts the WorldModel inthe PowerOff state.
  • TRIGGER: Toggles the state. Basically the same as when a player presses use against this object. If the WorldModel is in the ‘On’ or ‘PowerOn’
  • state it will immediately switch to ‘PowerOff’. If it’s in the ‘Off’ or ‘PowerOff’ state, then it will switch to ‘PowerOn’.
  • LOCK: Locks the object. Once locked the object cannot be activated.
  • UNLOCK: Unlocks the object so it can now be activated by the player and other messages.

Options

A RotatingWorldModel can have these options edited.

  • PlayerActivate: Toggles if the Player can interact with the RotatingWorldModel or not.
  • StartOn: When TRUE the RotatingWorldModel is in the ‘On’ position at load time
  • TriggerOff: Toggles weather or not the player can directly turn a
  • RotatingWorldModel ‘Off’.
  • RemainOn: If this is TRUE the RotatingWorldModel will stay in the ‘On’ position until directly told to turn off, either by a player or a message.
  • ForceMove: When TRUE the RotatingWorldModel will rotate through the player and other objects.
  • Locked : Toggles weather this object starts locked or not.
  • RotateAway: If TRUE the RotatingWorldModel will swing away from the player.
  • Waveform: Defines how the object Rotates.

Commands

A RotatingWorldModel can send these commands when in the corresponding state.

  • OnCommand
  • OffCommand
  • PowerOnCommand
  • PowerOffComand
  • LockedComand

Sounds

A RotatingWorldModel can play these sounds when in the corresponding state.

  • PowerOnSound
  • OnSound
  • PowerOffSound
  • OffSound
  • LockedSound

Animated Lightmaps

This object supports animated light maps.

SlidingWorldModel

Features

This WorldModel can slide, or move, a specified number of units in a specified direction. The player can interact with this object or it can be controlled only through other objects. Sounds can be played and commands can be executed when certain states are reached. Like all of the new objects this can handle Attachments, can have BlendModes, has Damage properties, and a surface type can be selected. This WorldModel can also have an animated light map associated with it.

Use

Any place you want a WorldModel that should move in a specific direction. Desk drawers are a good example of what these can be used for but of course there are many uses.

Creation

This object is created normally. Simply bind this object to a brush or group of brushes. To set its movement properties just edit the vector labeled MoveDir and set the distance you would like this SlidingWorldModel to move to in the property labeled MoveDist. A MoveDir vector of (0.0 1.0 0.0 ) will move the SlidingWorldModel along its own local Y axis, typically straight up. This vector can be edited to point in any direction you want (0.5 0.5 0.0) will move the SlidingWorldModel diagonally along its X and Y axis. The MoveDist property is the distance the SlidingWorldModel will travel in DEdit units. Using the desk drawer as an example you would create your brush in the closed position, bind a SlidingWorldModel to the brush and then edit the MoveDir vector (0.0 0.0 1.0). Now specify how far you want the object to move by making MoveDist 64.0. The desk drawer will now slide 64 units out in its local Z axis.

Damage

This object can handle damage. Edit the DamageProperties subset to define behavior.

Attachments

This object can handle attachments. Enter all the objects you want attached to the SlidingWorldModel, separated by a semicolon, in the Attachments property.

States
  • On: When the SlidingWorldModel is fully moved to the distance
  • specified in the MoveDist property, it is considered ‘On’.
  • PowerOn: While moving towards the ‘On’ position it is considered to be in the ‘PowerOn’ state.
  • Off: By default SlidingWorldModels start in the ‘Off’ position, and are considered ‘Off’ while in this position.
  • PowerOff: While moving from the ‘On’ position towards the ‘Off’ position theSlidingWorldModel is in the ‘PowerOff’ state.

Messages

A SlidingWorldModel can receive these messages.

  • ATTACH: Attaches the object specified in the message
  • DETACH: Detach the object attached with the ATTACH message.
  • ON: If not already in the On or PowerOn states, puts the WorldModel in the PowerOn state.
  • OFF: If not already in the Off or PowerOff states, puts the WorldModel in the PowerOff state.
  • TRIGGER: Toggles the state. Basically the same as when a player presses use against this object. If the WorldModel is in the ‘On’ or ‘PowerOn’ state it will immediately switch to ‘PowerOff’. If it’s in the ‘Off’ or ‘PowerOff’ state, then it will switch to ‘PowerOn’.
  • LOCK: Locks the object. Once locked the object cannot be activated.
  • UNLOCK: Unlocks the object so it can now be activated by the player and other messages.

Options

A SlidingWorldModel can have these options edited.

  • PlayerActivate: Toggles if the Player can interact with the SlidingWorldModel or not.
  • StartOn: When TRUE the SlidingWorldModel is in the ‘On’ position at load time
  • TriggerOff: Toggles weather or not the player can directly turn a
  • SlidingWorldModel ‘Off’.
  • RemainOn: If this is TRUE the SlidingWorldModel will stay in the ‘On’ position until directly told to turn off, either by a player or a message.
  • ForceMove: When TRUE the SlidingWorldModel will move through the player andother objects.
  • Locked : Toggles weather this object starts locked or not.
  • Waveform: Defines how the object moves.

Commands

A SlidingWorldModel can send these commands when in the corresponding state.

  • OnCommand
  • OffCommand
  • PowerOnCommand
  • PowerOffComand
  • LockedComand

Sounds

A SlidingWorldModel can play these sounds when in the corresponding state.

  • PowerOnSound
  • OnSound
  • PowerOffSound
  • OffSound
  • LockedSound

Animated Lightmaps

This object supports animated light maps.

SpinningWorldModel

Features

This WorldModel can spin around a point a in the specified amount of time to make one rotation around each axis. The player can interact with this object or it can be controlled only through other objects. Sounds can be played and commands can be executed when certain states are reached. Like all of the new objects this can handle Attachments, can have BlendModes, has Damage properties, and a surface type can be selected. This WorldModel can also have an animated light map associated with it.

Use

Any place you want a WorldModel that should spin around a central point. Ceiling fans or a Rolodex are good examples of what these can be used for but of course there are many uses.

Creation

This object is created normally. Simply bind this object to a brush or group of brushes. To set its rotation properties just edit the vector labeled RotationAngles and either position the bound object where you would like to spin around or link to a Point object positioned where you want the object to spin around. Enter the amount of time, in seconds to make one rotation around each axis, you would like this object to spin. Using the ceiling fan as an example you would create your brush in the closed position, bind a SpinningWorldModel to the brush, move the bound object to the center of the object (by default it is), and then edit the RotationAngles vector (0.0 4.0 0.0). This fan will now spin around its Y axis once every 4 seconds.

Damage

This object can handle damage. Edit the DamageProperties subset to define behavior.

Attachments

This object can handle attachments. Enter all the objects you want attached to the RotatingWorldModel, separated by a semicolon, in the Attachments property.

States
  • On: When the SpinningWorldModel is spinning at the desired rate
  • specified in the RotationAngles property, it is considered ‘On’.
  • PowerOn: While spinning around the point picking up speed towards the specified rate it is considered to be in the ‘PowerOn’ state.
  • Off: By default RotatingWorldModels start in the ‘Off’ position, and are considered ‘Off’ when they are no longer spinning.
  • PowerOff: While spinning from the specified rate slowly towards a resting position the SpinningWorldModel is in the ‘PowerOff’ state.

Messages

A SpinningWorldModel can receive these messages.

  • ATTACH: Attaches the object specified in the message
  • DETACH: Detach the object attached with the ATTACH message.
  • ON: If not already in the On or PowerOn states, puts the WorldModel in the PowerOn state.
  • OFF: If not already in the Off or PowerOff states, puts the WorldModel in the PowerOff state.
  • TRIGGER: Toggles the state. Basically the same as when a player presses use against this object. If the WorldModel is in the ‘On’ or ‘PowerOn’ state it will immediately switch to ‘PowerOff’. If it’s in the ‘Off’ or ‘PowerOff’ state, then it will switch to ‘PowerOn’.
  • LOCK : Locks the object. Once locked the object cannot be activated.
  • UNLOCK: Unlocks the object so it can now be activated by the player and other messages.

Options

A SpinningWorldModel can have these options edited.

  • PlayerActivate: Toggles if the Player can interact with the SpinningWorldModel or not.
  • StartOn: When TRUE the SpinningWorldModel will start spinning at load time
  • TriggerOff: Toggles weather or not the player can directly turn a
  • SpinningWorldModel ‘Off’.
  • RemainOn: If this is TRUE the SpinningWorldModel will keep on spinning until directly told to turn off, either by a player or a message.
  • ForceMove: When TRUE the SpinningWorldModel will rotate through the player and other objects.
  • Locked : Toggles weather this object starts locked or not.
  • Waveform: Defines how the object Spins.

Commands

A SpinningWorldModel can send these commands when in the corresponding state.

  • OnCommand
  • OffCommand
  • PowerOnCommand
  • PowerOffComand
  • LockedComand

Sounds

A SpinningWorldModel can play these sounds when in the corresponding state.

  • PowerOnSound
  • OnSound
  • PowerOffSound
  • OffSound
  • LockedSound

Animated Lightmaps

This object supports animated light maps.

RotatingDoor

Features

This Door can rotate around a point a specified number of degrees around each axis. The player can interact with this object or it can be controlled only through other objects. Sounds can be played and commands can be executed when certain states are reached. Like all of the new objects this can handle Attachments, can have BlendModes, has Damage properties, and a surface type can be selected. This Door can also have an animated light map associated with it. Doors also have the ability to open another door they are linked to and they can open and close portals when they open and close.

Use

Any place you want a Door that should swing like it is hinged to a wall. An office Door or a car Door are good examples of what these can be used for but of course there are many uses.

Creation

This object is created normally. Simply bind this object to a brush or group of brushes. To set its rotation properties just edit the vector labeled RotationAngles and either position the bound object where you would like to rotate around or link to a Point object positioned where you want the object to rotate around. Enter the number of degrees, positive or negative, around each axis you would like this object to rotate. Using the office door as an example you would create your brush in the closed position, bind a RotatingDoor to the brush, move the bound object to either the left or right edge of the brush, and then edit the vector (0.0 90.0 0.0). This office door will now open 90 degrees.

If you want this door to open another door whenever it is activated to open simply use the DoorLink property’s ObjectBrowser to find the door name you would like. Typically Door1 will link to Door 2 and Door2 will link to Door1, this way doors right next to each other will open more naturally. If you want this door to control the opening and closing of a portal just type in the name of the portal brush you want in the PortalName property.

Damage

This object can handle damage. Edit the DamageProperties subset to define behavior.

Attachments

This object can handle attachments. Enter all the objects you want attached to the RotatingDoor, separated by a semicolon, in the Attachments property. A very good use for this would be a doorknob and a peephole.

States
  • Open: When the RotatingDoor is fully rotated to the degree amounts
  • specified in the RotationAngles property, it is considered ‘Open’.
  • Opening: While rotating towards the ‘Open’ position it is considered to be in the ‘Opening’ state.
  • Closed: By default a RotatingDoor starts in the ‘Closed’ position, and are considered‘Closed’ whenever in this position.
  • Closing: While rotating from the ‘Open’ position towards the ‘Closed’ position the RotatingDoor is in the ‘Closing’ state.

Messages

A RotatingDoor can receive these messages.

  • ATTACH: Attaches the object specified in the message
  • DETACH: Detach the object attached with the ATTACH message.
  • ON: If not already in the Open or Opening states, puts the Door in the Opening state.
  • OFF: If not already in the Closed or Closing states, puts the Door in the Closing state.
  • TRIGGER: Toggles the state. Basically the same as when a player presses use against this object. If the Door is in the ‘Open’ or ‘Opening’
  • state it will immediately switch to ‘Closing’. If it’s in the ‘Closed’ or ‘Closing’ state, then it will switch to ‘Opening’.
  • LOCK: Locks the object. Once locked the object cannot be activated.
  • UNLOCK: Unlocks the object so it can now be activated by the player and other messages.

Options

A RotatingDoor can have these options edited.

  • PlayerActivate: Toggles if the Player can interact with the RotatingDoor or not.
  • AIActivate: Toggles if AI can interact with the door or not.
  • StartOpen: When TRUE the RotatingDoor is in the ‘Open’ position at load time.
  • TriggerClose: Toggles weather or not the player can directly Close a RotatingDoor.
  • RemainOpen: If this is TRUE the RotatingDoor will stay in the ‘Open’ position until directly told to close, either by a player or a message.
  • ForceMove: When TRUE the RotatingDoor will rotate through the player andother objects.
  • Locked : Toggles weather this object starts locked or not.
  • RotateAway: If TRUE the RotatingDoor will swing away from the player.
  • Waveform: Defines how the object Rotates.

Commands

A RotatingDoor can send these commands when in the corresponding state.

  • OpenCommand
  • ClosedCommand
  • OpeningCommand
  • ClosingComand
  • LockedComand

Sounds

A RotatingDoor can play these sounds when in the corresponding state.

  • OpeningSound
  • OpenSound
  • ClosingSound
  • ClosedSound
  • LockedSound

Animated Lightmaps

This object supports animated light maps.

SlidingDoor

Features

This Door can slide, or move, a specified number of units in a specified direction. The player can interact with this object or it can be controlled only through other objects. Sounds can be played and commands can be executed when certain states are reached. Like all of the new objects this can handle Attachments, can have BlendModes, has Damage properties, and a surface type can be selected. This Door can also have an animated light map associated with it. Doors also have the ability to open another door they are linked to and they can open and close portals when they open and close.

Use

Any place you want a Door that should move in a specific direction. Sliding glass doors or those sliding Asian doors are a very good example of what these can be used for but of course there are many uses.

Creation

This object is created normally. Simply bind this object to a brush or group of brushes. To set its movement properties just edit the vector labeled MoveDir and set the distance you would like this SlidingDoor to move to in the property labeled MoveDist. A MoveDir vector of (0.0 1.0 0.0 ) will move the SlidingDoor along its own local Y axis, typically straight up. This vector can be edited to point in any direction you want (0.5 0.5 0.0) will move the SlidingDoor diagonally along its X and Y axis. The MoveDist property is the distance the SlidingDoor will travel in DEdit units. Using the sliding glass door as an example you would create your brush in the closed position, bind a SlidingDoor to the brush and then edit the MoveDir vector (1.0 0.0 0.0). Now specify how far you want the object to move by making MoveDist 128.0. The sliding door will now slide 128 units out in its local X axis. If you want this door to open another door whenever it is activated to open simply use the DoorLink property’s ObjectBrowser to find the door name you would like. Typically Door1 will link to Door 2 and Door2 will link to Door1, this way doors right next to each other will open more naturally. If you want this door to control the opening and closing of a portal just type in the name of the portal brush you want in the PortalName property.

Damage

This object can handle damage. Edit the DamageProperties subset to define behavior.

Attachments

This object can handle attachments. Enter all the objects you want attached to the SlidingDoor, separated by a semicolon, in the Attachments property. A very good use for this would be a doorknob and a peephole.

States
  • Open: When the SlidingDoor is fully moved to the distancespecified in the MoveDist property, it is considered ‘On’.
  • Opening: While moving towards the ‘Open’ position it is considered to be in the ‘Opening’ state.
  • Closed: By default a SlidingDoor starts in the ‘Closed’ position, and are considered ‘Closed’ whenever in this position.
  • Closing: While moving from the ‘Open’ position towards the ‘Closed’ position the SlidingDoor is in the ‘Closing’ state.

Messages

A SlidingDoor can receive these messages.

  • ATTACH: Attaches the object specified in the message
  • DETACH: Detach the object attached with the ATTACH message.
  • ON: If not already in the Open or Opening states, puts the Door in the Opening state.
  • OFF: If not already in the Closed or Closing states, puts the Door inthe Closing state.
  • TRIGGER: Toggles the state. Basically the same as when a player presses use against this object. If the Door is in the ‘Open’ or ‘Opening’
  • state it will immediately switch to ‘Closing’. If it’s in the ‘Closed’ or ‘Closing’ state, then it will switch to ‘Opening’.
  • LOCK: Locks the object. Once locked the object cannot be activated.
  • UNLOCK: Unlocks the object so it can now be activated by the player and other messages.

Options

A SlidingDoor can have these options edited.

  • PlayerActivate: Toggles if the Player can interact with the SlidingDoor or not.
  • AIActivate: Toggles if AI can interact with the door or not.
  • StartOpen: When TRUE the SlidingDoor is in the ‘Open’ position at load time.
  • TriggerClose: Toggles weather or not the player can directly Close a SlidingDoor.
  • RemainOpen: If this is TRUE the SlidingDoor will stay in the ‘Open’ position until directly told to close, either by a player or a message.
  • ForceMove: When TRUE the SlidingDoor will rotate through the player andother objects.
  • Locked: Toggles weather this object starts locked or not.
  • Waveform: Defines how the object Moves.

Commands

A SlidingDoor can send these commands when in the corresponding state.

  • OpenCommand
  • ClosedCommand
  • OpeningCommand
  • ClosingComand
  • LockedComand

Sounds

A SlidingDoor can play these sounds when in the corresponding state.

  • OpeningSound
  • OpenSound
  • ClosingSound
  • ClosedSound
  • LockedSound

Animated Lightmaps

This object supports animated light maps.

RotatingSwitch

Features

This Switch can rotate around a point a specified number of degrees around each axis. The player can interact with this object or it can be controlled only through other objects. Sounds can be played and commands can be executed when certain states are reached. Like all of the new objects this can handle Attachments, can have BlendModes, has Damage properties, and a surface type can be selected. This Switch can also have an animated light map associated with it.

Use

Any place you want a Switch that should swing like it is hinged to the floor. Levers are a good example of what these can be used for but of course there are many uses.

Creation

This object is created normally. Simply bind this object to a brush or group of brushes. To set its rotation properties just edit the vector labeled RotationAngles and either position the bound object where you would like to rotate around or link to a Point object positioned where you want the object to rotate around. Enter the number of degrees, positive or negative, around each axis you would like this object to rotate. Using the lever as an example you would create your brush in the closed position, bind a RotatingSwitch to the brush, move the bound object to the bottom edge of the brush, and then edit the vector (0.0 0.0 -45.0). This lever will now rotate -45 degrees around it’s Z axis.

Damage

This object can handle damage. Edit the DamageProperties subset to define behavior.

Attachments

This object can handle attachments. Enter all the objects you want attached to the RotatingSwitch, separated by a semicolon, in the Attachments property. A good example of this would be a handle for the lever.

States
  • On: When the RotatingSwitch as fully rotated to the degree amountsspecified in the RotationAngles property, it is considered ‘On’.
  • PowerOn: While rotating towards the ‘On’ position it is considered to be in the ‘PowerOn’ state.
  • Off: By default RotatingSwitches start in the ‘Off’ position, and are considered ‘Off’ while in this position.
  • PowerOff: While rotating from the ‘On’ position towards the ‘Off’ position the RotatingSwitch is in the ‘PowerOff’ state.

Messages

A RotatingSwitch can receive these messages.

  • ATTACH: Attaches the object specified in the message
  • DETACH: Detach the object attached with the ATTACH message.
  • ON: If not already in the On or PowerOn states, puts the Switch in the PowerOn state.
  • OFF: If not already in the Off or PowerOff states, puts the Switch inthe PowerOff state.
  • TRIGGER: Toggles the state. Basically the same as when a player presses use against this object. If the Switch is in the ‘On’ or ‘PowerOn’ state it will immediately switch to ‘PowerOff’. If it’s in the ‘Off’ or ‘PowerOff’ state, then it will switch to ‘PowerOn’.
  • LOCK: Locks the object. Once locked the object cannot be activated.
  • UNLOCK: Unlocks the object so it can now be activated by the player and other messages.

Options

A RotatingSwitch can have these options edited.

  • PlayerActivate: Toggles if the Player can interact with the RotatingSwitch or not.
  • StartOn: When TRUE the RotatingSwitch is in the ‘On’ position at load time.
  • TriggerOff: Toggles weather or not the player can directly turn a RotatingSwitch ‘Off’.
  • RemainOn: If this is TRUE the RotatingSwitch will stay in the ‘On’ position until directly told to turn off, either by a player or a message.
  • ForceMove: When TRUE the RotatingSwitch will rotate through the player and other objects.
  • Locked : Toggles weather this object starts locked or not.
  • RotateAway: If TRUE the RotatingSwitch will swing away from the player.
  • Waveform: Defines how the object Rotates.

Commands

A RotatingSwitch can send these commands when in the corresponding state.

  • OnCommand
  • OffCommand
  • PowerOnCommand
  • PowerOffComand
  • LockedComand

Sounds

A RotatingSwitch can play these sounds when in the corresponding state.

  • PowerOnSound
  • OnSound
  • PowerOffSound
  • OffSound
  • LockedSound

Animated Lightmaps

This object supports animated light maps.

SlidingSwitch

Features

This Switch can slide, or move, a specified number of units in a specified direction. The player can interact with this object or it can be controlled only through other objects. Sounds can be played and commands can be executed when certain states are reached. Like all of the new objects this can handle Attachments, can have BlendModes, has Damage properties, and a surface type can be selected. This WorldModel can also have an animated light map associated with it.

Use

Any place you want a Switch that should move in a specific direction. Push buttons are a good example of what these can be used for but of course there are many uses.

Creation

This object is created normally. Simply bind this object to a brush or group of brushes. To set its movement properties just edit the vector labeled MoveDir and set the distance you would like this SlidingSwitch to move to in the property labeled MoveDist. A MoveDir vector of (0.0 0.0 1.0 ) will move the SlidingSwitch along its own local Z axis, typically forward. This vector can be edited to point in any direction you want (0.5 0.5 0.0) will move the SlidingSwitch diagonally along its X and Y axis. The MoveDist property is the distance the SlidingSwitch will travel in DEdit units. Using the push button as an example you would create your brush in the closed position, bind a SlidingSwitch to the brush and then edit the MoveDir vector (0.0 0.0 1.0). Now specify how far you want the object to move by making MoveDist 8.0. The push button will now slide 8 units out in its local Z axis.

Damage

This object can handle damage. Edit the DamageProperties subset to define behavior.

Attachments

This object can handle attachments. Enter all the objects you want attached to the SlidingSwitch, separated by a semicolon, in the Attachments property.

States
  • On: When the SlidingSwitch is fully moved to the distancespecified in the MoveDist property, it is considered ‘On’.
  • PowerOn: While moving towards the ‘On’ position it is considered to be in the ‘PowerOn’ state.
  • Off: By default SlidingSwitches start in the ‘Off’ position, and are considered ‘Off’ while in this position.
  • PowerOff: While moving from the ‘On’ position towards the ‘Off’ position the SlidingSwitch is in the ‘PowerOff’ state.

Messages

A SlidingSwitch can receive these messages.

  • ATTACH: Attaches the object specified in the message
  • DETACH: Detach the object attached with the ATTACH message.
  • ON: If not already in the On or PowerOn states, puts the Switch in the PowerOn state.
  • OFF: If not already in the Off or PowerOff states, puts the Switch inthe PowerOff state.
  • TRIGGER: Toggles the state. Basically the same as when a player presses use against this object. If the Switch is in the ‘On’ or ‘PowerOn’ state it will immediately switch to ‘PowerOff’. If it’s in the ‘Off’ or ‘PowerOff’ state, then it will switch to ‘PowerOn’.
  • LOCK: Locks the object. Once locked the object cannot be activated.
  • UNLOCK: Unlocks the object so it can now be activated by the player and other messages.

Options

A SlidingSwitch can have these options edited.

  • PlayerActivate: Toggles if the Player can interact with the SlidingSwitch or not.
  • StartOn: When TRUE the SlidingSwitch is in the ‘On’ position at load time
  • TriggerOff: Toggles weather or not the player can directly turn a SlidingSwitch ‘Off’.
  • RemainOn: If this is TRUE the SlidingSwitch will stay in the ‘On’ position until directly told to turn off, either by a player or a message.
  • ForceMove: When TRUE the SlidingSwitch will move through the player andother objects.
  • Locked : Toggles weather this object starts locked or not.
  • Waveform: Defines how the object moves.

Commands

A SlidingSwitch can send these commands when in the corresponding state.

  • OnCommand
  • OffCommand
  • PowerOnCommand
  • PowerOffComand
  • LockedComand

Sounds

A SlidingSwitch can play these sounds when in the corresponding state.

  • PowerOnSound
  • OnSound
  • PowerOffSound
  • OffSound
  • LockedSound

Animated Lightmaps

This object supports animated light maps.

WorldProperties

This object is placed in every level to define many of the global properties of the level.

WorldSection

This object was not used in the creation of TRON 2.0.


Processing Levels

Overview

What is processing?

Processing is the term used for taking a level that you have created in DEdit and transforming it into a playable TRON 2.0 map. Processing your level is a relatively simple and painless task, but doing it incorrectly can have highly adverse effects on both the look and performance of the game.

When should I process?

Processing takes place after you have created a level in DEdit. You must have at least one brush placed in your level before the processor will work. Similarly, you must have both a WorldProperties object and a GameStartPoint object in your level before you can run it in the game. Each time you make a change to your level in DEdit, you must reprocess your level for the change to take effect.

How do I start the processor?

To start the processor, load your world in DEdit, and then select Process World from the World menu.

How can I run my level after it’s processed?

When the processor is finished, you can run your level directly from DEdit by selecting “Run” from the world menu. You must have DEdit properly configured to run files before this will work. See the DEdit tutorial document for more information on this topic.

What are .TBW Files?

When you save a world in DEdit, it is saved with the .TBW extension. These files are only readable by DEdit and cannot be run directly by the game. When you distribute your completed maps, you may choose to include this file so that others can further modify your work.

What are .DAT Files?

Once your level has been processed, it will be saved with the same name as your .TBW file, but with the .DAT file extension. So if you built a level called MyLevel.TBW and compiled it, you would get MyLevel.DAT as a result. This is the file that you will need to include in your .rez files for distribution if you want other to be able to play your level.

Processor Options

The default settings for the processor (with the possible exception of the project path) are the settings that were used for the retail release of TRON 2.0. These are the settings that you will want to use when you process your level for the final time prior to release. However, a full process on a large level using a slower machine can take up to an hour or more. During the course of development when you are likely to check your changes and additions often by actually playing the level, this can be a problem.

The following sections will describe the various settings available in the processor application, and show you which options can be used to minimize the time it will take to covert your levels into playable maps. Options that are not specifically covered should be kept at their default values to avoid unexpected results. Note that any changes you make to any of these options will remain after you have closed the processor; so be careful to check your settings often.

Common Options

The processor application is running, the following dialog will appear on your screen:

Process Settings

ProjectPath: This is the path to the directory where your DEdit project file (.dep) is located. This must be set correctly or the processor will not be able to locate the resources needed to compile your level.

LogToFile: This option will write out all of the text from the processor window to a log file, including error messages. The completed log files will be written out to the directory where processor.exe is located. The filename format for log files is:

(level name)_(log file #).log

ErrorLog: This option will write out any error messages that occur during the compilation processes to a separate log file for easy reference. The filename format for error log files is:

(level name)Error_(log file #).log

ObjectsOnly: One you have completed a full compile of your level and a .dat file already exists, you can use this option to do a quick, objects only compile of your level. This option will only process the objects in your level, leaving the existing geometry and lighting information contained within the .dat file intact. This option is intended to help you tweak your objects and then check them in the game without going through the hassle of a full install. Please note that you should always do a full compile before releasing any level to the public.

IgnoreHidden: In large, complex levels, you may find that it’s easier to hide any nodes that you are not currently working on to increase performance and avoid mistakes. This option will determine whether or not the hidden pieces of your level should be processed. IgnoreFrozen: Similar to IgnoreHidden, this option will determine if nodes you have set to frozen (i.e. not modifiable) will be processed.

Lighting Settings

The following options are provided so that you can turn off lighting features to streamline compile time during development. However, you should always make sure to do a full compile with all lighting options set to their default settings before you distribute your level!

Apply Lighting: Unchecking this box will automatically disable all of the lighting options. If you have not made any lighting changes to your level since the last time it was processed, you can use this to significantly improve processing times.

Volumetric Ambient: This determines if volumetric lighting should be calculated from the ambient setting on brushes. This is on by default.

LightAnimations: This determines if lightmap animations should be created by the code and is on by default.

Shadows: This determines if shadows will be generated from stationary objects in the level. This is also on by default.

Vertex Lighting Only: For quick compiles, this option can be used to approximate lighting based on vertices. The results will not look as good as they would with a complete lighting pass. This is off by default.

SuperSample: Specifies that lighting should be done by supersample, causing multiple samples to be taken per lightmap level. This is on by default.

Numsamples: Specifies the number of samples that should be taken per lightmap texel. This defaults to 1.

Advanced Settings

The options continued under the advanced settings tab were used in TRON 2.0 development and should never be changed. If you happen to change anything in this section accidentally, please refer to the image below for the default settings and change them back before processing your level to avoid potential problems with the game.

Finishing up

Once you actually run the Processor, the dialog will change to a log window and a display of progress bars showing compile progress. If you read the log window you can learn a lot about how the level is being handled. Error messages will also appear here.

While your level is being processed, you may need to use your computer for other tasks. Use the priority option to determine how much of your system’s resources will be used to process your level. On the low and very low settings, the processor shouldn’t have too much of an impact on your other applications, but the tradeoff is that your level won’t be finished as quickly.

Once the processor has finished, a bell will sound and a “close” button will appear at the bottom of the dialogue window. Click on this to close the processor. Your level is now ready to run.


Commands

Command Architecture

Basic “grammar”:

(If you don’t follow this, don’t worry about it. It is more important for you to just understand how the commands below work)

Command à <command name> <arg 1> <arg 2> … <arg N> Number of arguments depends on the command.

A command can be made up of multiple commands (seperated by semicolons):

Command 1 <arg 1> … <arg N>;Command 2 <arg 1> … <arg N>;…Command N <arg 1> … <arg N>

Also commands can be nested inside other commands if a command is expected as an argument:

Command 1 <arg1 > <Command 2 <arg 1>…<arg N>> … <arg N>

Commands

None of the commands, command ids, object names, or object messages are case sensitive! Msg = msg = MSG = mSg J

ListCommands

This is used internally to list out all of the available commands (i.e., if “commands” is specified in the console the “ListCommands” command is sent to the CommandMgr).

Msg <object name> <object msg>

The Msg command should be used to send one or more objects a message to be processed by the object.

<object name> <object name> à <object name> <object name> | Case-insensitive name of the object(s)
<object msg> | String that the object parses – i.e., syntax not known to command mgr

Examples:

Msg prop0 destroy | Sends the “destroy” message to the object named prop0
Msg prop0 fire | Sends the “fire” message to the object named prop0
Msg prop0 (fire player) | Sends the “fire player” message to the object named prop0

Delay

Delay <delay> <command>

The Delay command is used to delay the sending of a command by some length of time.

<delay> | Time for the command to be delayed
<command> | See Command above

Example:

Delay 0.5 (msg prop0 destroy)

Waits ½ a second then processes the “msg prop0 destroy” command

DelayId

DelayId <command id> <delay> <command>

The DelayId command is exactly like the Delay command. However, a DelayedId command can also be stopped (without being processed) by sending the Abort command (See below).

<command id> | Unique string id for this command (16 characters max).
<delay> | Time for the command to be delayed
<command> | See Command above

Example:

DelayId d1 2.5 (msg prop0 destroy)

Waits 2.5 seconds then processes the “msg prop0 destroy” command. This command is named “d1” so the command could be aborted by sending an “Abort d1” command (See Abort below)

Rand

Rand <command1 percent> <command 1> <command 2>

The Rand command is used to randomly send one of two commands based on the specified percentage.

<command 1 percent> | Percentage (between 0.0 and 1.0) that <command 1> will be processed
<command 1> | Command that will be processed <command 1 percent> of the time (See Command above).
<command 2> | Command that will be processed 1.0 - <command 1 percent> of the time (See Command above).

Example:

Rand 0.25 (msg prop0 fire) (msg prop2 fire)

Randomly “msg prop0 fire” or “msg prop2 fire” is processed. There is a 25% chance “msg prop0 fire” will be processed and a 75% chance “msg prop2 fire” will be processed.

Rand2 <command 1> <command 2>

Rand3 <command 1> … <command3>

Rand4 <command 1> … <command4>

Rand5 <command 1> … <command5>

Rand6 <command 1> … <command6>

Rand7 <command 1> … <command7>

Rand8 <command 1> … <command8>

The Rand2 – Rand8 commands are used to randomly send one of 2 to 8 commands equally. These should be used in place of the Rand command if you want to randomly select 2 or more commands and have each command have the same chance of being processed.

Example:

Rand3 (msg prop0 fire) (msg prop2 fire) (msg prop3 fire)

There is an equal chance that any of the 3 commands will be processed.

Loop

Loop <min delay> <max delay> <command>

The Loop command is used to continuously repeat a specific command. The time between processing of the command is recalculated every time the command is processed based on the min and max delay arguments.

<min delay> | Minimum time between processing the command.
<max delay> | Maximum time between processing the command.
<command> | See Command above

Example:

Loop 0.25 2.0 (msg prop0 fire)

Continuously process the “msg prop0 fire” randomly every ½ second to every 2 seconds. (the delay to the next time processed is recalculated each time the command is processed).

LoopId

LoopId <command id> <min delay> <max delay> <command>

The LoopId command is exactly like the Loop command. However, the LoopId command can also be stopped by sending the Abort command (see below). If you don’t need to abort the command, use the Loop command specified above.

<command id> | Unique string id for this command (16 characters max).
<min delay> | Minimum time between processing the command.
<max delay> | Maximum time between processing the command.
<command> | See Command above

Example:

Loop l1 0.25 2.0 (msg prop0 fire)

Continuously process the “msg prop0 fire” randomly every ½ second to every 2 seconds. (the delay to the next time processed is recalculated each time the command is processed).

This command is named “l1” so the command could be aborted by sending an “Abort l1” command (See Abort below)

Repeat

Repeat <min times> <max times> <min delay> <max delay> <command>

The Repeat command is used to repeat a specific command a certain number of times. The time between processing of the command is recalculated every time the command is processed based on the min and max delay arguments. The command will be repeated randomly between the min and max number of times requested.

<min times> | Minimum number of times to repeat
<max times> | Maximum number of times to repeat
<min delay> | Minimum time between processing the command
<max delay> | Maximum time between processing the command.
<command> | See Command above.

Example:

Repeat 2 5 0.25 2.0 (msg prop0 fire)

Process the “msg prop0 fire” randomly every ½ second to every 2 seconds between 2 and 5 times (The delay to the next time processed is recalculated each time the command is processed).

RepeatId

RepeatId <command id> <min times> <max times> <min delay> <max delay> <command>

The RepeatId command is exactly like the Repeat command. However, a RepeatId command can be stopped before it has been processed the requested number of times by sending the Abort command (see below). If you don’t need to abort the command, use the Repeat command described above.

<command id> | Unique string id for this command (16 characters max).
<min times> | Minimum number of times to repeat
<max times> | Maximum number of times to repeat
<min delay> | Minimum time between processing the command
<max delay> | Maximum time between processing the command.
<command> | See Command above.

Example:

RepeatId r1 2 5 0.25 2.0 (msg prop0 fire)

Process the “msg prop0 fire” randomly every ½ second to every 2 seconds between 2 and 5 times (The delay to the next time processed is recalculated each time the command is processed).

This command is named “r1” so the command could be aborted by sending an “Abort r1” command (See Abort below)

Abort

Abort <command id>

The Abort command is used to stop a LoopId, RepeatId, or DelayId command (See LoopId, RepeatId, and DelayId above).

<command id>

Id of the command to abort.

Example:

Abort r1 | Abort the command named “r1”

Int

Int <variable name> <value>

The Int command is used to declare an integer variable and assign an initial value. Once a variable is declared you can modify its value by using the commands Set, Add or, Sub (see below).

<variable name> | Unique string representing the name of the variable. (32 characters max). Use this name to reference the variable in other commands such as Set. NOTE: The first character of the variable name CAN NOT be a number.
<value> | The initial value given to the variable. Value must be an integer number.

Example:

Int Var1 100

Declare a variable named Var1 with an initial value of 100.

Obj

Obj <variable name> <object name>

The Obj command is used to declare an object variable and assign an initial value. Once a variable is declared you can modify its value by using the Set command (see below).

<variable name> | Unique string representing the name of the variable. (32 characters max). Use this name to reference the variable in other commands such as Set. NOTE: The first character of the variable name CAN NOT be a number.
<object name> | The initial value given to the variable. If this object doesn’t exist, the variable will still be created, and will be referring to a NULL object.

Example:

Obj ActiveProp LampOnShelf

Declare an object variable named ActiveProp referring to the object named LampOnShelf.

Set

Set <variable name> <value>

The Set command is used to assign a value to a variable. The variable must be declared before setting its value. (See Int and Obj above).

<variable name> | Unique string representing the name of an existing variable.
<value> | The value you are assigning the variable to. Value can be a number, 3, the name of an object, or another variable, Var2. Assigning a variable to another variable will simply make the variables equal to each other. Note that integer variables cannot be assigned objects, and object variables cannot be assigned integers.

Example:

Set Var1 0 | Assign the value 0 to the variable Var1
Set Var1 Var2 | Assign the value of Var2 to the variable Var1.

Add

Add <variable name> <value>

The Add command is used to add a value to an integer variable. The variable must be declared before setting its value. (See Int above).

<variable name> | Unique string representing the name of an existing variable.
<value> | The value you are adding to the variable. Value can be a number, 3, or another variable, Var2. Adding a variable to another variable will simply increase the variable by the other variables value.

Example:

Add Var1 5 | Increment the value of Var1 by 5.
Add Var1 Var2 | Increment the value of Var1 by the value of Var2.

Sub

Sub <variable name> <value>

The Sub command is used to subtract a value from an integer variable. The variable must be declared before setting its value. (See Int above).

<variable name> | Unique string representing the name of an existing variable.
<value> | The value you are subtracting from the variable. Value can be a number, 3, or another variable, Var2. Subtracting a variable from another variable will simply decrease the variable by the other variables value.

Example:

Sub Var1 5 | Decrement the value of Var1 by 5.
Sub Var1 Var2 | Decrement the value of Var1 by the value of Var2.

If Then

If <condition> THEN <commands>

The If command is used to process a command or set of commands if the condition argument is evaluated to TRUE.

<condition> | The condition argument is an expression or set of expressions consisting of variable comparisons using Operators. (See Operators below).
<commands> | The command(s) that should be processed when the condition is met. If you want to process multiple commands they must be surrounded by parenthesis.

Example:

If (Var1 equals 1) Then (msg Door1 Open) | If the variable Var1 has a value of 1 then send a message to object Door1 to open.
If ((Var1 == 1) AND (Var2 <= 5)) Then ((msg Door1 open) (msg Door2 Close)) | If the variable Var1 has a value of 1 and the variable Var2 has a value that is less than or equal to 5 then send a message to object Door1 to open and a message to object Door2 to close.

When Then

</A<

When <condition> THEN <commands>

The When command is used to process a command or set of commands when the condition argument is evaluated to TRUE. Very similar to the If (see above) command however the When command does not need to be processed more than once to check its condition. As soon as the condition is true the command(s) will be processed.

<condition> | The condition argument is an expression or set of expressions consisting of variable comparisons using Operators. (See Operators below).
<commands> | The command(s) that should be processed when the condition is met. If you want to process multiple commands they must be surrounded by parenthesis.

Example:

When (Var1 equals 1) Then (msg Door1 Open) | When the variable Var1 has a value of 1 then send a message to object Door1 to open.
When (((Var1 == 1) AND (Var2 <= 5)) OR (Var3 != 0)) Then ((msg Door1 open) (msg Door2 Close)) | When the variable Var1 has a value of 1 and the variable Var2 has a value that is less than or equal to 5 or the variable Var3 has a value that is not equal to 0 then send a message to object Door1 to open and a message to object Door2 to close.

VMsg

VMsg <variable name> <object msg>

This command is exactly the same as the Msg command, except it sends the message to the object referred to by an object variable. (i.e. it is the Variable Message command.)

<variable name> <variable name> à <variable name> <variable name> | Case-insensitive name of the object variable(s)
<object msg> | String that the object parses – i.e., syntax not known to command mgr

Examples:

VMsg ActiveProp destroy | Sends the “destroy” message to the object activeprop is referring to
VMsg ActiveProp fire | Sends the “fire” message to the object activeprop is referring to
VMsg ActiveProp (fire player) | Sends the “fire player” message to the object activeprop is referring to

ShowVar

ShowVar <variable name> <1 or 0>

This command sets the variable and it’s value to be displayed in the console whenever it’s value changes. It is used only for debugging purposes to see what a variables value is and when it changes.

<variable name> | Unique string representing the name of an existing variable.
<1 or 0 > | The number one, representing ‘on’ or ‘true’, or the number zero, representing ‘off’ or ‘false’. If the value is 1 then the variable and its value will be displayed in the console when the variable changes.

Examples:

ShowVar Var1 1 | Sets the variable, Var1, to be displayed in the console whenever its value changes.
ShowVar Var1 0 | Clears the variable, Var1, from displaying in the console. This is the default behavior.

Operators

A couple of the above commands (If, When) have a condition argument where you can compare a variable to a number value or another variable. The condition argument can be broken down into a single expression or a series of expressions. An expression has 3 arguments, the first parameter followed by an operator followed by the second parameter. Depending on the operator, either of the parameters can be another expression. Every operator can be expressed by either a mathematical symbol or the English phrase equivalent.

<Variable> Equals (==) <Value>

The Equals (==) operator is a comparison operator used to determine if a variable is equal to a number value or another variable. An expression with the Equals (==) operator will evaluate to true when <Variable> has a value equal to <Value>. This operator can be used with both integer and object variables.

<variable name> | Unique string representing the name of an existing variable.
<value> | The value you are comparing the variable to. Value can be a number, 3, or another variable, Var2.

Example:

Var1 == 5 | Compare Var1 to the number value 5
Var1 Equals Var2 | Compare Var1 to the variable value Var2

<Variable> Not_Equals (!=) <Value>

The Not_Equals (!=) operator is a comparison operator used to determine if a variable is equal to a number value or another variable. An expression with the Not_Equals (!=) operator will evaluate to true when <Variable> has a value that is not equal to <Value>. This operator can be used with both integer and object variables.

<variable name> | Unique string representing the name of an existing variable.
<value> | The value you are comparing the variable to. Value can be a number, 3, or another variable, Var2.

Example:

Var1 != 5 | Compare Var1 to the number value 5
Var1 Not_Equals Var2 | Compare Var1 to the variable value Var2

<Variable> Greater_Than (>) <Value>

The Greater_Than (>) operator is a comparison operator used to determine if a variable is greater than a number value or another variable. An expression with the Greater_Than (>) operator will evaluate to true when <Variable> has a value that is greater than <Value>. This operator can only be used with integer variables.

<variable name> | Unique string representing the name of an existing variable.
<value> | The value you are comparing the variable to. Value can be a number, 3, or another variable, Var2.

Example:

Var1 > 5 | Compare Var1 to the number value 5
Var1 Greater_Than Var2 | Compare Var1 to the variable value Var2

<Variable> Less_Than (<) <Value>

The Less_Than (<) operator is a comparison operator used to determine if a variable is less than a number value or another variable. An expression with the Less_Than (<) operator will evaluate to true when <Variable> has a value that is less than <Value>. This operator can only be used with integer variables.

<variable name> | Unique string representing the name of an existing variable.
<value> | The value you are comparing the variable to. Value can be a number, 3, or another variable, Var2.

Example:

Var1 < 5 | Compare Var1 to the number value 5
Var1 Less_Than Var2 | Compare Var1 to the variable value Var2

<Variable> Greater_Than_Or_Equal_To (>=) <Value>

The Greater_Than_Or_Equal_To (>=) operator is a comparison operator used to determine if a variable is greater than or equal to a number value or another variable. An expression with the Greater_Than_Or_Equal_To (>=) operator will evaluate to true when <Variable> has a value that is greater than or equal to <Value>. This operator can only be used with integer variables.

<variable name> | Unique string representing the name of an existing variable.
<value> | The value you are comparing the variable to. Value can be a number, 3, or another variable, Var2.

Example:

Var1 >= 5 | Compare Var1 to the number value 5
Var1 Greater_Than_Or_Equal_To Var2 | Compare Var1 to the variable value Var2

<Variable> Less_Than_Or_Equal_To (<=) <Value>

The Less_Than_Or_Equal_To (<=) operator is a comparison operator used to determine if a variable is less than or equal to a number value or another variable. An expression with the Less_Than_Or_Equal_To (<=) operator will evaluate to true when <Variable> has a value that is less than or equal to <Value>. This operator can only be used with integer variables.

<variable name> | Unique string representing the name of an existing variable.
<value> | The value you are comparing the variable to. Value can be a number, 3, or another variable, Var2.

Example:

Var1 <= 5 | Compare Var1 to the number value 5
Var1 Less_Than_Or_Equal_To Var2 | Compare Var1 to the variable value Var2

<Expression1> And (&&) <Expression2>

The And (&&) operator is a logical operator used to determine if both expressions evaluate to true. An expression with the And (&&) operator will evaluate to true when both <Expression1> and <Expression2> evaluate to true. Both expressions need to be enclosed in parenthesis.

<Expression1> | An expression that you wish to evaluate.
<Expression2> | An expression that you wish to evaluate.

Example:

(Var1 == 2) And (Var2 <= Var1) | The entire expression will evaluate to true if variable Var1 is equal to number value 2 and variable Var2 is less than or equal to the variable Var1.
((Var1 == 2) && (Var2 <= Var1)) && (Var3 >= Var1) | If all of the three expressions evaluate to true the whole expression is true. If any one of them evaluate to false the whole expression is false.

<Expression1> Or (||) <Expression2>

The Or (||) operator is a logical operator used to determine if either expressions evaluate to true. An expression with the Or (||) operator will evaluate to true when either <Expression1> or <Expression2> evaluate to true. Both expressions need to be enclosed in parenthesis.

<Expression1> | An expression that you wish to evaluate.
<Expression2> | An expression that you wish to evaluate.

Example:

(Var1 == 2) Or (Var2 <= Var1) | The entire expression will evaluate to true if variable Var1 is equal to number value 2 or variable Var2 is less than or equal to the variable Var1.
((Var1 == 2) || (Var2 <= Var1)) || (Var3 >= Var1) | If either of the three expressions evaluate to true the whol expression is true. If they all evaluate to false the whole expression is false.

Use of Parenthesis

Parenthesis must be used to group multi-term arguments together. This is most often necessary when a command is an argument to another command (i.e., “Repeat 2 5 0.25 2.0 (msg prop0 fire)”). In this example msg prop0 fire is a single argument to the command Repeat. In order for the Repeat command to correctly parse the string “msg prop0 fire” as a single argument, the individual terms must be grouped together using parenthesis.


Content Packs and Modifications

Overview

This document will discuss how to create and distribute content packs, such as map packs, and modifications (mods) for TRON 2.0. It will detail the directory structure of the game, how to gain access to the content shipped with the game, the directory structure of the Custom directory in the root folder of the game, and other important aspects of mod creation and distribution.

Game Directory Structure

When setting up your content packs and mods it is important to use an exact replica of the directory structure used in TRON 2.0. If your files are in different directories the game will not be able to find them and no one will be able to play your maps. To view the correct directory structure of the game you should extract all the files from the Game.rez, Game2.rez, Gamedll.rez and Sound.rez located in the root of your installed TRON 2.0 directory. Extract each .rez file to the exact same folder (e.g. “game”) as described in the overview section of the documentation. Take some time to familiarize yourself with the directory structure so that you can mirror it perfectly when you go to create your own .rez files to distribute your content.

As a simple example, let’s say you are going to create a new Disc Arena map named TRON OLITH that consists of one new texture, a bunch of existing TRON 2.0 assets (i.e. textures, sounds, etc.) and your new map file. While working on the map, it would be save the new assets into your existing TRON 2.0 directory structure and name them in such a way that they can easily be pulled out for distribution. The new textures could be stored in TRON 2.0\Game\Textures\TRON OLITH and similarly, any new assets could be saved using a format of TRON OLITH_assetname so that a wildcard (*.*) search could easily isolate them. Again, the important thing is that the directory structure is preserved. Once the map is finished, you would place any new assets that you created into a directory structure of the following form:

TRON OLITH\Tex\TRON OLITH\texture.dtx TRON OLITH\Worlds\RetailMultiPlayer\DiscArena\TRON OLITH.dat

You would then just need to create a .rez file from the TRON OLITH directory. (See below on how to create .rez files.)

Custom Directory Structure

People wishing to use new content will need to create a Custom directory within their TRON 2.0 folder. This directory must contain two folders – Mods and Resources. In order for other people to properly play your new maps or mods they will need to be placed in these folders. The Resources folder is where all of the new content-only .rez files, such as maps, should go. Any .rez file found in this folder will be automatically visible to the game. Any .rez files containing attribute file changes, changes to existing files, or changes to any of the retail maps within the Resources directory will be ignored by the game. The Resources folder is a place to put new content that isn’t necessary tied to a specific mod. New maps for Disc Arena are a good example. If you wish to make any code or attribute file modifications you will need to place those .rez files within a separate folder inside the Mods folder. These files are only visible when the user selects your specific Mod to play when launching the game. The Resources folder is always available regardless of the Mod selected. Each mod needs to be in its own folder within the Mods directory and the name of the folder needs to be the name of the mod. So when adding a new mod, your .rez file(s) need to be in a directory that looks like this:

Custom\Mods\MyCoolMod

When zipping your files for download it would be wise to include a brief readme that instructs users on where to place the downloaded files. Creating a zip file or installer that automatically extracts the files to the proper folders would be ideal. Please note that the functionality to load Mods and Resources is introduced in the 1.3 Update. Players will need to have this Update installed to load the new content.

LithRez and Rez files

LithRez.exe, located in the Tools directory, is used to pack and unpack all content into .rez files. Rez files contain all of the content, maps, models and textures, for the game. In order to distribute your content packs and mods you will need to pack your resources into a .rez file. You can create a .rez file by using LithRez through the command prompt. Change your directory to the tools directory where LithRez.exe is located and type “lithrez” and hit enter to view how to use the commands. As an example, if you want to rez your maps you would type the following at the command line:

lithrez c MyMaps.rez C:\Program Files\Buena Vista Interactive\TRON 2.0\MyMaps

This will create the MyMaps.rez file from the MyMaps directory in your TRON 2.0 directory.

If you want to take a look at the files from the retail version of TRON 2.0 or from other people’s content packs or mods you will need to extract the .rez files into a directory. Here’s an example on how to extract the .rez file you just created above:

lithrez x MyMaps.rez MyMapsExtracted

This will extract all the directories and files from MyMaps.rez to the Directory MyMapsExtracted.

When packing your files it is important to remember to have the files set up in a directory structure that is a replica of the original TRON 2.0 directory structure. You should also make sure that ONLY the files you are creating or modifying belong in the directory structure you are going to pack into a .rez file. DO NOT include all of the unchanged files from the original game. That is unnecessary, will take a long time to rez, and will make your .rez file much larger than it needs to be for quick downloads.

Creating Asset Lists

Asset lists contain the filenames of resources that are used by a level and it’s components during a game, but are not automatically loaded at the start of the level. When precaching is turned on in the options menu, TRON 2.0 will look for an assetlist for the level after it is loaded, and then precache all of the resources in the list. This greatly reduces hitching in the level.

Before you can create asset lists, you will need to install the Perl programming language. You can download and install ActivePerl free of charge at http:\\www.activestate.com\Products\ActivePerl. Once this is installed, you can create asset lists like this:

1) In the Advanced Options menu in TRON 2.0 launcher, type in the following on the command line:

+errorlog 1 +alwaysflushlog 1 +showfileaccess 1

1) Run the level you wish to build an asset list for. Make sure you do not use cheats and that you use everything available in the level (i.e., you listen to all conversations, activate every secret, use all available weapons\ammo types, set off any explosions, generate all debris available in the level, scroll through all HUD options, etc.)

2) When you feel confident that you have done everything possible within the level that would require an asset of some sort to be loaded dynamically, quit the game without loading any additional levels.

3) Rename the error.log file to the exact name of the level with a .log file extension (i.e. mylevel.log).

4) You will now need to manually edit the log file so that it only contains resources loaded after the level was completely loaded. Open the log file with a text editor and delete the following:

· All text prior to the line that reads something like: “Loaded world: Worlds\RetailSinglePlayer\mylevel in 3.87 seconds”

· Everything after the line that reads “World Ended”.

5) Save your changes and exit the text editor.

6) If for any reason you need to play through a level multiple times to ensure that all resources have been recorded, follow steps 1-6 again, making sure to rename each new log file appropriately. When done, you’ll need to create a single log file that combines the contents of all of the smaller files, and rename this to “mylevel.log”. You do not need to rearrange the contents of your log files in any particular manner, as all the matters is that the complete list of resources is contained in the file that you copy over in the next step.

7) Copy the edited log file to the Tools\AssetLists\logs\new folder.

8) Double click the TRON 2.0\Development\Tools\AssetLists\BuildAssetLists.pl script. When you run this script, the log file in the AssetLists\logs\new directory will be moved to the AssetLists\logs\processed directory and renamed based on the time\date. The log will then be processed and an intermediate file will be copied to AssetLists\processing. The final .txt version of the log fill will be copied to AssetLists\final.

9) Copy the AssetLists\Final\levelname.txt file into the Game\Worlds\ directory associated with the level that was logged. For example, if the level was Game\Worlds\RetailMultiPlayer\dm_mylevel.dat, you would copy the AssetLists\Final\dm_mylevel.txt file to the Game\Worlds\RetailMultiPlayer folder.

10) Your asset list is now complete. The next time you run this level, all of the resources contained in the list will be precached before the level begins.


Adding and Modifying Weapons

Adding and Modifying Weapons in TRON 2.0

Overview

This document will describe how to modify existing weapons and adding new ones to the game TRON 2.0. It will go over the necessary properties for the weapons, mods and ammo and how to add ammo and mods to a weapon. The main file used for the weapon, ammo and mod definitions is weapons.txt found in your TRON 2.0\Game\Attributes directory. This file will also take a look at FX.txt so you know how to create and modify the special FX for the weapons. When working with attribute files such as weapons.txt or FX.txt, the headers for the files should be read for more information on each field and recent changes.

Weapons.txt

The first section you will see in weapons.txt is the WeaponOrder list. The WeaponOrder list allows you to specify the order of all weapons used in the game and is also used to categorize the weapons into classes. The class numbers refer to the NextWeapon_XX command binding. The NextWeapon_XX command will cycle through all the weapons in the XX class. When adding or changing weapons you may want to reorganize the weapon classes so like weapons are grouped together. The last entries in the WeaponOrder list are the non-player weapons, weapons that are only used by AI.

After the WeaponOrder list is the AutoSwitch list. This is used to set a priority to weapons when auto switching. When the player picks up a weapon the AutoSwitch list is used to determine if they should switch to that weapon. Leave any weapons off the list that you feel the player would never want that game to automatically switch to.

MP_Weapons.txt

TRON 2.0 SinglePlayer strictly used weapons.txt for all of its weapon definitions. The other multiplayer game types, Disc Arena and Disc Tournament used an override file, mp_weapons.txt the allows you to override certain properties from weapons.txt for use in those game types. This allowed us to balance singleplayer and multiplayer game types separately. Only the properties that are going to be overridden need to be listed in the weapon definition in mp_weapons.txt. (see mp_weapons.txt for more info).

Ammo

The ammo section is where all of the ammo definitions are listed. The order of the ammo list is in order of creation and doesn’t pertain to the weapons that use the ammo or the priority of the ammo. When creating a new ammo definition you must add it to the end of the already existing list with a tag that is one greater than the previous definition. If you wish to edit an existing ammo definition, you may change any of the properties, listed below, to the desired value. However, you cannot change the name of an ammo definition since that name is used to reference the ammo in the weapon definitions.

Ammo Properties

Name | (string) | This is the user friendly name that is used to reference the ammo in the weapon definitions and from within DEdit
NameId | (integer) | This is an ID that maps to a localized string for the name of the ammo (seen in game).
DescId | (integer) | This is an ID that maps to a localized string for the description of the ammo.
Type | (integer) | Specifies the type of ammo. 0 – Vector (bullet) 1 – Projectile (grenade) 3 – Gadget (code breaker)
Icon | (string) | File path and name of the interface icon fro the ammo that will be displayed when the ammo is selected.
MaxAmount | (integer) | Specifies the maximum amount of ammo that the player can carry at any given time.
SelectionAmount | (integer) | Specifies the amount of this ammo in a weapon when a weapon is picked up in game.
SpawnedAmount | (integer) | Specifies the amount of ammo that will be in an ammo box when this ammo spawns in an ammo box. (level designers can override this value).
InstDamage | (integer) | Specifies the amount of Instantaneous damage done by this type of ammo.
InstDamageType | (string) | Specifies the type of Instantaneous damage done by this type of ammo. (See valid DamageTypes in DamageTypes.txt).
AreaDamage | (integer) | Specifies the Max amount of Area damage done by this type of ammo (i.e., damage done if you are in the center of the damage).
AreaDamageType | (string) | Specifies the type of Area damage done by this type of ammo. (See valid DamageTypes in DamageTypes.txt).
AreaDamageRadius | (integer) | Specifies the radius of effect for the AreaDamage.
ProgDamage | (float) | Specifies the amount of Progressive damage done by this type of ammo. This is the amount of damage that is done per second.
ProgDamageType | (string) | Specifies the type of Progressive damage done by this type of ammo. (See valid DamageTypes in DamageTypes.txt).
ProgDamageDuration | (float) | Specifies how long the Progressive damage is applied to the victim.
ProgDamageRadius | (float) | Specifies the radius of effect for the Progressive damage (only used if ProgDamageLifetime is greater than 0.0).
ProgDamageLifetime | (float) | Specifies the time the progressive damage radius of effect lasts (for things like poison gas).
FireRecoilMult | (float) | This multiplier modifies the FireRecoilPitch value in a weapon firing this type of ammo (see FireRecoilPitch in Weapon definition below)
ImpactFXName | (string) | Specifies the impact special fx. The value of this property MUST correspond to the name of an ImpactFX specified in the FX.txt file.
UWImpactFXName | (string) | Specifies the under water impact special fx. The value of this property MUST correspond to the name of an ImpactFX specified in the FX.txt file.
ProjectileFXName | (string) | Specifies the a projectile special fx. The value of this property MUST correspond to the name of a ProjectileFX specified in the FX.txt file.
MoveableImpactOverrideFXName | (string) | Specifies an effect to play if the impact occurs on a moveable object, such as a model or a door. This way you can have effects that 'stick' but not stick to moveable objects so they won't hang in the air.
FireFXName | (string) | Specifies a fire special fx. The value of this property MUST correspond to the name of a FireFX specified in the FX.txt file.
TracerFXName | (string) | Specifies a tracer special fx. The value of this property MUST correspond to the name of a TracerFX specified in the FX.txt file.
WeaponAniOverride | (string) | Not used in TRON 2.0 and is unsupported
CanBeDeflected | (integer) | Ammo can be deflected by weapon. To deflect, the weapon must have a model string key "begindeflect" followed by a key "enddeflect".
DeflectSurfaceType | (string) | When ammo is deflected, the impact fx used will be based on this surface type. Surface types found in surface.txt.
CanAdjustInstDamage | (integer) | If set to 1 the InstDamage amount may be adjusted programatically, if set to 0 the value specified by InstDamage will always be used.
CanServerRestrict | (integer) | If set to 0 to not allow server options to restrict this item from the level. Default: 1.

Weapons

The weapon section is where all of the weapon definitions are listed. The order of the weapon list is in order of creation and doesn’t pertain to the WeaponOrder list mentioned above. When creating a new weapon definition you must add it to the end of the already existing list with a tag that is one greater than the previous definition. If you wish to edit an existing weapon definition, you may change any of the properties, listed below, to the desired value. However, you cannot change the name of a weapon definition since that name is used in the WeaponOrder list and within DEdit.

Weapon Properties

Name

(string)

User friendly name used in WeaponOrder above and in DEdit.

NameId

(integer)

Id that maps to the weapon Localizable name (stored in CRes.dll)

DescriptionId

(integer)

Id that maps to the weapon localized description (stored in CRes.dll)

IsAmmoNoPickupId

(integer)

Id that maps to the string that is displayed for IsAmmo = 1 type weapons when the weapon can not be picked up (stored in CRes.dll)

ClientWeaponType

(integer)

Weapon type:

0 - none (NEVER use this number)

1 - vector (bullet type weapons)

2 - projectile (like crossbows)

AniType

(integer)

Classify the weapon into a style of animation when holding the weapon. Players and AI will hold their weapons depending on the animation type of the weapon.

Values :

0 - rifle

1 - pistol

2 - melee

3 - Throw

4 - Rifle2

5 - Rifle3

6 - Holster

7 - Place

8 - Gadget

9 - Throwing Stars

Icon

(string)

Filename of the texture used for an icon associated with the weapon.

for Normal icons

".dtx" is appended to the name.

for Unselected icons

"U.dtx" is appended to the name.

for Disabled icons

"D.dtx" is appended to the name.

for Silhouette icons

"X.dtx" is appended to the name.

Pos

(vector)

The player-view weapon model pos (offset from player model in x, y, and z)

MuzzlePos

(vector)

The player-view weapon model muzzle pos (offset from the player model in x, y, and z). This is used to determine where to place muzzle fx.

BreachOffset

(vector)

The player-view weapon breach offset which is relative to the above model muzzle pos. This is used to determine where shell casings will be ejected from the player-view weapon.

MinPerturb

(integer)

The minimum amount of perturb on each vector or projectile fired by the weapon. A value in range from MinPerturb to MaxPerturb

is added to the Up and Right components of the firing direction vector based on the current accuracy of the player/ai firing the weapon.

MaxPerturb

(integer)

The maximum amount of perturb on each vector or projectile fired by the weapon. A value in range from MinPerturb to MaxPerturb is added to the Up and Right components of the firing direction vector based on the current accuracy of the player/ai firing the weapon.

Range

(integer)

The range of the weapon. The weapon is ineffective if shooting at targets beyond the range.

Recoil

(vector)

The amount the weapon will recoil when fired.

VectorsPerRound

(integer)

The number of vectors (rays cast) per round when the weapon is fired. Used for things like a shotgun.

PVModel

(string)

File path and name of the player-view weapon model.

PVSkin0-N

(string)

Name of the player-view weapon skin(s) (NOTE: You can specify "Hands" if you want to use the player-view hands texture associated with the current player model style). There can be any number of skins: PVSkin0, PVSkin1, …, PVSkinN. The PVSkinX number relates to the texture indices in the piece info dialog in ModelEdit.

PVRenderStyle0-N

(string)

Name of the render style file ltb(s). There can be any number of render styles: PVRenderStyle0, PVRenderStyle1, ..., PVRenderStyleN. The PVRenderStyleX number relates to the renderstyle index in the piece info dialog in ModelEdit.

PVMuzzleFXName

(string)

Specifies the optional player-view muzzle fx for this weapon. The value of this property MUST correspond to a name specified in the MuzzleFX definitions in the Attributes\fx.txt file.

PVAttachFXName0-10

(string)

Specifies the optional player-view fx attachment for this weapon. The value of this property MUST correspond to an effect created with FXEd.

HHModel

(string)

File path and name of the hand-held (and powerup) weapon model.

HHSkin0-N

(string)

Name of the hand-held (and powerup) weapon skin(s). There can be any number of skins: HHSkin0, HHSkin1, ..., HHSkinN. The HHSkinX number relates to the texture indices in the piece info dialog in ModelEdit.

HHRendeStyle0-N

(string)

Name of the render style file ltb(s). There can be any number of render styles: RenderStyle0, HHRenderStyle1, ..., HHRenderStyleN. The HHRenderStyleX number relates to the renderstyle index in the piece info dialog in ModelEdit.

HHModelScale

(vector)

The scale of the hand-held (and powerup) weapon model.

HHMuzzleFXName

(string)

Specifies the optional hand-held muzzle fx for this weapon. The value of this property MUST correspond to a name specified in the MuzzleFX definitions in the Attributes\fx.txt file.

FireSnd

(string)

Name of the sound that is played when the weapon is fired.

AltFireSnd

(string)

Name of the sound that is played when the weapon is alt-fired. (ALT Fire was not used in TRON 2.0 and is unsupported)

SilencedFireSnd

(string)

Name of the sound that is played when the weapon is fired with a silencer.

DryFireSnd

(string)

Name of the sound that is played when the weapon is dry fired.

ReloadSnd1-3

(string)

Name of the sound that is played when the weapon is reloaded. (mapped to SOUND_KEY 1 – SOUND_KEY 3)

SelectSnd

(string)

Name of the sound that is played when the weapon is selected. (mapped to SOUND_KEY 4)

DeselectSnd

(string)

Name of the sound that is played when the weapon is deselected. (mapped to SOUND_KEY 5)

MiscSound1-5

(string)

Optional miscellaneous sounds to play during weapon animations. (mapped to SOUND_KEY 10 – SOUND_KEY 14)

FireSndRadius

(integer)

The radius of volume falloff that fire sounds are played at

AIFireSndRadius

(integer)

The radius of volume that fire sounds make, w.r.t to AI's senses

WeaponSndRadius

(integer)

The radius of volume falloff that all other sounds, non-fire sounds, are played at

EnvironmentMap

(integer)

Specifies whether or not the weapon uses environment mapping.

InfiniteAmmo

(integer)

Specifies whether or not the weapon has unlimited ammo. (1 = true, 0 = false). Things like swords should have unlimited ammo.

ShotsPerClip

(integer)

The number of rounds the weapon can fire before it must be reloaded.

FireRecoilPitch

(float)

Specifies the amount the weapon should pitch (in degrees) when fired.

FireRecoilDelay

(float)

Specifies the time (in seconds) it should take for the weapon's pitch to get back to normal after recoiling from firing.

AmmoName#

(string)

Specifies the type of ammo available for this weapon. The value of this property MUST correspond to a name of an AMMO definition. If the weapon uses multiple ammo types, you may specify multiple AmmoName properties. For example:

AmmoName0 = “9mm fmj”

AmmoName1 = “9mm dum dum”

Note: The first (or only) ammo type specified is considered the “default” ammo type. Every weapon MUST have at least one ammo type specified.

ModName#

(string)

Specifies the optional mods available for this weapon. The value of this property MUST correspond to the name of a MOD definition. If the weapon uses multiple mods, you may specify multiple ModName properties. For example:

ModName0 = “silencer”

ModName1 = “scope”

PVFXName#

(string)

Specifies the optional player-view fx available for this weapon. The value of this property MUST correspondd to a name specified in the PVFX definitions in the Attributes\fx.txt file. If the weapon uses multiple pv fx, you may specify multiple PVFXName properties.

AIWeaponType

(integer)

Classify the weapon for use by AI

Values :

0 - None

1 - Ranged

2 - Melee

3 - Thrown

AIMinBurstInterval

(float)

Specifies the range of time (in seconds) an AI will wait in between firing a burst from a weapon. IE, the AI will shoot somewhere between Min/AIMaxBurstShots, then wait Min/AIMaxBurstInterval seconds, then shoot again.

AIMaxBurstInterval

(float)

AIMinBurstShots

(integer)

Specifies the range of shots an AI will fire when it is firing a burst from a weapon. IE, the AI will shoot somewhere between Min/AIMaxBurstShots, then wait Min/AIMaxBurstInterval seconds, then shoot again.

AIMaxBurstShots

(integer)

AIAnimatesReload

(integer)

Specifies whether or not an AI animates reloading this weapon. 1 = true, 0 = false)

LooksDangerous

(integer)

Specifies whether or not the weapon/gadget looks dangerous to AIs. (1 = true, 0 = false)

FireDelay

(integer)

Specifies the minimum delay in milliseconds between fire keys. The server will not allow shots to fire quicker than the FireDelay.

HideWhenEmpty

(integer)

Specifies whether or not the weapon/gadget should be hidden when out of ammo (also implies that the deselect animation shouldn't be played when auto-switching from this weapon when it runs out of ammo) (1 = true, 0 = false)

IsAmmo

(integer)

Specifies whether or not the weapon/gadget should be treated as ammo. In other words is the weapon placed/thrown (e.g., grenade, bear trap, etc.). If set to true the weapon's pick-up message won't be displayed when the weapon is picked up unless the weapon can't be picked up. If the weapon can't be picked up the IsAmmoNoPickupId string is displayed. This should be used for "thrown" weapons so the player doesn't see both the weapon pickup message AND the ammo pick up message. (1 = true, 0 = false)

HolsterAttachment

(string)

Specifies node and model to attch when weapon is holstered. For example:

HolsterAttachment = "BACK AK47_holster"

HiddenPiece0-N

(string)

Names of Gadget model pieces to hide/show when the gadget is fired. There can be any number of pieces to hide/show.

FireAnimRateScale

(float)

Speeds up or slows down the rate of the Fire animation. By default the scale is 1.0 which will play the animation at normal speed, 2.0 will double the speed, and 0.5 will half the speed.

ReloadAnimRateScale

(float)

Speeds up or slows down the rate of the Reload animation. By default the scale is 1.0 which will play the animation at normal speed, 2.0 will double the speed, and 0.5 will half the speed.

PowerupFX

(string)

Name of the FxED created FX to be played when the item respawns. This FX will constantly loop as long as the item is waiting to be picked up.

RespawnWaitVisible

(integer)

(0 or 1) If 0 the item will become invisible once it is picked up and is waiting to respawn. Otherwise the item will remain visible.

RespawnWaitFX

(string)

Name of an FxED created FX to play once the item is picked up and is waiting to respawn.

RespawnWaitSkin0-N

(string)

Name of the skin files that will be associted with the mode once it is picked up and is waiting to respawn.

RespawnWaitRenderstyle0-N

(string)

Name of the renderstyle that will be associated with the model once it is pickedup and is waiting to respawn.

CanServerRestrict

(integer)

If set to 0 to not allow server options to restrict this item from the level. Default: 1.

Mods

The mod section is where all of the mod definitions are listed. The order of the mod list is in order of creation and doesn’t pertain to the weapons that use the mod or the priority of the mod. When creating a new mod definition you must add it to the end of the already existing list with a tag that is one greater than the previous definition. If you wish to edit an existing mod definition, you may change any of the properties, listed below, to the desired value. However, you cannot change the name of a mod definition since that name is used in the weapon definitions and within DEdit.

Name | (string) | User friendly name used in DEdit.
Socket | (string) | Name of the weapon model socket to attach the mod model to. You can add and edit sockets on a model within ModelEdit.
NameId | (integer) | Id that maps to the localized string for the name of the Mod.
DescriptionId | (integer) | Id that maps to the localized string for the description of the mod.
Icon | (string) | Name of the interface icon associated with the ammo type.
Type | (integer) | Specifies the type of mod. Valid values are: 0 – Silencer 1 – Scope
AttachModel | (string) | File path and name of the model attachment associated with the mod.
AttachSkin0-N | (string) | Name of the skin(s) associated with the mod attachment model. There can be any number of skins: AttachSkin0, AttachSkin1, …, AttachSkinN
AttachRenderStyle0-N | (string) | Name of the render style file ltb(s). There can be any number of render styles: AttachRenderStyle0, AttachRenderStyle1, …, AttachRenderStyleN
AttachScale | (vector) | Scale of the mod attachment model.
ZoomLevel | (integer) | Level the weapon can zoom to (Valid levels are 1, 2, and 3. 0 = can’t zoom). Ignored for non-scope mods.
NightVision | (integer) | Does the mod provide night vision (1 = true, 0 = false). Ignored for non-scope mods. (Night vision was not used in TRON 2.0 and is unsupported)
Integrated | (integer) | Is the mod built into the weapon (1 = true, 0 = false). If this is true, any weapon that lists this mod in its list of mods will always have this mod.
Priority | (integer) | This is used for weapons that have more than one mod of the same type (e.g., two scopes). This field indicates which should be used if the weapon has both mods (the highest priority is used). NOTE: this is a number between 0 and 255, that should default to 0.
ZoomInSound | (string) | Name of the sound that is played when the weapon is zoomed in.
ZoomOutSound | (string) | Name of the sound that is played when the weapon is zoomed out.
PickUpSound | (string) | Name of the sound that is played when the mod is picked up (either absolute path to sound or name of soundbutes sound)
RespawnSound | (string) | Name of the sound that is played when the mod respawns in multiplayer (either absolute path to sound or name of the soundbutes.txt sound)
PowerupModel | (string) | Name of the powerup model associated with the mod. This is what players see in the game when picking up the mod.
PowerupSkin0-N | (string) | ame of the powerup skin(s) associated with the mod. There can be any number of skins: PowerupSkin0, PowerupSkin1, ..., PowerupSkinN
PowerupRenderStyle0-N | (string) | Name of the render style file ltb(s). There can be any number of render styles: PowerupRenderStyle0, PowerupRenderStyle1, ..., PowerupRenderStyleN
PowerupModelScale | (float) | The scaling factor used with the powerup model. (same model as attach model)
TintColor | (vector) | Color to tint the screen when mod is picked up (r, g, b)
TintTime | (float) | Duration in seconds of screen tint when gear is picked up
AISilencedFireSndRadius | (integer) | The radius of volume that silenced fire sounds make, w.r.t to AI's senses NOTE: this value only works with Type = 0 mods.
PowerupFX | (string) | Name of the FxED created FX to be played when the item respawns. This FX will constantly loop as long as the item is waiting to be picked up.
RespawnWaitVisible | (integer) | (0 or 1) If 0 the item will become invisible once it is picked up and is waiting to respawn. Otherwise the item will remain visible.
RespawnWaitFX | (string) | Name of an FxED created FX to play once the item is picked up and is waiting to respawn.
RespawnWaitSkin0-N | (string) | Name of the skin files that will be associted with the mode once it is picked up and is waiting to respawn.
RespawnWaitRenderStyle0-N | (string) | Name of the renderstyle that will be associated with the model once it is pickedup and is waiting to respawn.

Creating New Weapons

When adding a new weapon here are a few things to keep in mind. Your model will need a select, deselect, reload, idle_0 and fire animations. You may also have idle_1 and idle_2 for multiple idle animations, these animations are played less often and may be more pronounced. You can also have prefire and postfire animations that, if present, will play before and after the fire animation. These animations can be used to start and stop looping sounds, be used to show a ramp up and ramp down time for the weapon and may also be used to simulate holding an object to throw, like the grenades. In order for the weapon to actually fire a round it must contain a fire_key frame string on one of the keyframes of the model for one of the prefire, fire, or postfire animations. All the valid framestrings and what the are used for are listed below.

FIRE_KEY | Lets the weapon know when to fire.
SOUND_KEY (integer) | Tells the weapon to play a sound that is associated with the given number. Valid numbers and their mapping to the sound files in the weapon definition are: 1 – ReloadSnd 2 – ReloadSnd2 3 – ReloadSnd3 4 – SelectSnd 5 – DeselectSnd 6 – FireSnd 7 – DryFireSnd 8 – AltFireSnd 9 – SilencedFireSnd 10 – MiscSnd1 11 – MiscSnd2 12 – MiscSnd3 13 – MiscSnd4 14 – MiscSnd5
BUTE_SOUND_KEY (string) | Tells the weapon to play a buted sound of the given name. (see soundbutes.txt for more info on soundbutes)
LOOP_SOUND_KEY (integer) | Same as SOUND_KEY except the sound will begin to loop. To stop the looping sound use the frame string “LOOP_SOUND_KEY stop”. Usually you want the sound to begin looping during its prefire animation and stop during its postfire animation.
FX (string) | Play the specifed FxEd created fx.
FIREFX_KEY (string) | Fires the weapon and plays the specified FxEd create FX. Same as doing “FIRE_KEY; FIREFX_KEY (fx name)”
FLASHLIGHT (string) | Lets the weapon turn the flashlight on and off. Valid strings: ON OFF
DEFLECT (float) | When a weapon hits this key it specifies the time, in seconds, that this weapon can deflect hits from other weapons that are deflecting.
HIDE_PIECE_KEY (string) | Sets the specified piece name invisible.
SHOW_PIECE_KEY (string) | Sets the specified piece name visible again.
HIDE_PVATTACHFX (integer) | Hides specifed PVAttachFXName# on the weapon
SHOW_PVATTACHFX (integer) | Shows the specified PVAttachFXName#.
HIDE_PVATTACHMENT (integer) | Hides the specified PlayerViewAttachmentX (set on a per player model basis. See modelbutes.txt for more info)
SHOW_PVATTACHMENT (integer) | Shows the specified PlayerViewAttachmentX. (set on a per player model basis. See modelbutes.txt for more info)


Working with models

Basic model creation

All of the models in TRON 2.0 were modeled, textured and animated in Maya 4.0. We currently have working exporters for Maya3.0/4.0, and 3dStudioMax3.0/4.0. All of the basics of model creation mentioned here are specific to Maya, but the concepts apply to Max-created models.

Models and Polycounts

Models should be created using polygons. There are limits on the number of polygons of a particular model depending on the function and necessary detail level of that model. In TRON 2.0, the character models ranged from 1700 to 2700 triangles. This is a good range for most characters, but the limit could go as high as 4-5000 triangles in isolated situations. In addition to the main models, TRON 2.0 used hand-built level-of-detail (LOD) models for most of the gameplay characters (and all of the multiplayer models). The rule of thumb used was to create two duplicate models and reduce on to 60% and the other to 25% of the original model’s polycount. LODs are not necessary, but are an optimization that will improve rendering speed when many models are onscreen simu.ltaneously. More will be mentioned later about setting up LODs for a model.

Textures and RenderStyles

Textures can be created using any digital painting tool and should have dimensions that are a power of 2 pixels in length (…64,128,256, 512…). Model textures are generally kept square, but rectangular shaped textures are ok as long as the dimensions fill this requirement. A Photoshop plugin is included to allow creation of Lithtech’s DTX texture format. In addition, plugins for Maya and Max are included to allow the use of DTX textures (Maya: IMFLithDTX.dll, MAX: MaxDTXLoader40.bmi). A model can theoretically have up to 16 textures, but each part of the model using a different texture needs to be separated into a unique piece. A model can be made up of as many as 64 separate pieces, but keeping as few as possible is desirable to avoid slowing model rendering down. Most TRON 2.0 characters have only two pieces, a head and a body, for this reason. In addition to simple textures, each piece can have a unique “render style”. There are a lot of these that were created for very specific purposes, but the ones most commonly used for models are: envmap.ltb, glass.ltb (for creating gray-scale alpha masked transparency) and transparent.ltb (for creating things like windows with alpha masks). There isn’t currently a way to duplicate the effects of these in Maya, but they’re not too bad to set up by just checking them in the game. One model piece can have only one render style, and usually pieces are combined based on the way model’s render styles are distributed.

Skeletons

After creating the model and textures, the model geometry is bound to a skeleton. In Maya, this consists of a hierarchy of one or more joints. All Maya models should be attached to skeletons using ‘smooth bind’ in the Skin menu. By default, the exporter will only export joints that are bound to geometry, or the parents of such joints. In some cases it is necessary have other joints in the hierarchy exported. This is done by creating a Boolean attribute called ‘ForcedNode’ on the joint and setting its value to 1. Every exported model must have at least one joint. Inanimate models, such as lamps, chairs, etc. will need only one joint. Most TRON 2.0 characters have 35. Again it’s possible to use a lot of joints, but keeping the number as low as possible will improve performance. Model LODs can be made even more efficient by removing unneeded joints from the lower detail models. This can be done in Maya by using the ‘Edit Smooth Skin > Remove Influence’ function.

Exporting models

To use the exporter plugin in Maya, place the file ‘MayaModelExport40.mll’ in the Maya bin\plugins\ folder and the file ‘LithTechModelExportOptions.mel’ in the Maya scripts\others\ folder. Make sure the plugin is loaded in Maya’s Plugin Manager window.

The exporter plugin exports a text version of the Lithtech file format, ‘.lta’. It will also export a compressed version, ‘.ltc’, to save disk space. The format should be specified in the filename supplied to the plugin. The exporter uses the command line format:

lithtechModelExport –all [-usePlaybackRange <bool> -append <bool> -ignoreBindPose <bool> -exportWorldNode <bool> -scale <float>] <animation name> <file name>

The optional flags are defined as follows:

  • -usePlaybackRange – setting this to ‘1’ will export only the visible range of an animation. ‘0’ will export all keyframes in the scene.
  • -append – setting this to ‘1’ will append the animation to an existing file, allowing models to contain many animations. Setting it to ‘0’ (the default) will overwrite the file if it exists.
  • -ignoreBindPose – This option determines whether the bind pose of a model or the first frame of an animation is used as a base for deformation. This was set to ‘1’ for nearly all TRON 2.0 models because of the child model workflow described below.
  • -exportWorldNode – This allows multiple skeletons in a scene to be exported as one model if set to ‘1’. It adds a ‘world node’ as a parent to all exported skeletons. It was generally set to ‘0’ for TRON 2.0 models.
  • -scale – this will scale a model by the specified float value. This can be helpful since it can be tricky to scale animations in Maya.
  • animation name – the name of an animation. When appending animations, if there is an existing animation of the same name, it will need to be deleted in ModelEdit before it can be used.

· file name – this should contain the entire path to the desired file. The format should be either ‘.lta’, or ‘.ltc”.

The exporter will use these options to decide which skeleton(s) should be exported, and will include all visible geometry bound to it.

The concept of ‘child models’ was used for most characters in TRON 2.0. The child model is a model that is used solely to store animations (and animation specific data). When a child model is applied to another model, that model will share all the animation data from the child model. This allows continual edits to be made on models without needing to worry about re-exporting large numbers of animations. It also allows many different models to use the same animation set. The base character should be exported unanimated at its bind pose with the animation called ‘base’. A child model is created by using the ‘append’ option in the exporter. Be very careful, since accidentally not setting the append flag will simply overwrite the file without warning. Also, when joint names are case-specific when appending and must match exactly the names of the model.

A Maya script that eases the export/model setup workflow described here is included. It creates an interface to save many of the settings described here and in the next section in a Maya scene. It was used for nearly all the models that were exported throughout production and is presented here as is… it worked for me - I hope it works for others. If nothing else it provides a starting point for others to understand how the .lta format can be used. It is described mode fully in another section.

Model setup using ModelEdit

After exporting a character model, a few things need to be done to get it to appear in the game. These things are done in ModelEdit. This tool has been around for a few years and hasn’t changed a lot, in spite of our workflow changing a lot. What that means is that there are a lot of options that probably haven’t been used in a while and may be obsolete.

The new Lithtech file format exists in two forms. The exporter creates a user-friendly data file (.lta or ltc), but this needs to be compiled as an ltb file for use in the engine. An .lta file is a text file containing all the model and animation data. An ltc file is a compressed version of this, and is what was used for most TRON 2.0 models. ModelEdit only reads .lta or ltc files, not ltb files. ModelEdit can be used to convert between ltc and .lta files. In addition to this, a command line tool, LTC.exe, can be used to convert between .lta and ltc files. For help using this tool, execute the command ‘LTC’. ModelPacker.exe is used by ModelEdit to create ltb files.

There are several things that need to be set up in ModelEdit to get models working. As an example, a fully setup character, Game\Chars\Models\Character_Sample..lta, has been provided that is the exported version of the Maya scene Character_Sample.mb.

User Dims

The most basic thing that needs to be set on models is the User Dims. This is basically a bounding box for each model. To see this box in ModelEdit, select ‘Options > Show User Dimensions’. By default the dims are a long box. This needs to be changed to more closely match the size of the model. This can be done either by adjusting the ‘+’ and ‘-‘ buttons in the ‘Animation Edit’ section of ModelEdit or by selecting ‘Animation > Dimensions…’ and entering appropriate values. One thing to know about user dims is that the X value must always equal the Z value. If not the engine will pick one and apply it to both, producing strange results. Another thing to notice is that user dims can be set per animation. To avoid possible timing issues with changing dims, they are usually set the same for all animations on a character. The only exception in TRON 2.0 is the crouching animations for player characters. All human characters in TRON 2.0 have X=24, Y=53, Z=24.

Weight Sets

In order to render in the engine, character models need to have several ‘weight sets’ created. Weight Sets are used by the programmers to tell a character to play more than one animation at a time, such as the recoil animations or the upper/lower body blending in multiplayer. Select ‘Model > Edit Weighted Animation Blending’ in ModelEdit. Weight Sets are created one at a time by clicking the ‘Add Set’ button and entering the name. The following sets need to be added to every character model: Null, Upper, Lower, blink, twitch. To set the Weight Sets, select one or more nodes in the ‘Nodes’ window and set the appropriate value in the ‘Current Node Weight’ window. (When setting this number, don’t press enter, as it will exit the dialogue and frustrate you).

  • Twitch - select all the nodes in the node window and set the Weight to ‘2’. Setting the weight to ‘2’ tells the engine to additively blend animations and in this case allows the twitch on dead bodies and recoil on shot enemies.
  • Blink – select the Eyelid node (if one exists) and set its value to 2. This will cause the engine to play an animation called ‘blink’ if it exists constantly as long as the character is alive and blend it over whatever the character is doing. This could be used creatively…
  • Upper – select all the nodes in the upper body of the character and set the weight to ‘1’. This tells the engine to replace the animation on these nodes with the desired upper body animation.
  • Lower – select all the nodes in the lower body of the character and set the weight to ‘1’. Note that if there is a node controlling the translation of the model, it should be in the lower body.
  • Null – leave all nodes set to zero.

Note that other than the Upper and Lower sets in multiplayer characters, all of these can be left at zero and the models will work fine. The sets just need to exist for the engine to be able to set up each character. Non-character models do not need weight sets.

Sockets

Sockets are created to define locations where other models or FX can be attached to characters. The most noticeable place where sockets are used is in the gun hands of character models. This is the only socket I can think of that is necessary for a character to function properly. This socket must be named ‘RightHand’, but can be attached to any node in the model (for example, the laser shooting super soldier has a RightHand socket attached to his Head node.) To create this socket in ModelEdit, select the desired node (usually the right hand) in the Nodes window. Then select ‘Sockets > Add Socket…’, and enter the name ‘RightHand’. The socket will be created at the location and orientation of it’s parent node. Usually this will need to be edited. This is most easily done by showing attachment models in ModelEdit. (Unfortunately, new sockets don’t show attachments until the model is saved and re-opened.) Select ‘Options > Show Sockets’ and ‘Options > Show Attachments’. Now double click the socket name (RightHand) in the ‘Sockets’ window. In the ‘Attachment’ field of this properties window, enter or browse to the location of an attachment model .lta file (gun, flashlight…). Also in this window are entry boxes for orientation, translation, and scale values. These are very helpful when you know exactly what they need to be, but can be a little counterintuitive when starting from scratch since they are based on the orientation of the parent node. It’s easier to use the ‘Transform Edit’ controls. The Red, Green, and Blue boxes correspond to the colored axes of the socket in the ModelEdit viewport. Translation and Rotation are usually all that is needed to position the attachment into place. Scale is usually only used if an attachment that is shared among several characters needs to be adjusted to fit onto larger (or smaller) body part. All the sockets that you create are listed in the ‘Sockets’ window in ModelEdit. Other important sockets that every character should have are LeftFoot and RightFoot. These are needed to create footprints and accurately located footstep sounds. Other than this the main uses for sockets are hats, glasses, holstered weapons. To see how these and other sockets are set up, examine the sample character. Most characters have about a dozen sockets even though many of them aren’t used by all the characters. This is for consistency, so no one needs to remember which character gets which sockets. A socket name will not be valid unless it is appears on a list determined by game code. The full available list can be seen by opening DEdit, selecting an AI and opening the attachments property. One other thing… the exporter plug-in allows sockets to be created and exported from Maya. To do this create an object (usually a locator) and add a Boolean attribute called ‘sockets’ and set it to ‘1’. This object can be used to orient objects within Maya and may be easier to work with than ModelEdit’s controls.

Importing Sockets and Weight Sets

Sockets and Weight Sets are two things that are commonly imported from similar existing models. This can be done by selecting ‘File > Import…’. To import only Sockets and Weight Sets, check the boxes next to those options, and uncheck Animations. Then browse to a previously set up model with a matching skeleton and click ‘Open’. This can save a lot of tedious work, but some sockets may still need to be adjusted depending on the situation. Among the other options, Animations can also be imported from one model to another (instead of using a child model). When importing Animations, you should always import User Dims and Translations simu.ltaneously to avoid needing to reset this information. The ‘UV Coords’ is no longer used.

Child Models

Child models are added in ModelEdit by selecting ‘Child Model > Add ChildModel…’ and browsing to the desired .lta or ltc file. The only requirement for a model to be a valid child model is that the hierarchy must match exactly that of the parent model. A model can have as many as 32 child models, some of which can be added in game code as needed. Generally, only 1-3 child models are needed, depending on the character, and they will be listed in the ‘Child models’ window in ModelEdit. If a child model has drastically different proportions than a character, you may notice the character distorting to match those proportions. This can be corrected by checking the box next to the distorted nodes in ModelEdit’s Nodes window. This tells the engine to ignore the translation information from the child model for this node and use only the rotation. In most TRON 2.0 characters, all the nodes are checked except translation, movement, and most Face nodes. These nodes contain mostly translation animation, so ignoring translation will kill the animation. The Face nodes that should be checked are the eye nodes and the eyelid node, since they only contain rotation animation. Note that this only works if a character shares the exact face setup as the child model. If this is not the case, all the face nodes should be checked.

Texture Setup

Setting up textures and render styles in ModelEdit is done in the Piece Info window. This is accessed by highlighting a model piece in the ‘Pieces’ window and selecing ‘Piece > Piece Info…’. This can be the most confusing part of setting up a model. The main things to understand here are the Texture Indices and Render Style Index. All of the textures and render styles associated with a model are listed in an attribute file. Characters are in modelbutes.txt and props are in proptypes.txt. Here is an example of a Super Soldier’s texture list:

Skin0         = "chars\skins\SSLtBody.dtx"

Skin1         = "chars\skins\SSLtHead.dtx"

Skin2         = "chars\skins\SSLtPack.dtx"

Skin3         = "chars\skins\shinyspot.dtx"

RenderStyle0  = "RS\default.ltb"

RenderStyle1  = "RS\envmap.ltb"

RenderStyle2  = "RS\glass.ltb"

RenderStyle3  = "RS\Glow.ltb"

The Texture Index refers to the Skin number in this list. The Render Style Index refers to the Render Style number in this list. For example the ‘body’ piece of the model will use Skin0 and RenderStyle0, so the indices will stay at the default values of zero. Some render styles use multiple textures. The only commonly used render style like this is envmap.ltb. An example of its use would be the Super Soldier’s backpack. This uses RenderStyle1, Skin2 as the main texture map, and Skin3 as the environment map. To set this up, the ‘Number of Textures’ option needs to be set to ‘2’. Then Texture Index 0 should be set to ‘2’ (for Skin2) and Texture Index 1 should be set to ‘3’ (for Skin3’). The Render Style Index should be set to ‘1’ (for RenderStyle1). There is also an option for ‘Render Priority’. This is used to insure proper sorting of transparent models. All non-transparent models should have this set to ‘0’. Most models using alpha transparency render styles should have this set to ‘1’ to insure that that piece will always be rendered properly when it is in front of an opaque piece. Complex model setups, like Armstrong’s beard, can have a wide range of render priorities to sort the pieces properly.

Saving and Compiling

The last thing that needs to happen in ModelEdit is to save and compile the model. To Save and Compile, select ‘File > Save and Compile…’. There are several options here, but only a couple that are ever actually used. One is the compression type. The default compression type is (RLE 16) which in the case of some animations, is too much compression. I generally compress unanimated models at ‘(RLE 16)’ and compress any thing with subtle animations using ‘(RLE16)PlayerView’. This difference is that with (RLE16)PlayerView, everything is compressed to 16bit except translation which stays at 32bits. This basically results in smoother animations. The other commonly used option is ‘Exclude Model Geometry’. This can be used for any model that is exclusively a child model and allows for really good data compression since the geometry is simply thrown out. The good news about the compile window is that all the settings are saved per model, so the only need to be set when first exported, if at all.

Other ModelEdit functions

Here are the other most commonly used ModelEdit functions.

Animation Editing

ModelEdit has a number of functions to allow simple editing of animation data. An animation cannot be edited if it is being shared from a child model. In the ‘Animations’ window, the animations are listed with a check mark in the box next to the name if they can be edited. Right clicking on the name of an animation will bring up a menu with options to rename, duplicate, or delete the animation. The animation time slider displays the keyframes of an animation as red (or green) ticks. For editing purposes, ModelEdit allows you to ‘tag’ a group of keyframes. Keyframes can be tagged individually by double clicking the red ticks in the time slider. This actually toggles the tagged state, so double clicking again will untag the keyframe. Tagged keyframes will appear as blue ticks. Groups of keyframes can be tagged by holding down the ‘Shift’ key and click-dragging the mouse across the group of red ticks. The tagged state of keyframes is not saved with the file. Right clicking the time slider opens a menu. Here are the useful options in this menu:

  • Delete Keyframe – This will delete the current keyframe from the animation. It will not work on the first or last frame of the animation.
  • Delete Tagged Keyframes – This allows multiple keyframes to be tagged and deleted simu.ltaneously. Deleting unnecessary keyframes is a useful file size optimization.
  • Clip After Keyframe – This will delete all the keyframes after the current keyframe.
  • Clip Before Keyframe – This will delete all the keyframes before the current keyframe.
  • Insert Time Delay – This will allow a time delay between two keyframes to be specified, and is used a lot in tweaking the timing of animations in cut-scenes.

More useful functions can be found in the ‘Animation’ menu:

  • Set Animation Rate – This changes the keyframe rate of an animation. Most TRON 2.0 animations come from motion capture data, which has 30 frames per second. This function is used to reduce that rate. Most TRON 2.0 AI animations are reduced to 7.5 frames per second, while cut-scene animations are 10 frames per second. Tagged frames are protected from this function, so if there are rapid motions in the animation, tagging those frames will allow them to retain the full rate.
  • Set Animation Length – This will scale the speed of an animation. During TRON 2.0 production, it was the easiest way to accurately set the timing of animations.
  • Set Animation Interpolation – Interpolation is what the engine does to blend from one animation to another. This function allows the time of this blend to be set. The default is 200 ms, and that is good for most purposes. Looping animations and cut-scene animations usually have 0 interpolation.
  • Make Continuous - This will duplicate the first frame of an animation and place it at the end to create a rough looping effect. This isn’t perfect in most cases, but is a quick way to get a looping animation for testing purposes.
  • Reverse – This will reverse the frames of an animation so that it plays backwards.
  • Create Single Frame – This creates a one frame animation from the current frame of an existing animation.
  • Translation – This is used to add a positional offset to an animation.
  • Rotate – This is used to add a rotational offset to an animation.

Frame Strings

It is also possible to add commands to animations so that they are executed at a desired keyframe. This is done in ModelEdit by setting the animation to the desired keyframe and entering the command in the ‘Frame String’ text field (at the bottom of the ModelEdit interface). A keyframe that has a Frame String will appear as a green tick in the animation timeslider, as opposed to the default red tick. Multiple commands can be added to the same keyframe by separating the commands with a semicolon. There are many possible commands that can be used here – pretty much any command that can be sent to a character through triggers in the game will also work here. The most common ones are:

  • FOOTSTEP_KEY 1 – Right Footstep. This will play the appropriate sound effect when the right foot hits the ground and should be placed that point in the animation. It will also leave a footprint at the correct place in the snow.
  • FOOTSTEP_KEY 2 – Left Footstep. This should be placed when the left foot hits the ground.
  • DOOR – Activate a door object. This should be placed at the keyframe where the door should start opening.
  • OPEN – This command is used with smart objects to activate an object associated with the smart object. An example of this is the ‘Desk’ smart object where the OPEN command activates a chair to move when the animation pulls it from under the desk. For more information on smart objects see the AI docs.
  • FX <fx name> - This will play an FX object at the desired keyframe. An example of this in action is the dissolve body FX (FX AIBodyRemove).
  • Attach <socket name> <attachment name> – This will cause an attachment to be spawned at the specified socket and keyframe. An example is the cigarette appearing in an AI’s hand at the appropriate time (Attach LeftHand cigarette).
  • Detach <socket name> – This will remove an attachment from a character at the desired keyframe.

Importing LODs

Model LODs are another confusing part of model setup. Since they are not necessary, they may not be worth the trouble when experimenting. Nevertheless, here is how they can be imported using ModelEdit. LOD models should first be exported as a separate .lta file, and the pieces should be named exactly as the pieces in the main file. LODs are imported on a piece-by-piece basis from this file. In ModelEdit, highlight the desired piece in the ‘Pieces’ window and select ‘File > Import Custom LODs…’. Browse to the file containing the LOD pieces and click ‘Open’. A window will open containing a list of all the pieces in that file. Select the appropriate piece and click ‘OK’. Now open the ‘+’ sign next to the piece name in the Pieces window. It should open to two ‘0.00’ children. Here’s the tricky part that will be frustrating. One of these is the original and the other is the LOD, but it can be difficult to guess which one. Usually the top 0.00 piece is the LOD, so highlight it and select ‘Piece > Piece Info…’. The Texture and Render Style information should match the original Piece. In the LOD Properties section, set the Distance to a value other than 0. This will be the distance where the original model piece will swap with the new LOD. This process will need to be repeated for each piece of each LOD. Most of the characters in TRON 2.0 have two full LODs, one at 250 units, and on at 550.

Command String

The model’s Command String is used to store various commands and settings used by the engine when setting up a model. In previous versions of Lithtech, there were many commonly used commands that were placed here, but many of those are now obsolete. The only thing the Command String is currently being used for is enabling shadows on a model. To access the Command String in ModelEdit, select ‘Model > Command String…’. To turn in shadow casting simply enter “ShadowEnable” in the text field.

Piece Merging

A piece-merging feature was added to help optimize the number of geometry pieces in a model. It will merge all pieces that share a render style and texture. To use it highlight the desired pieces in the ‘Pieces’ window and select ‘Piece > Merge Selected’. This allows modelers to keep models in separate pieces in the modeling software if desired and wait to combine them in the exported model for optimization.

Null LODs

It is possible to have model pieces disappear when models are a certain distance from the player. This is done in ModelEdit by highlighting the desired piece in the ‘Pieces’ window and selecting ‘Piece > Create Null LOD…’, then enter the desired distance. This was used as an optimization in Armstrong’s beard, which mostly disappears at about 600 units.

Bute Files

All models in the game need to be defined in an attribute file. Characters are defined in ‘modelbutes.txt’, props are defined in ‘proptypes.txt’, and attachments are defined in ‘attachments.txt’. There is a not a lot that needs to be understood about these files in order to add to them, but not following the format exactly can cause disastrous results. For this reason, they should be modified at your own risk, and never without first backup them up. Most new models are created by simply cutting and pasting new model listings from existing, similar models and changing the number, Name, the model filename, the Skin and RenderStyle lines. It is very important that each model has a unique number and name, and that each attribute file contains no gaps in numbers (example: a file that contains [Model56] and [Model58], but not [Model57] will crash the game. Also, a file that contains two [Model56] listings will crash the game). This is pretty important, but it’s really all that needs to be understood to add most new models. Characters can be a little more complex for two reasons. One is the Skeleton section, which is used to define hit detection per skeleton and can be enormously painful to deal with. A lot can be done with it without any changes. The other extra piece of information for characters is the ‘DeathmatchModels’ section. To add new multiplayer models, in addition to the model listing already described, the model must be added to this list using the ‘Name’ of the model listing (example ‘Name36 = “NewModelName”’). This covers all the needed basics for model setup in TRON 2.0, but again modify at your own risk and be sure to backup the originals.

LtExport.mel Script

As mentioned in the exporter section, as MEL script was created to help streamline our workflow and give the ability to store a lot of settings in the Maya scene that would otherwise need to be set in ModelEdit every time a model is re-exported. It is intended to be an interface to the exporter plugin. This is 100% artist created tool and most of it was created as a means to learn MEL scripting. Because of this, it is unsupported and may not be the best way to do everything… but it works for us, and nearly all TRON 2.0 (and TRON) models were exported using this script as an interface. The script requires the file ‘LTC.exe’ to support the compressed ltc version of the .lta file format. To use this script, place it in a user script directory, or Maya’s Scripts\Others\ folder. Enter the command ‘ltExport’ to open the interface. Included is a brief description of options, settings, and known limitations in the script.

Edit Options

The ‘Edit Options’ section contains functions that attempt to mimic ModelEdit functionality:

  • UserDims – This button creates a bounding box that can be scaled normally to set the dims. It correctly locks the X and Z values to avoid bad dims. The scale values will be saved on the skeleton so that they can always be exported correctly.
  • Sockets – This opens a window that will give options to create and delete sockets and works very much like the ModelEdit dialogue.
  • Piece Info – For texture setup, this works exactly like ModelEdit’s Piece info window. Select a Piece and press this button and the window will open to allow settings to be made. It also has a place to enter the correct game texture path so that textures will show up in ModelEdit automatically (This may not be usable except during production).
  • CommandString – This is exactly like the ModelEdit Command String window. Anything entered here will be saved with the skeleton.
  • ChildModels – This allows child models to be specified. A list of child models is saved with the skeleton.
  • NodeFlags – This mimics the ‘Nodes’ window of ModelEdit, allowing the node check box setting to be saved with the skeleton.

Other Setting Options

Here are the other available setting options:

  • Append Animation – When checked on, this will cause the exporter to always append animations without warning. When off, a warning will come up to prevent accidentally overwriting files. This sets the ‘-append’ flag of the exporter flag of the exporter plugin.
  • Use TimeSlider range – This sets the ‘-usePlaybackRange’ flag of the exporter plugin.
  • ExportWeightSets – This will create (but not correctly set) the default set of weight sets needed to for characters to work in the game.
  • Export Child Models – This was added to allow a model to have child models in Maya, but export without them if needed.
  • CompileModel – This will automatically compile the model as an ltb file. When checked on, an option is exposed to ‘Compile with no geometry’. This is used when exporting many animations to a child model.
  • Dims – This provides a numerical input for setting User Dims.
  • Scale – This sets the ‘-scale’ flag of the exporter plugin.
  • Interpolation – This sets the interpolation time of an animation. It is the same as using ‘Set Animation Interpolation’ in ModelEdit.
  • ToolPath – This should provide the folder where the file ‘LTC.exe’ exists
  • GamePath – This may not be usable, but shouldn’t affect the working of the script.

In addition to these options, the script will export LODs for models by looking for a very specific naming convention in the Maya scene. I can’t think of a better way to describe this setup than to point to the sample Maya character setup scene (Character_Sample.mb). It contains LOD pieces that have been hidden to prevent them from exporting. Unhiding them and exporting this scene using the ltExport Script will result in fully set up LODs.

Limitations

There are lots of issues that were never addressed due to lack of time. Here are a couple that you’ll probably notice:

  • There are a lot of ‘Browse’ buttons in the interface. Most of them don’t work at all and the main File Browser will only work if you select an existing .lta or ltc file. I never did figure out how to get file browsing to work correctly.
  • The script will give an error if it is run when there are no skeletons in the scene.
  • The script recognizes the first skeletal hierarchy in the scene to be the export skeleton. This is always the top joint listed in the outliner or the leftmost one in the hypergraph. Occasionally a hidden skeleton could be listed before the desired one and cause a lot of confusion.
  • There is a weird bug that occurs when child models are specified and exported using this script… the normals are destroyed. Fortunately this can be remedied in ModelEdit by selecting ‘Model > Generate Vertex Normals’. Because of this, unless there are several child models, I don’t really use the child model part of the script much.
  • The ‘Node Flags’ option will be made invalid if the skeleton is changed after setting the flags. The exporter won’t notice this, and may cause an assortment of problems if invalid values are exported.


Player Messages

The “player” object handles a number of different trigger messages. This document will list the syntax and results of these various messages. In the syntax definitions below, parameters that appear in angle brackets, i.e. < > are required parameters. Parameters that appear in square brackets, i.e. [ ] are optional.

Music

Most of the player messages to affect the game music take an optional timing parameter. This parameter may be any of the following:

Default - Will use the default value that is defined in the Control File or by DirectMusic

Immediately - Will happen immediately

Beat - Will happen on the next beat

Measure - Will happen on the next measure

Grid - Will happen on the next grid

Segment - Will happen on the next segment transition

Intensity

This command changes the intensity of the music.

          Music i <intensity> [timing]

          Music intensity <intensity> [timing]

Secondary Segment

This command will play a secondary segment.

Music secondary <segment name> [timing]

Music ps <segment name> [timing]

Motif

This command will play a motif.

Music motif <motif style> <motif name> [timing]

Music pm <motif style> <motif name> [timing]

Volume

This command will adjust the volume of the music.

Music volume <volume adjustment in db> Music v <volume adjustment in db>

Stop Secondary Segment

This command will stop a secondary segment.

Music stopsecondary <segment name> [timing]

Music ss <segment name> [timing]

Stop Motif

This command will stop a motif.

Music stopmotif <motif name> [timing]

Music sm <motif name> [timing]

Play

This command will start the music playing.

Music play

Music p

Stop

This command will stop playing the music.

Music stop [timing]

Music s [timing]

Lock Mood

This command will lock the music in the current mood.

LockMood

LockMusic

Unlock Mood

This command will unlock the music from the currently locked mood.

LockMood

LockMusic

Lock Event

This command will lock the music in the current motif.

LockMotif

LockEvent

Unlock Event

This command will unlock the music from the currently locked motif.

LockMotif

LockEvent

Rewards

Rewards give the player experience points. The <reward name> parameter specifies the name of the reward given. The amount of experience received is set in missions.txt and is indexed by <reward name>

Reward <reward name>

Objectives, Optional Objectives, and Mission Parameters

The player’s objectives are divided into three classes. Objectives are goals which must be accomplished to complete the mission. Optional Objectives are goals that may be accomplished, but are not required. Mission Parameters are rules for how your objectives may be accomplished. The objective IDs referred to in these commands are the ids of strings in the CRes.dll string table.

Adding Items

These commands will add a new required item.

Objective add <objective id>

Option add <optional id>

Parameter add <parameter id>

Removing Items

These commands will remove an item.

Objective remove <objective id>

          Option remove <optional id>

          Parameter remove <parameter id>

Removing All Items

These command will remove all items.

Objective removeall

          Option removeall

          Parameter removeall

Complete Items

This command will mark an objective or optional objective as completed. Parameters cannot be marked for completion.

Objective completed <objective id>

          Option completed <optional id>

Keys

The key IDs referred to in these commands are the ids of entries in the KeyItems.txt attributes file.

Add Key

This command will add a new key item.

Key add <key id>

Remove Key

This command will remove a key item.

Key remove <key id>

Remove All Keys

This command will remove all key items.

Key removeall

Transmission

Transmissions are text messages that are sent to the player. The transmission ID referred to in this command is the id of a string in the CRes.dll string table. The ActivePlayerComm is an optional parameter set to 1 or 0. If set to 1, then the transmission will be displayed with the MP name of the ActivePlayer in this format: “<ActivePlayerName>: <Message>”. The TeamNumber is an optional parameter set to 1 or 0, referring to the team numbers. Only players on the TeamNumber team will receive the transmission.

Transmission <transmission id> [ActivePlayerComm][TeamNumber]

Credits

The credits message starts or stops the on screen credits.

Start credits

This message will start the display of credits.

Credits on

Stop credits

This message will stop the display of credits.

Credits off

Intro credits

This message will start the display of the intro credits.

Credits intro

Intel

This message will give the player an intelligence item.

The <text id> parameter is the ID of a string in the CRes.dll string table.

The <popup id> parameter is the ID of an entry in the PopupItems.txt attributes file which will define how the item will be displayed in popups and in the menus.

The [intel] parameter should be 1 if the item should be considered as valuable intelligence data and 0 if it should be considered general information. This will be 0 by default.

The [show] parameter should be 1 if the popup up should be displayed and 0 if it should not. This will be 0 by default.

The [add] parameter should be 1 if the intel item is to be added to the list of intelligence items the player sees in the menu. This will be 1 by default.

MissionText <text id> <popup id> [intel] [show] [add]

Fade In, and Fade Out

These messages cause the screen to fade in or fade out over the given number of seconds.

     FadeIn <time>

     FadeOut <time>

Mission Text

This message will cause text to appear teletype style on the screen. The text id is the id of a string in the CRes.dll string table.

MissionText <text id>

Mission Failed

This message will let the Mission Failure screen to appear and display the specified text. The text id is the id of a string in the CRes.dll string table.

MissionFailed <text id>

Remove Bodies

This message will remove all body objects that are currently in the level.

RemoveBodies

Remove Bad AI

This message will remove all AI in the level that are considered “Bad” to the player.

RemoveAllBadAI

Resetting Inventory

This message will reset all the weapons and give only the default weapon for the mission.

ResetInventory

Pickup Items

PickupItems are any item that the player can pickup throughout the levels. They may also be acquired through searching or by being a default of the mission.

Weapons

This message will give the player the specified weapon and will switch to that weapon.

AcquireWeapon <weapon name>

This message tells the player to change to the specified weapon if they currently have the weapon. The <weapon name> parameter refers to the name of a weapon definition in weapons.txt.

ChangeWeapon <weapon name>

Ammo

This message will give the player the specified ammo.

AcquireAmmo <ammo name>

Mods

This message will give the player the specified weapon mod.

AcquireMod <mod name>

Gear

This message will give the player the specified gear.

AcquireGear <gear name>

Health

This message will give the player the max amount of health.

FullHealth

     This message will clear the sleeping damage rom the player

Wakeup

Vehicles

The player can have vehicle physics applied to them in a number of circumstances. Riding a PlayerVehicle, a snowmobile, is the most obvious but following a PlayerLure is also considered riding a vehicle.

PlayerVehicles

This message will force the player to get off on vehicle they currently are on and use the normal player physics

Dismount

PlayerLures

This message tells the player to begin following the specified PlayerLure. The <PlayerLure name> parameter must refer to the name of a PlayerLure object on the level.

FollowLure <PlayerLure name>

This message will tell the player to stop following any lure it is currently following.

CancelLure

Overlays

Overlays are sprites that are displayed on screen such as the scope crosshairs, and certain cinematic specific overlays. To define what sprites are displayed per overlay look in the Overlay section of layout.txt.

This message turns the specified overlay on or off. The <Overlay Id> parameter is the id of the overlay to use. For a list of overlay Ids see ClientShellDLL\ClientShellShared\Overlays.h. The <On or Off> parameter specifies if the overlay should be rendered on the screen or not.

Overlay <OverlayId> <On or Off>


AI

TRON 2.0 AI

AI Placement in Dedit

All AI placed through Dedit are CAIHuman. In addition to placing CAIHumans, other AI objects are placed in Dedit that allow AI to understand the world. AI navigate the world by planning paths through connected AIVolumes. AI determine what objects or places of interest are nearby by searching for AINodes. AIVolumes and AINodes are invisible to the player.

Properties on the CAIHuman object determine the AI’s look and behavior:

CAIHuman Parameters:

ModelTemplate | The model template from modelbutes.txt. The model template deteremines the ltb model file, skeleton, animation data file, skin textures, and renderstyles. The model template references an AI template in aibutes.txt. The AI template determines the AI’s alignment, and sensory parameters.
Brain | The brain template from aibutes.txt. The brain determines a number of parameters that affect the AI’s behavior.
GoalSet | The goalset defined in aigoals.txt. The goalset lists the goals that will control the AI’s behavior.

AIButes.txt

AIButes.txt contains various sections defining parameters that affect AI behavior. The major sections are AIBrains, and AI Attribute Templates. Sections not described are insignificant, self-explanatory, or beyond the scope of this document (AIStimulus – tweak at your own risk!).

AIBrain

AIBrains specify a number of parameters that define an AI’s behavior. Many AI may share the same brain. There are a number of required parameters, and some optional parameters. Some parameters found in AIbutes.txt were not used for TRON 2.0.

Required Parameters:

DodgeVectorCheckTime | How frequently we check to see if we need to dodge a vector
DodgeVectorCheckChance | The % chance we will check to see if we need to dodge a vector once this time is up
DodgeVectorDelayTime | After dodging a vector, the time we must wait before we can check again
DodgeVectorShuffleDist | How much space is needed to shuffle.
DodgeVectorRollDist | How much space is needed to roll.
DodgeVectorShuffleChance | The % chance the dodge will be a shuffle.
DodgeVectorRollChance | The % chance the dodge will be a roll.
DodgeVectorBlockChance | The % chance the dodge will be a block.
DodgeProjectileCheckTime | Not used for TRON 2.0.
DodgeProjectileCheckChance | Not used for TRON 2.0.
DodgeProjectileDelayTime | Not used for TRON 2.0.
AttackRangedRange | The min/max distance we must be at to attack with a ranged weapon (e.g. rifle)
AttackThrownRange | The min/max distance we must be at to attack with a thrown weapon (e.g. grenade)
AttackMeleeRange | The min/max distance we must be at to attack with a melee weapon (e.g. sword)
AttackChaseTime | After we lose sight of our target, how long do we wait before chasing
AttackChaseTimeRandom | An additional random amount of time to the above time
AttackPoseCrouchChance | When we enter the attack state, chance we will crouch and fire
AttackPoseCrouchTime | How long we stay crouched
AttackGrenadeThrowTime | How often we'll consider throwing a grenade
AttackGrenadeThrowChance | Chance we'll attempt to throw the grenade after this time expires
AttackCoverCheckTime | How often we check for the presence of cover
AttackCoverCheckChance | Chance we'll check once this time expires
AttackSoundTimeMin | Min amount of time since any AI played combat dialog before this AI can play combat dialog
AttackWhileMoving | Can the AI attack while moving?
AttackFromCoverCoverTime | How long we will stay covered for before uncovering
AttackFromCoverCoverTimeRandom | An additional random amount of time to the above time
AttackFromCoverUncoverTime | How long we will stay uncovered for before covering
AttackFromCoverUncoverTimeRandom | An additional random amount of time to the above time
AttackFromCoverReactionTime | If uncovered and shot at, the delay before we will go back to cover
AttackFromCoverMaxRetries | How many times we will attempt to go for new cover when cover becomes invalidated.
AttackFromVantageAttackTime | Time we will fire from a vantage node before moving on to the next one
AttackFromVantageAttackTimeRandom | An additional random amount of time to the above time
AttackFromViewChaseTime | How long we will we wait to chase at an attack from view node
ChaseExtraTime | Not used for TRON 2.0.
ChaseExtraTimeRandom | Not used for TRON 2.0.
ChaseSearchTime | Not used for TRON 2.0.
PatrolSoundTime | Time between chances of playing a patrolling sound
PatrolSoundTimeRandom | An additional random amount of time to the above time
PatrolSoundChance | The chance we'll play a patrol sound after the patrolsoundtime
DistressFacingThreshhold | Dot product (-1=180' to 1=0') at which target must be facing towards us to be considered threatening
DistressIncreaseRate | Rate at which distress increases when being threatened
DistressDecreaseRate | Rate at which distress decreases when not being threatened
DistressLevels | How many levels of distress to go through before panic
MajorAlarmThreshold | How high alarm level must be to start searching (threat assumed)
ImmediateAlarmThreshold | How high alarm level must be to know threat is immediate
TauntDelay | How long between checks to taunt
TauntChance | Chance the AI should taunt when it is able to
CrawlThreshhold | Not used for TRON 2.0.
CrawlChance | Not used for TRON 2.0.
CrawlLifetime | Not used for TRON 2.0.
CanLipSync | Can this AI lip sync?
DamageMask | Mask of accepted types of damage. Other types are ignored. "None" means affected by all damage types.

Optional Parameters:

Parameters that are not required for every AI are specified in the AIBrain with name = value pairs, in the form AIDataN = “SomeLabel=SomeValue”. For example:

AIData0 = "AccidentChance=0.1"

AIData1 = "DivergePaths=1.0"

AIData2 = "OneAnimCover=1.0"

 | AccidentChance |  | Percent chance of AI having an accident. Used for AIs falling on their faces when jumping over railings.
 | BreaksDoors |  | This was not used in TRON 2.0.
 | CannotPathThruDoors |  | AI may not go through doors. Used to contain ambient life.
 | ChaseEndurance |  | Number of seconds running before AI needs to catch his breath. Used for police.
 | DeflectChance |  | Percent chance of deflecting a bullet. Used for DataWraiths with katanas.
 | DisappearDistMin |  | Minimum distance away a threat must be to trigger AI to disappear. Used for DataWraiths.
 | DisappearDistMax |  | Minimum distance away a threat can be to trigger AI to disappear. Used for DataWraiths.
 | DisappearFadeTime |  | Amount of time to fade translucency when disappearing. Used for DataWraiths.
 | DisposeLantern |  | AI must detach object from light socket when leaving an investigative state. Used for DataWraiths with search lanterns.
 | DivergePaths |  | AIs try to split up taking separate paths to the same destination.
 | DoNotCloseDoors |  | AI does not close doors after going through them.
 | DoNotDamageSelf |  | AI does not damage himself with his own weapons. Used to keep Volkov from injuring himself with rocket splash damage.
 | DoNotExposeHiding |  | AI does not expose a hidden player, in a hiding spot. Used for ambient life.
 | DoNotToggleLights |  | AI does not attempt to turn on/off lights.
 | DynMoveTimeMin |  | Minimum time AI stands still while attacking with a ranged weapon.
 | DynMoveTimeMax |  | Maximum time AI stands still while attacking with a ranged weapon.
 | DynMoveBackupDist |  | Distance an AI backs up while attacking with a ranged weapon.
 | DynMoveFlankPassDist |  | Distance past a target AI will travel when flanking.
 | DynMoveFlankWidthDist |  | Distance to the side of a target AI will travel when flanking.
 | IgnoreJunctions |  | AI cannot get lost in junctions.
 | LethalSpecialDamage |  | SpecialDamage will instantly kill AI. Used for ambient life, when hit with sleeping damage, electrical damage, etc.
 | LongJumpHeightMin |  | Minimum height of parabola when jumping long distances. Used for DataWraith lunge.
 | LongJumpHeightMax |  | Maximum height of parabola when jumping long distances. Used for DataWraith lunge.
 | LungeDistMin |  | Minimum distance away a target can be to trigger a lunge. Used for DataWraith.
 | LungeDistMax |  | Maximum distance away a target can be to trigger a lunge. Used for DataWraith.
 | LungeSpeed |  | Speed AI travels while lunging. Used for DataWraith.
 | LungeStopDistance |  | Distance in front of a target to end a lunge. Used for DataWraith.
 | GoalProximityDist |  | Distance to trigger the ProximityCommand goal.
 | MeleeKnockBackDist |  | Distance to push back a target with a melee attack.
MinPathWeight |  | Minimum weight of an AIVolume that AI will use when pathfinding. Used to restrict some AI to preferred volumes.
 | MusicMoodMin |  | Minimum music mood AI will set. Used to keep ambient life from affecting music.
 | MusicMoodMax |  | Maximum music mood AI will set. Used to keep ambient life from affecting music.
 | NoDynamicPathfinding |  | AI will not try to avoid dynamic obstacles.
OneAnimCover |  | AI uses one movement-encoded animation to attack from cover, rather than a series of animations.
 | PrimaryWeaponOnLeft |  | Primary weapon is on AI’s left side, instead of the default right side.
 | ProneDistMin |  | Minimum distance from target AI must be to go prone.
 | ProneSlideDist |  | Distance AI slides forward when diving to the ground to go prone.
 | ProneTime |  | Amount of time AI stays prone.
 | ReappearDist |  | Distance away AI reappears after disappearing. Used for DataWraith.
 | RetreatTriggerDist |  | Distance from target to AI required to trigger AI to retreat. Used for DataWraith.
 | RetreatJumpDist |  | Distance AI jumps back when retreating. Used for DataWraith.
 | RetreatSpeed |  | Speed AI travels while jumping back when retreating. Used for DataWraith.
 | SleepTimeMin |  | Minimum time AI sleeps. Used for powered-down SuperSoldiers.
 | SleepTimeMax |  | Maximum time AI sleeps.

AI Attribute Templates

AI attribute templates define parameters for AI behavior associated with a model. Multiple models may share the same template.

Required Parameters:

Name | Name of template, referenced in modelbutes.txt as AIName.
RunSpeed | Speed AI moves when running with an animation that uses constant velocity (rather than movement encoding).
JumpSpeed | Speed AI moves while playing a jumpUp animation.
JumpOverSpeed | Speed AI moves while playing a jumpOver animation.
FallSpeed | Speed AI moves while falling.
CrawlSpeed | Not used in TRON 2.0.
WalkSpeed | Speed AI moves when walking with an animation that uses constant velocity (rather than movement encoding).
SwimSpeed | Not used in TRON 2.0.
FlySpeed | Not used in TRON 2.0.
Marksmanship | Not used in TRON 2.0.
Bravado | Not used in TRON 2.0.
SoundRadius | Sound radius used when AI plays dialogue sounds.
HitPoints | Amount of hit points AI starts with. Modified by difficulty.
Armor | Amount of Armor points that AI begin with.
Accuracy | Percent chance a shot will hit AI’s target.
AccuracyIncreaseRate | Rate AI regains accuracy after a change due to attacking from cover.
AccuracyDecreaseRate | Not used in TRON 2.0.
FullAccuracyRadius | Radius from AI where AI has perfect accuracy.
AccuracyMissPerturb | Amount of perturb on bullets that miss their target.
MaxMovementAccuracyPerturb | Maximum amount of perturb caused by aiming at a moving target.
MovementAccuracyPerturbTime | Amount of time to catch up when aiming at a moving target.
CanUseVolumeXXX | AI may pathfind through AIVolumes of type XXX (e.g. CanUseVolumeJumpUp). By default, AI may pathfind through all AIVolume types. Types of AIVolumes are described in the AIVolume section of this document.
CanXXX | TRUE if sense is turned on for AI, where XXX is a sense. (e.g. CanSeeEnemy).
XXXDistance | Distance that AI can sense XXX. (e.g. SeeEnemyDistance).

Senses referenced by XXX above include:

SeeEnemy | AI sees an enemy.
SeeEnemyLean | AI sees a leaning enemy.
SeeEnemyWeaponImpact | AI sees someone get shot by an enemy.
SeeEnemyDanger | AI sees something dangerous. Used for AIGoalLoveKitty.
SeeEnemyDisturbance | AI sees something disturbed by an enemy.
SeeEnemyLightDisturbance | AI sees a light disturbed by an enemy (turned on or off).
SeeEnemyFootprint | AI sees an enemy’s footprint.
SeeAllyDeath | AI sees an ally’s dead, or knocked out body.
SeeAllyDisturbance | AI sees an ally get disturbed.
HearEnemyWeaponFire | AI hears an enemy fire a weapon.
HearEnemyWeaponImpact | AI hears an enemy’s weapon impact.
HearEnemyFootstep | AI hears an enemy’s footsteps.
HearEnemyAlarm | AI hears an alarm sound, due to an enemy’s presence.
HearEnemyDisturbance | AI hears an enemy make a disturbance.
HearAllyDeath | AI hears an ally die.
HearAllyPain | AI hears an ally shout in pain.
HearAllyWeaponFire | AI hears an ally fire a weapon.
HearAllyDisturbance | AI hears an ally get disturbed.
SeeAllyDistress | AI sees an ally in distress, going for backup.
SeeAllySpecialDamage | AI sees an ally affected by special damage (glued, in bear trap, on fire, etc)

AIVolumes

AIVolumes denote open space to an AI, and must be placed everywhere an AI may travel. AIVolumes are invisible to the player.

The restrictions and requirements for placing AIVolumes in general are:

· AIVolumes do not contain any physical obstacles (e.g. desks, walls, columns, etc).

· AIVolumes align exactly with adjacent AIVolumes.

· AIVolumes containing doors must be narrow volumes just containing the dimensions of the closed door. Only one door may be in an AIVolume.

· AIVolumes have minimum dimensions in XZ of 48x48.

· AIVolumes are generally 16 units tall, and 8 units off the ground. This is not a requirement.

· AIVolumes touching other AIVolumes must have a connection of at least 48 units.

There are several varieties of AIVolumes, used for different purposes. Below are descriptions of the purposes and parameters of the different types of AIVolumes. AIVolumes not listed below were not used on TRON 2.0.

AIVolume

AIVolume is the most basic volume type. All other AIVolume objects are derived from AIVolume. All AIVolumes have the parameters below at a minimum.

Lit | FALSE if volume is in the dark. Tells AI whether they need to turn on a light. Can be toggled through the commands “lit” and “unlit”. Example: msg aivolume01 unlit
Region | AIRegion this AIVolume is part of. Regions are used for alarms and for searching.
LightSwitchNode | LightSwitch AINodeUseObject used to toggle the light state of this volume (lit/unlit).
PreferredPath | TRUE if this volume should be preferred over other for pathfinding. In TRON 2.0 this was used a couple of different ways. Only SuperSoliders and Robots can travel through AIVolume with PreferredPath set to true so they don’t walk through spaces that are too small for them to fit. The AIBrain AIData MinPathWeight=1 takes care of this. We also used this to make the AI path finding look better in some situations. For instance in Japan, when a DataWraith was patrolling a section of street sometimes she would walk through a flower bed to get to her next patrol point. Setting the PreferredPath to True on the AIVolumes that were on the streets helped make the AI paths look better by making them walk on the streets when in a relaxed state..

AIVolumeAmbientLife

There is nothing special about AIVolumeAmbientLife. The volume types simply exists so that ambient life AI can be use a set of volumes that other AI do not use (e.g. so that a rat can run under a table, but a soldier cannot). AI are restricted from pathfinding through AIVolumeAmbientLife by adding this line to their AI Attribute Template in AIButes.txt:

CanUseVolumeAmbientLife = FALSE

AIVolumeJumpOver

AI use AIVolumeJumpOvers to pathfind and jump over obstacles (e.g. fences). This volume should connect to AIVolumes horizontally. AI jump from one edge of the volume to the opposite edge. The height of the parabola of the jump is determined by the height of the top of the volume.

AIVolumeJumpUp

AI use AIVolumeJumpUps to pathfind and jump up and down from things (e.g. rooftops). This volume should connect to AIVolumes above and below the jump destination. AIVolumeJumpUp has several additional parameters.

OnlyJumpDown | This volume may only be used to jump down from something (and not jump up onto something).
OnlyJumpWhenAlert | AI may only jump through this volume when alerted to a threat.
HasRailing | AI must play an animation to jump over a railing when jumping through this volume.

AIVolumeJunction

AI get lost when chasing a target, and running through an AIVolumeJunction while the target is out of sight. A junction connects up to four AIVolumes. AIVolumeJunctions have extra parameters determining the percent chance of different actions that can be taken once the junction is reached. The extra parameters are duplicated for each of the connecting volumes in four possible directions, North, South, East, and West.

Junction Actions:

Nothing | Run through junction and get lost.
Continue | Run through junction and get lost.
Peek | Peek into a connecting volume, and then run a different direction.
Search | Run into a volume and search its AIRegion.

AIVolumeLadder

AI use AIVolumeLadders to pathfind and climb on ladders. This volume should be centered on the ladder, and connect to AIVolumes above and below the ladder. AI play a special death animation when killed inside an AIVolumeLadder.

AIVolumeLedge

AI play a special death animation when killed inside an AIVolumeLedge. These volumes are typically used on balconies, rooftops, and cliffs. The angle of the Yaw determines which direction the AI will fall off the ledge.

AIVolumeStairs

AI use AIVolumeStairs to pathfind and walk up stairs. This volume should enclose the staircase, and connect to AIVolumes above and below the stairs. AI play a special death animation when killed inside an AIVolumeStairs. The angle of the Yaw determines which direction the AI will roll down the stairs when killed.

AIVolumePlayerInfo

AIVolumePlayerInfo is totally unrelated to the other AIVolumes. AIVolumePlayerInfo is not used for AI pathfinding. It is used to determine if the player is hidden, or attackable from an associated AINodeView. AIVolumePlayerInfo has a number of unique parameters.

On | Volume is usable for hiding, and sense mask is enabled when On is TRUE. This volume can be messaged “On” and “Off” with commands.
SenseMask | SenseMask applied to the volume, that blocks out specified senses while AI are relaxed. Used in the HARM Villa to make enemies ignore Cate when she was in unrestricted areas.
Hiding | Player can use this volume to hide.
HidingCrouch | Player can use this volume to hide, if she is crouched.
ViewNodes | List of AINodeViews that are associated with this volume. If an AI cannot find a path to the player, and wants to attack, he may go to an AINodeView and attack from there.

AINodes

AINodes are objects that provide information to AI about opportunities at particular locations. AI must be able to find a path to an AINode, so all AINodes must be inside of AIVolumes. AINodes are invisible to the player.

There are several varieties of AINodes, used for different purposes. Below are descriptions of the purposes and parameters of the different types of AINodes. AINodes not listed below were not used on TRON 2.0.

AINode

AINode is the most basic node type. All other AINode objects are derived from AINode. All AINodes have the parameters below at a minimum.

Face | AI turns to face the direction of this node when arriving at this node.
Alignment | Only AI with the specified alignment may use this node. By default, Alignment is set to “None,” which means all AI may use the node. An AI’s alignment is specified in the AI Attribute Template in AIButes.txt.
StartDisabled | This node starts disabled. AI ignores disabled nodes. Nodes may be enabled / disabled through the commands “enable” and “disable”.

AINodeBackup

AI runs to an AINodeBackup when he sees a threat and needs backup. The goal GetBackup sends an AI to an AINodeBackup. Other AI that are within the AINodeBackup’s stimulus radius will respond to the AI when he arrives at the node, and follow him to the threat if they have the goal RespondToBackup.

AttractRadius | AI must be within this radius for the node to be valid to go to for backup.
ResetTime | Amount of time before any AI may use this node again.
StimulusRadius | AI within the stimulus radius may respond to the call for backup.
Movement | Movement animation AI uses to get to the node.
CryWolfCount | Number of times AI may call for backup at this node before allies think he is crying wolf. Count resets when allies see a threat
Command | Command to run on arrival to the node.

AINodeCover

AI run to an AINodeCover when a threat is present, and the AI activates goal Cover or AttackFromCover.

Duck | AI ducks at node and pops up to attack.
BlindFire | AI ducks at node, and fires blindly over an object.
1WayRoll | AI rolls away from node to one side.
2WayRoll | AI rolls away from node to either side.
1WayStep | AI stands at node, and steps out from behind something to attack. Node rotation determines the direction of the step.
2WayStep | AI stands at node, and steps out from behind something to attack. AI may step out from 2 directions. Node rotation determines the directions of the step.
IgnoreDir | Ignore the direction of a threat when determining if node is valid for cover.
Fov | Field of view that threat must be in to validate the node for cover.
Radius | AI must be within this radius for the node to be valid to go to for cover.
ThreatRadius | If threat enters the ThreatRadius, node is invalidated for cover.
Object | Object or AINodeUSeObject to activate on arrival at the node. (e.g. to flip a table to take cover behind).
Timeout | Amount of time AI can stay at the node.
HitpointsBoost | Amount to boost AI’s hitpoints while at the node.

AINodeDeath

AI pathfind to an AINodeDeath before dying with a special animation from the DramaDeath goal.

AINodeExitLevel

AI walk to an AINodeExitLevel if they have the ExitLevel goal, and no other goals are active. This node is mainly used for reinforcements leaving the level if there are no open patrol routes of guard posts.

AINodeGoto

AI pathfind to an AINodeGoto when given a Goto goal with an AINodeGoto as the destination.

Command

Command AI runs when arriving at the AINodeGoto.

AINodeGuard

AI stays within the ReturnRadius of an AINodeGuard when he has the Guard goal, and is unaware of a threat.

ReturnRadius | AI stays within this radius when unaware of a threat. AI returns to this radius when giving up on a chase or search.
GuardedNodes | List of AINodeUseObject nodes AI may use while assigned to this AINodeGuard. Only the AI assigned to the AINodeGuard may use these nodes.

AINodePanic

AI run to AINodePanic nodes when they are in distress. AI plays a panic animation at the node.

Next | Next AINodePatrol on the patrol route.
Action | Animation to play at the node.
Command | Command to run on arrival to the node.

AINodePatrol

AI with the Patrol goal patrol along a route set by chaining AINodePatrol nodes.

AttractRadius | AI must be within this radius for the node to be valid to go to for backup.
ResetTime | Amount of time before any AI may use this node again.
StimulusRadius | AI within the stimulus radius may respond to the call for backup.
Movement | Movement animation AI uses to get to the node.
CryWolfCount | Number of times AI may call for backup at this node before allies think he is crying wolf. Count resets when allies see a threat
Command | Command to run on arrival to the node.

AINodeSearch

AI pathfind between AINodeSearch nodes when searching for a known threat. At each node, AI plays a searching animation.

ResetTime | Amount of time before any AI may visit this node again.
ShineFlashlight | Play a flashlight animation.
LookUnder | Play a look under animation.
LookOver | Play a look over animation.
LookUp | Play a look up animation.
LookLeft | Play a look left animation.
LookRight | Play a look right animation.
KnockOnDoor | Play a knock animation.
Alert | Play an alert animation.
SearchType | Invalidation test if any: Default, OneWay, or Corner. OneWay nodes are only valid if AI approaches facing the same direction the node points. Corner nodes are only valid if AI approaches facing the opposite direction from the direction the node points. If set to Corner then the Yaw should be pointed at the corner the AI is going to peak around when searching.

AINodeTalk

AINodeTalk is exactly the same as AINodeGuard, but AI stand at AINodeTalk nodes when having a conversation with another AI.

AINodeUseObject

AINodeUseObject nodes are special general-purpose nodes. When an AI arrives at an AINodeUseObject, he animates using a set of animations defined by the SmartObject specified on the node. The set of animations usually includes a transition in and out, some looping idles, and some intermittent fidgets.

Object | Optional object to activate on arrival to the node.
Radius | AI must be within this radius for the node to be a valid destination.
Movement | Movement animation used to travel to the node (e.g. Run or Walk).
SmartObject | SmartObject defining the purpose of the node. SmartObjects are defined in AIGoals.txt.
PreActivateCommand | Command to run on arrival to the node.
PostActivateCommand | Command to run when leaving the node.
ReactivationTime | Amount of time before any AI may use this node again.
FirstSound | Sound to play on arrival to the node.
FidgetSound | Sound to play while playing fidget animations.
OneWay | This node may only be used when approaching facing the direction matching the direction of the node.

AINodeVantage

AI run to an AINodeVantage to attack an enemy from a specific position. When an enemy’s position validates an AINodeVantage, the goal AttackFromVantage sends the AI to the AINodeVantage to attack.

IgnoreDir | Ignore the direction of a threat when determining if node is valid.
Fov | Field of view that threat must be in to validate the node.
Radius | AI must be within this radius for the node to be valid.
ThreatRadius | If threat enters the ThreatRadius, node is invalidated.
Object | Object or AINodeUseObject to activate on arrival at the node. (e.g. open a hatch or window shutters).

AINodeVantageRoof

AINodeVantageRoof is exactly the same as AINodeVantage. Having a separate node type allows goals to use specific nodes. DataWraiths use special logic in AttackFromVantageRoof to determine when to jump onto a roof to attack from an AINodeVantageRoof.

AINodeView

AI run to an AINodeView to attack an enemy that they cannot find a path to. If an AI cannot find a path to a threat, and the threat is in an AIVolumePlayerInfo, the goal AttackFromView sends the AI to an AINodeView associated with the AIVolumePlayerInfo.

Radius

AI must be within this radius for the node to be valid to go to it.

AIGoals

Goals control an AI’s behavior. AI are given a goalset in Dedit. Goalsets are defined in AIGoals.txt. Goals may also be added and removed dynamically through commands. Goals compete for activation, and only one goal is active at a time. Each goal has an Importance value, which determines its priority over other goals. Goals may optionally have required SenseTriggers and/or Attractors. Attractors are types of nodes, or types of SmartObjects. The Importance of a goal is zero when SenseTrigger and/or Attractor requirements are not satisfied. Goals may optionally have parameters that can be set through name=value pairs in commands. Goals not listed below were not used on TRON 2.0.

Alarm

AI runs to activate an alarm when an enemy is seen, then runs back to position where enemy was seen and searches the AIRegion.

Importance | 32
SenseTriggers | SeeEnemy
Attractors | AINodeUseObject with SmartObject Alarm

Animate

AI plays an animation on command. This goal is used to script animations.

Importance | 100
SenseTriggers | None
Attractors | None

Parameters:

ANIM=animname | Name of animation to play, from ltb file.
LOOP=1 or 0 | Infinitely loop the animation if TRUE.

AttackFromCover

AI runs to the nearest valid AINodeCover and attacks from there.

Importance | 27
SenseTriggers | SeeEnemy
Attractors | AINodeCover

AttackFromVantage

AI runs to the nearest valid AINodeVantage and attacks from there.

Importance | 27
SenseTriggers | SeeEnemy
Attractors | AINodeVantage

AttackFromRandomVantage

AI runs to a random valid AINodeVantage and attacks from there.

Importance | 27
SenseTriggers | SeeEnemy
Attractors | AINodeVantage

AttackFromRoofVantage

AI runs to the nearest valid AINodeVantageRoof and attacks from there. AI will only activate this goal if no other AI are at AINodeVantageRoof nodes, and at least 3 AI are currently attacking the same target. Used for DataWraith.

Importance | 28
SenseTriggers | SeeEnemy
Attractors | AINodeVantageRoof

AttackFromView

AI runs to the nearest valid AINodeView and attacks from there. AI will only activate this goal if he cannot find a path to his target, and his target is an AIVolumePlayerInfo that has associated AINodeViews.

Importance | 27
SenseTriggers | SeeEnemy SeeEnemyLean HearEnemyWeaponFire HearEnemyWeaponImpact SeeEnemyWeaponImpact HearAllyDeath HearAllyPain HearAllyWeaponFire HearEnemyDisturbance SeeEnemyDisturbance
Attractors | AINodeView

Parameters:

SEEKPLAYER=1

AI will activate goal without first sensing anything if it receives the parameter SEEKPLAYER=1.

AttackMelee

AI attacks with a melee weapon, if he has one and target is within range set in AIBrain.

Importance | 24
SenseTriggers | SeeEnemy
Attractors | None

AttackProne

AI drops to lie on stomach and attack with a ranged weapon. AI first checks for clear space in front of him. Only one AI may AttackProne at a time, and timing is coordinated between all AI to control frequency.

Importance | 26
SenseTriggers | SeeEnemy
Attractors | None

AttackRanged

AI attacks with a ranged weapon, if he has one and target is within range set in AIBrain.

Importance | 23
SenseTriggers | SeeEnemy
Attractors | None

AttackRangedDynamic

AI attacks with a ranged weapon, if he has one and target is within range set in AIBrain. Ai constantly moves between shots. Moves are randomly selected. Moves include strafing, flanking, and backing up.

Importance | 23
SenseTriggers | SeeEnemy
Attractors | None

Chase

AI chases a target, and fires a weapon if allowed by the AIBrain. AI gets lost if chase path goes through an AIVolumeJunction, and target is not in sight. If target is lost, AI searches the AIRegion.

Importance | 20
SenseTriggers | SeeEnemy (other senses are used to get AI to lose interest in searching).
Attractors | None

Parameters:

SEEKPLAYER=1 | AI will activate goal without first sensing anything if it receives the parameter SEEKPLAYER=1.
NEVERGIVEUP=1 | AI will never lose interest in chasing if it receives the parameter NEVERGIVEUP=1. Used for DataWraiths in the trailer park, arena combat level.
KEEPDISTANCE=1 | AI will only come close enough to get target in firing range if it receives the parameter KEEPDISTANCE=1. Used for HARM Villa, where guards apprehend player rather than attacking.

CheckBody

AI checks the body of a dead or knocked out ally. Ally is woken if knocked out. If ally is dead, AI disposed of the body. AI searches the AIRegion after checking the body.

Importance | 15
SenseTriggers | SeeAllyDeath (other senses are used to get AI to lose interest in searching).
Attractors | None

Cover

AI runs to the nearest valid AINodeCover and takes cover. This goal only activates if AI has a ranged weapon. AI takes cover if he was not previously aware of a threat, and hears a bullet hit nearby.

Importance | 18
SenseTriggers | HearEnemyWeaponImpact
Attractors | AINodeCover

Destroy

AI walks to AINodeUseObject and animates destroying something. Animation may cause AI to fire a weapon, or attack with bare hands. Used for SuperSoldiers destroying environment.

Importance | 4
SenseTriggers | None
Attractors | AINodeUseObject with SmartObject Attackable or Smashable

DisappearReappearEvasive

AI disappears in a cloud of smoke, and reappears elsewhere. AI only disappears if an enemy is aiming a weapon at her. Frequency of any AI disappearing is coordinated between all AI. Used for DataWraith.

Importance | 31
SenseTriggers | SeeEnemy
Attractors | None

Parameters:

NOW=1 | AI will disappear on command if it receives the parameter NOW=1.
OVERRIDEDIST=dist | Distance used to override ReappearDist set in AIBrain.
DELAY=secs | Amount of time before AI reappears.

Distress

AI puts up hands in distress. This goal only activates if the AI is unarmed and a weapon is aimed at him. Distressing may lead to panicking, running to an AINodePanic.

Importance | 17
SenseTriggers | SeeEnemy
Attractors | None

DramaDeath

AI pathfinds to an AINodeDeath, and animates a dramatic death. This goal only activates when the AI dies.

Importance | 1000
SenseTriggers | None
Attractors | AINodeDeath

Parameters:

LAUNCH=1

Launch AI in a parabola to the AINodeDeath if the parameter LAUNCH=1 is set, rather than pathfinding.

DrawWeapon

AI draws a weapon (or weapons) when a target is sensed, if he has any weapons.

Importance | 50
SenseTriggers | SeeEnemy SeeEnemyLean SeeEnemyFootprint HearEnemyWeaponFire HearEnemyWeaponImpact SeeEnemyWeaponImpact HearEnemyFootstep HearEnemyAlarm HearEnemyDisturbance SeeEnemyDisturbance SeeEnemyLightDisturbance SeeAllyDeath HearAllyDeath HearAllyPain HearAllyWeaponFire SeeAllyDisturbance HearAllyDisturbance SeeAllySpecialDamage
Attractors | None

EnjoyPoster

AI examines something on a wall.

Importance | 4
SenseTriggers | None
Attractors | AINodeUseObject with SmartObject Examinable

ExitLevel

AI walks to an AINodeExitLevel, and deletes himself from the game. This is used to remove reinforcements who entered the level as the result of an alarm sounding. If the reinforcements cannot find any open guard nodes or patrol routes, they exit the level.

Importance | 7
SenseTriggers | None
Attractors | AINodeExitLevel

Flee

AI runs to an AINodePanic and panics. This goal only activates if the AI is unarmed. If no panic node is found, AI runs away randomly.

Importance | 16
SenseTriggers | SeeEnemy HearEnemyWeaponFire HearEnemyWeaponImpact SeeEnemyWeaponImpact SeeAllyDeath HearAllyDeath HearAllyPain HearAllyWeaponFire SeeAllyDisturbance
Attractors | AINodePanic

FollowFootprint

AI follows an enemy’s footprints, then searches the AIRegion.

Importance | 14
SenseTriggers | SeeEnemyFootprint
Attractors | None

GetBackup

AI runs to an AINodeBackup to call for help. If allies are within the stimulus radius of the AINodeBackup, and have the RespondToBackup goal, they will follow the AI back to where he last saw the enemy. If AI loses track of his target, he searches the AIRegion.

Importance | 30
SenseTriggers | SeeEnemy SeeEnemyWeaponImpact
Attractors | AINodeBackup

Goto

AI pathfinds to a specified node on command.

Importance | 8
SenseTriggers | None
Attractors | None

Parameters:

NODE=nodename | Name of node to pathfind to.
MOVEMENT=movement | Type of movement animation (e.g. Walk or Run).
AWARENESS=awareness | Awareness type of animation (e.g. Investigate).

Guard

AI stays within the radius of an AINodeGuard. The AINodeGuard may be assigned through a command, or the AI can find the nearest AINodeGuard. AI may wander within the radius, and activate goals associated with AINodeUseObject nodes that are guarded by the AINodeGuard. If AI leaves the guard radius to chase an enemy, he will return to the radius when he relaxes.

Importance | 5
SenseTriggers | None
Attractors | AINodeGuard

Parameters:

NODE=nodename

Name of node to assign as the AI’s AINodeGuard.

HolsterWeapon

AI holsters weapon. This goal only activates if AI has a weapon in his left and/or right hand.

Importance | 10
SenseTriggers | None
Attractors | None

Investigate

AI investigates a disturbance. AI pathfinds to a disturbance and looks around, then searches the AIRegion. The AI’s movement (walking or running) depends how alarmed the AI is. Disturbances have different alarm levels, and multiple minor disturbances accumulate to equal a larger disturbance. If the disturbed object has an AINodeUseObject pointing at it, the AI may activate the object (e.g. close a drawer). If it is the first minor disturbance, or the AI cannot pathfind to the disturbance, he will just look in the direction of the disturbance.

Importance | 13
SenseTriggers | HearEnemyFootstep HearEnemyWeaponFire HearEnemyWeaponImpact SeeEnemyWeaponImpact HearAllyDeath HearAllyPain HearAllyWeaponFire HearEnemyDisturbance SeeEnemyDisturbance SeeEnemyLightDisturbance SeeAllyDisturbance HearAllyDisturbance SeeAllySpecialDamage SeeEnemyLean SeeEnemy
Attractors | None

LoveKitty

This was not used in TRON 2.0.

Importance | 9
SenseTriggers | SeeEnemyDanger
Attractors | None

Lunge

AI lunges at a target and causes damage. Only one AI may lunge at a time. AI must have a path clear of static obstacles in front of her. Used for DataWraith.

Importance | 26
SenseTriggers | SeeEnemy
Attractors | None

Menace

AI walks to an AINodeUseObject and places a menace animation. This goal is used to make AI appear agitated when they are actually unaware of a threat. Used in levels where the AI is intended to already know that the player is around.

Importance | 4
SenseTriggers | None
Attractors | AINodeUseObject with SmartObject MenacePlace

MountedFlashlight

AI turns on/off flashlight mounted on rifle when entering/exiting a dark AIVolume.

Importance | 0
SenseTriggers | None
Attractors | None

Patrol

AI patrols on route set between AINodePatrols.

Importance | 2
SenseTriggers | None
Attractors | None

PlacePoster

This was not used in TRON 2.0.

Importance | 4
SenseTriggers | None
Attractors | AINodeUseObject with SmartObject PostingPlace

ProximityCommand

AI runs a command when he comes within proximity of an enemy. Command is set on CAIHuman object in Dedit.

Importance | 1000
SenseTriggers | SeeEnemy
Attractors | None

Parameters:

RESET=1

Reset the command to run again if AI receives the parameter RESET=1.

PsychoChase

AI chases an enemy relentlessly. No stimulus is required to activate the goal. AI ignores junctions, and never gives up.

Importance | 21
SenseTriggers | None
Attractors | None

RespondToAlarm

AI responds to an alarm. Alarms specify AIRegions where AI respond or go alert. If AI is in an alert AIRegion, he looks around. If he is in a respond AIRegion, he runs to the alarm. The alarm specifies a list of AIRegions to search after reaching the location of the alarm.

Importance | 19
SenseTriggers | HearEnemyAlarm
Attractors | None

RespondToBackup

AI responds to an ally’s call for backup. AI must be standing within the stimulus radius of an AINodeBackup that an AI with the goal GetBackup is running to. Responding AI follow the AI that called for backup back to the last place the enemy was seen, and search the region. If AI has called for backup too many times, without finding anything, allies believe he is crying wolf, and ignore his call for help.

Importance | 19
SenseTriggers | SeeAllyDistress. AI loses interest in RespondToBackup if he senses SeeEnemy.
Attractors | None

Retreat

AI jumps back to retreat from an enemy. AI only retreats from enemies wielding melee weapons. Used for DataWraith.

Importance | 25
SenseTriggers | SeeEnemy
Attractors | None

Ride

AI plays a riding animation when at an AINodeUseObject.

Importance | 500
SenseTriggers | SeeEnemy
Attractors | AINodeUseObject with SmartObject Ride

Search

AI searches a list of AIRegions on command. Used for scripting AI to search, without first sensing a disturbance.

Importance | 12
SenseTriggers | None
Attractors | None

Parameters:

REGION=list of AIRegions | Name of node to pathfind to.
MOVEMENT=movement | Type of movement animation (e.g. Walk or Run).

SerumDeath

AI dies instantly if hit with AntiSuperSoldierSerum while powered down. Any other damage type reduces hitpoints but does not kill AI. When AI reaches zero hitpoints, he powers down and regenerates full hitpoints, then powers up. Used for SuperSoldiers.

Importance | 1000
SenseTriggers | None
Attractors | None

Sleep

AI sleeps at an AINodeUseObject. Visual senses are turned off while sleeping.

Importance | 4
SenseTriggers | None
Attractors | AINodeUseObject with SmartObject Bed

Sniper

AI stands alert and fires at any enemy in view. If a node is not specified, AI will find the nearest node owned by his AINodeGuard. If AI is shot, he will choose a new node. Sniper nodes may be listed as view nodes of AIVolumePlayerInfos, so that AI chooses the best node to attack an enemy in specified areas.

Importance | 29
SenseTriggers | None
Attractors | AINodeUseObject with SmartObject Sniper

Parameters:

NODE=nodename

Name of node to go to, to fire from.

SpecialDamage

AI reacts to special damage types. AI plays a looping, incapacitating damage animation with a transition in and out. Some damage types knock the AI out, at which point weapons may be stolen. If the AI wakes up unarmed, he panics. Otherwise, he searches the AIRegion.

Importance | 1000
SenseTriggers | Anything sensed interrupts the AI’s search.
Attractors | None

Parameters:

PAUSE=1 or 0 | AI stops decrementing the damage timer when PAUSE=1, and continues when PAUSE=0. This command parameter is used when a player picks up a knocked out AI.
SLEEPFOREVER=1 | AI is put to sleep and never wakes up if it receives the parameter SLEEPFOREVER=1.

Talk

AI walks to an AINodeTalk to have a conversation with another AI. AI waits until all dialogue participants are in place. If AI is waiting at the node and notices a disturbance, he may investigate, and then return to the AINodeTalk.

Importance | 6
SenseTriggers | None
Attractors | None

Parameters:

RETRIGGER=1 | AI retriggers the dialogue object on arrival to the AINodeTalk if it receives the parameter RETRIGGER=1.
DISPOSABLE=1 | If AI receives the parameter DISPOSABLE=1, the conversation will never occur if the AI is drawn away to investigate a disturbance.
GESTURE=animname | Name of animation to play while having a conversation. Used for scripting gesture animations from dialogue objects.
MOVEMENT=movement | Type of movement animation (e.g. Walk or Run).

Work

AI walks to an AINodeUseObject and does some work. Work may include anything a SmartObject is set up to do. Work includes desk work, smoking, urinating, stretching, etc.

Importance | 4
SenseTriggers | None
Attractors | AINodeUseObject with SmartObject Work

SmartObjects

SmartObjects are defined in AIGoals.txt. A SmartObject is a template that announces an AINode’s purpose to an AI, and describes the animation set to play while using the SmartObject. In general, the AI will play a single Action animation, or a looping Idle animation with optional intermittent Fidget animations.

TRON 2.0 had 87 SmartObjects covering a wide variety of objects and activities, such as desks, microscopes, urinals, places to hammer, smoke, and lean. This document will not enumerate each of the TRON 2.0 SmartObjects, but will describe the properties and commands that define a SmartObject.

Here are a couple examples of SmartObjects:

// A desk that AI can sit at and do work.

[SmartObject1]

Name  = "Desk"

Flag0 = "WorkItem"

Cmd0  = "HumanUseObject Activity=DeskWork Pose=Sit LoopTime=[30.0,60.0] FidgetFreq=[8.0,10.0] LockNode=FALSE"

AddAnimsLTB0 = "\chars\models\anims\desk.ltb"

// A file cabinet that serves 2 purposes to AI:

// 1) AI may open and close the cabinet to do work in

//    its default state.

// 2) AI may notice that a player has opened the cabinet,

//    and put it into a disturbed state.

[SmartObject5]

Name  = "FileCabinet"

Flag0 = "WorkItem"

Cmd0  = "HumanUseObject Activity=FilingHigh LoopTime=[15.0,25.0] LockNode=FALSE"

Flag1 = "Disturbance"

Cmd1  = "HumanUseObject Action=CloseDrawer LockNode=FALSE"

StateDefault0 = "WorkItem"

StateDisturbed0 = "Disturbance"

AddAnimsLTB0 = "\chars\models\anims\filecabinet.ltb"

SmartObject Properties:

Name | Name of SmartObject.
Flag0-N | Type of SmartObject. A SmartObject may have any number of types. Types are listed in SmartObject Types table below.
Cmd0-N | Command for SmartObject type flag with matching index. Parameters for SmartObject commands are described in the table below.
StateDefault0-N | SmartObject types active in the Default state.
StateDisturbed0-N | SmartObject types active in the Disturbed state.
AddAnimsLTB0-N | Child ltb files containing extra animations that need to be loaded for the AI to interact with this SmartObject.

SmartObject Types:

Alarm | AI can sound an alarm at the node.
Attackable | AI can attack from the node.
Bed | AI can sleep at the node.
Coverable | AI can take cover at the node.
DamageType | SmartObject used to define animation resulting from taking special damage.
Disturbance | AI can investigate a disturbance at the node.
Examinable | AI can look at something on a wall.
LightSwitch | AI can turn on/off a light at the node.
MenacePlace | AI can play a menace at the node.
PostingPlace | AI can post something at the node. Used for police.
Ride | This was not used in TRON 2.0.
Smashable | AI can destroy something.
Sniper | AI can shoot someone from the node.
WorkItem | AI can do some work at the node. (e.g. sit at a desk)

SmartObject Command Parameters:

HumanUseObject | All SmartObject commands start with HumanUseObject, because they are setting parameters in the AIHumanStateUseObject.
Action | Action animation property from AnimationsHuman.txt.
Activity | Awareness animation property from AnimationsHuman.txt.
Mood | Mood animation property from AnimationsHuman.txt.
Pose | Posture animation property from AnimationsHuman.txt.
WeaponAction | WeaponAction animation property from AnimationsHuman.txt.
LoopTime | Minimum and maximum for random range of seconds to animate. [0, 0] means loop infinitely.
FidgetFreq | Minimum and maximum for random range of seconds between fidget animations.
LockNode | FALSE if AINode is re-usable after an AI has used this SmartObject.

AI Commands

Level Designers can modify AI behavior by sending commands to AINodes, AIVolumes, and AIs themselves.

Commands to AINodes:

ENABLE | Enable the AINode, so that AI may use it.
DISABLE | Disable the AINode, so that AI will ignore that it exists. If AI was currently at the node, AI will lose interest in whatever he was doing.

Commands to AIVolumes:

ENABLE | Enable the AIVolume, so that AI may use it for pathfinding.
DISABLE | Disable the AIVolume, so that AI will ignore that it exists, and may not pathfind through it.
LIT | Make the AIVolume appear lit to the AI.
BRIGHT | Make the AIVolume appear lit to the AI.
UNLIT | Make the AIVolume appear unlit to the AI.
DARK | Make the AIVolume appear unlit to the AI.

Commands to AIVolumePlayerInfos:

ON | Enable the AIVolumePlayerInfo, so that player may use its hiding properties, and SenseMask will be enabled.
OFF | Disable the AIVolumePlayerInfo, so that player may not use its hiding properties, and SenseMask will be disabled.

Commands to AI:

HIDDEN 1 or 0 | AI is hidden if HIDDEN 1, and exposed if HIDDEN 0.
CINERACT animname | AI plays a specified animation once.
CINERACTLOOP animname | AI loops a specified animation.
TRACKLOOKAT | AI tracks player with his head.
TRACKAIMAT | AI tracks player with his head and torso.
TRACKNONE | AI disables head and torso tracking.
ALIGNMENT alignment | Set an AI’s alignment. **Alignment is Case Sensitive!! Valid alignments are: GoodCharacter BadCharacter NeutralCharacter
DAMAGEMASK mask | Set an AI’s damage mask to a mask listed in AIButes.txt, or to None.
GOAL_xxx name1=value1 name2=value2 ... | Set parameters on a goal that the AI already has, where xxx is the name of a goal. For example: GOAL_chase SEEKPLAYER=1 KEEPDISTANCE=1
GOALSET goalset | Change an AIs goalset. Goalset may be any goalset listed in AIGoals.txt.
ADDGOAL goal name1=value1 name2=value2 ... | Add a goal to an AI, and optionally set parameters on the new goals. For example: ADDGOAL goto NODE=AINodeGoto1 MOVEMENT=run
REMOVEGOAL goal | Remove a goal from an AI.
GOALSCRIPT goal1 name1=value1 name2=value2 ... goal2 name1=value1 name2=value2 ... | Add a sequence of goals to an AI. This is used to script an AI to do a series of actions. There can be any number of goals, and each goal can set any number of parameters. For example: GOALSCRIPT goto NODE=AINodeGoto1 MOVEMENT=run animate ANIM=dance LOOP=1


AI Gameplay Setup

TRON 2.0 AI Gameplay Setup

This document describes how the TRON 2.0 AI systems were used to setup basic gameplay. This is not an exhaustive description of every piece of the AI systems, but instead an overview of the most commonly used pieces, highlighting things that may not be obvious by looking at the code or Dedit properties.

GoalSets

In general, AI in TRON 2.0 are assigned either the Patrol, Guard, or Reinforcement GoalSet. There are a total of 46 GoalSets defined in aigoals.txt, but most are variations of Patrol or Guard for special characters. Please see aigoals.txt for details of what Goals are in each GoalSet.

Patrol, Guard, and Reinforcement share identical combat behavior, but vary in their relaxed and investigative behaviors. Below are descriptions of the expected behaviors with each of these GoalSets.

Patrol GoalSet

· The Patrol GoalSet includes the DefaultRequired and DefaultBasic GoalSets to define the standard combat behavior.

· Patrol’s relaxed behaviors are defined by the Goals Patrol and Work.

· AI will walk along a patrol path defined by LevelDesign through AINodePatrols.

· A patrolling AI owns his path, and no other AI can use it until he dies or otherwise relinquishes it.

· A patrol path can be assigned by specifying a node on the path in the AI’s Initial Command: goal_patrol node=AINodePatrol9.

· If no node is specified, AI will find the nearest unowned AINodePatrol, and take ownership of that node’s path.

· A patrolling AI may not own an AINodeGuard. Patrol and Guard are mutually exclusive.

· If a patrolling AI walks near an unowned work node (AINodeUseObject with SmartObject set to Work), he will stop patrolling to do some “work,” then continue patrolling. Patrolling AI will ignore any work nodes that are owned by an AINodeGuard.

· A patrolling AI may animate an investigative walk rather than the routine patrol walk through the command: goal_patrol awareness=investigate. This is useful for levels where AI are intended to be eternally suspicious regardless of stimuli.

· Patrolling AI will turn off lights as they leave an AINodePatrol, and turn on lights at a destination AINodePatrol.

Guard

· The Guard GoalSet includes the DefaultRequired and DeafultBasic GoalSets to define the standard combat behavior.

· The Guard GoalSet includes the Sniper Goal.

· Guard’s relaxed behaviors are defined by the Goals Guard, Work, and Menace.

· A guarding AI will stay within the return radius of his guard node. If he is drawn outside of this radius, he will walk to return to it.

· A guarding AI owns his guard node, and no other AI can use it until he dies or otherwise relinquishes it.

· An AINodeGuard can be assigned by specifying a node in the AI’s Initial Command: goal_guard node=AINodeGuard22.

· If no node is specified, AI will find the nearest unowned AINodeGuard.

· A guarding AI may not own any AINodePatrols. Patrol and Guard are mutually exclusive.

· The guarding AI owns his guard node, and the guard node may own additional nodes. Owned nodes are AINodeUseObjects used for the Work, Menace, and Sniper Goals.

· An AI that owns a guard node will randomly select work nodes owned by his guard node, rather than always going to the next nearest work node. This AI may not use any unowned work nodes. The same applies to menace nodes.

· Menace nodes are used exactly like work nodes, but are used in levels where the AI is supposed to already be aware of the enemy’s presence, and should appear permanently agitated, even when the AI system thinks the AI is relaxed. In other words, when the AI is not in combat he will run between menace nodes (AINodeUseObjects with SmartObject set to Menace), and play aggressive animations.

· When a guarding AI investigates a disturbance, he will stop at the edge of his guard radius and play an alert animation, rather than walking all the way to the disturbance.

· A Guarding AI will not go to search nodes outside of his guard radius.

· If the guarding AI has previously seen the player, heard an alarm, or been shot, he will ignore his guard radius and investigate anywhere. Once the AI returns to a relaxed state of awareness, he will start paying attention to his guard radius again.

· If the AI notices a disturbance outside of his guard radius, he will not speak. This prevents an AI from repeatedly saying “I hear you!,” “What was that!,” “I know you’re there!,” but never coming to investigate.

· If an AI currently owns a talk node, he will ignore his guard node. This is covered in more detail later in the section about the Talk Goal and conversations.

Reinforcement

· The Reinforcement GoalSet is used for AIs who spawned as reinforcements, usually from a command in an alarm.

· The Reinforcement GoalSet includes the DefaultRequired and DeafultBasic GoalSets to define the standard combat behavior.

· The Reinforcement GoalSet includes the Sniper Goal.

· Reinforcement’s relaxed behaviors are defined by the Goals Guard, Work, ExitLevel, and Menace. (See the Guard GoalSet above for more info on Menace).

· A reinforcement AI will enter the level and respond to whatever is currently going on. Once the situation dies down, and the AI returns to a relaxed state of awareness, he will look for unclaimed guard and patrol nodes. If one is found, he will claim a node and activate the Guard or Patrol goal, and behave like an ordinary AI that is guarding or patrolling.

· Nodes may be unclaimed because the AI that previously owned them have died. In this case the reinforcements are replenishing the level to maintain some number of AI, and keep the level at approximately the same difficulty.

· Alternatively, the level may intentionally contain a surplus of nodes, so that the level will become harder once reinforcements are brought in.

· If no unclaimed nodes are found, the AI will look for an AINodeExitLevel. If an ExitLevel node is found, the AI will walk to the node and get removed from the level. These are normally placed in areas the player cannot get to, so it is not obvious the AI is getting instantly removed from the game.

· The AI will not look for an ExitLevel node until he has been in the level for at least 5 seconds. This restriction prevents an AI from spawning near an ExitLevel node, and immediately removing himself before noticing an alarm sounding, or other stimuli.

Scripting

Scripting was avoided as much as possible in TRON 2.0, but there were situations where some amount of scripting was necessary to drive the story or vary the gameplay for specific levels. Here are the ways we accomplished scripted behaviors without breaking the autonomy of the AI.

· Enable/Disable Node Commands: The majority of scripting in TRON 2.0 involved enabling and disabling nodes, or assigning new nodes with command, such as: goal_guard node=AINodeGuard45. This gives control over where AI are idling while still allowing some randomness and allows them to react normally to whatever situation they find themselves in.

· GoalScripts: GoalScripts supply an AI with a sequence of Goals to complete. When one Goal is satisfied (e.g. the AI has arrived at the destination node of a Goto Goal), the next Goal activates. GoalScripts may be interrupted if the AI notices a disturbance, and the GoalScript will continue once the AI returns to a relaxed state of awareness. GoalScripts are useful for making an AI go fro place-to-place and animate.

· Search: Normally AI search after activating other Goals (e.g. after investigating or chasing and losing the target). In cases where AI are spawned with the intention of immediately searching, they may be given the Search Goal, which is a scripted Search. AI with the Search Goal can be given a list of comma-separated regions to search: addgoal search region=airegion01,airegion02,airegion03. AI who search through normal means will only search their current region.

· Patrol: Another way to script searching behavior is to spawn AI and assign them patrol routes. The Patrol Goal may be instructed to play investigative walking animations: addgoal patrol awareness=investigate. In some TRON 2.0 levels, we periodically spawn a patrolling AI to ensure the level will never be completely empty (and boring to the player), even when all AI have been killed leaving no one to sound alarms. An AI may be spawned, instructed to patrol, and then removed through a command on a destination patrol node.

Conversations

The Talk Goal allows AI to coordinate meeting up, having a conversation, and going on to do other things. The Talk Goal also handles responding to interruptions, and possibly returning to have the conversation later. There are basically two options for setting up AI to have a conversation:

Statically Positioned Conversation Participants:

· AI are placed at AINodeTalk nodes and given initial commands of: addgoal talk node=AINodeTalk04. AI will walk to Talk nodes and wait for a dialogue object to be triggered.

· If both AI are within the radii of their Talk nodes when the corresponding dialogue object is triggered, they will have their conversation.

· When the conversation ends, the dialogue object will run its finished and cleanup commands.

· An AI with a Talk Goal and Talk node will ignore his Guard and Patrol Goals. The Talk Goal overrides other relaxed goals, so the AI may still have a full GoalSet, such as Patrol or Guard.

· If an AI is at a Talk node, and notices a disturbance, he will investigate. Guard node radii will be ignored.

· If the dialogue object is triggered while one or both of the dialogue participants are not relaxed, the dialogue will not play, and the dialogue object’s cleanup command will be run.

· If the dialogue object was not triggered while the AI was investigating, when the AI returns to a relaxed state of awareness, he returns to his Talk node and continues waiting for the dialogue to be triggered.

· The Talk Goal parameter disposable=1 tells the AI not to return to his Talk node if he was disturbed while waiting for the conversation. In this case, the AI will simply return to his normal relaxed behaviors and forget about having the dialogue.

Dynamically Positioned Conversation Participants:

· AI may be anywhere in the level, running various Goals. They do not need to be near their Talk nodes.

· When a dialogue object is triggered, commands are sent to the dialogue participants: addgoal talk node=AINodeTalk09 retrigger=1. If either AI are outside of their Talk node radii, the dialogue will not start. The parameter retrigger=1 tells the AI to retrigger the dialogue object once the AI arrive at their Talk nodes.

· Once both AI are in position, the conversation starts.

· When the conversation ends, the dialogue object will run its finished and cleanup commands.

· The above steps may be used to get AI to walk towards each other and start talking, or to make an AI stop working and start talking to someone.

A couple more general notes about the Talk Goal:

· While the Talk Goal is active, AI will face each other and talk while playing their basic idle animation (usually 3StGd).

· AI may be instructed to play gesture animations at key points in the conversation. From the dialogue object, send a command to the AI: goal_talk gesture=NameOfAnim.

· If a dialogue object is triggered, and one or more of the dialogue participants does not exist (probably because he is dead), the dialogue will not play and the dialogue object’s cleanup command will run.

Goal Notes

Below are points of interest about various Goals:

Chase

· Once the Chase Goal is activated (by seeing the enemy) the AI will never lose interest in chasing, with the exceptions described below.

· An AI may lose interest in chasing if another goal activates that puts the AI in a state of awareness other than alert (so, relaxed or suspicious). Normally any Goals that activate in favor of Chase are other alert Goals, such as AttackRanged. The exceptions are Goals like SpecialDamage, which incapacitate the AI and then send him searching for his attacker. When an AI wakes up from SpecialDamage, he is investigative and loses interest in chasing.

· An AI may lose interest in chasing if he loses his target in a Junction volume, and gives up.

· Chase Goal Parameters:

o SeekPlayer=1: This parameter instructs the AI to immediately start chasing a player, even if no stimuli have been sensed. This allows the AI to cheat in combat levels where the AI is intended to already know where the player is. The AI ignores Junction volumes while seeking the player. Once the player has been seen, the AI falls back to normal chasing behavior where he can get lost in Junction volumes.

o NeverGiveUp=1: This parameter instructs the AI to cheat indefinitely. The AI will always know where the player is, and will never lose interest in chasing. This parameter was used for the TRON 2.0 ninja trailer park level, where combat should never stop, but ninjas may get temporarily incapacitated when hit with SpecialDamage (e.g. poison).

AttackFromCover

· Cover nodes have an optional parameter Object. This Object may be an object like a table that can be flipped on its side to use for cover. If an AINodeUseObject also points to this object, and the UseObject node has a SmartObject set to something for cover, the SmartObject can specify what animation the AI should use when activating the Object. For example, SmartObject FlipTable tells an AI how to animate when flipping a table to use as cover. After flipping the table, the AI runs to the Cover node, and runs the normal AttackFromCover behavior.

AttackFromVantage

· AINodeVantage may specify an optional Object property. This object will be triggered On before the AI starts attacking from the Vantage node, and triggered Off after the AI attacks. This could be used to open and shut window shutters, for example.

· There are a couple Goals derived from AttackFromVantage that may be useful, or may be good templates for doing similar things.

o AttackFromRandomVantage works exactly like AttackFromVantage, but does not require any stimuli to activate the Goal, and chooses valid Vantage nodes at random instead of choosing the nearest valid node.

o AttackFromRoofVantage works exactly like AttackFromVantage, but uses AINodeVantageRoof attractor nodes instead of normal AINodeVantages. An AI may only activate AttackFromRoofVantage if no other AI already has the Goal active, and only if at least 3 AI are already attacking the same target.

AttackFromView

· An AI will attack from an AINodeView if the AI has sensed stimuli of the enemy’s presence, and cannot find a path to the enemy, and the enemy is in an AIVolumePlayerInfo that points to a View node that the AI can find a path to.

· SeekPlayer=1: This parameter instructs an AI to attack from a View node without first sensing any stimuli.

Work

· AINodeUseObjects set to SmartObjects for work are used with the Work Goal. These nodes control most of TRON 2.0’s relaxed behaviors (smoking, working at desks, dancing, leaning, etc).

· If a Work node has a ReactivationTime of zero, an AI may not use this node again until first using another Work node. Any ReactivationTime greater than zero will allow an AI to re-use the same node once the node is active again.

· An AI can be instructed to immediately stop working at a node by sending a Disable command to the node.

· If an AI is interrupted in the middle of working, he may optionally play an interrupt animation. For example, an AI that is smoking may abruptly throw down his cigarette instead of calmly putting it out. When the Work Goal deactivates, it will play an interrupt animation if it exists in animationsCharacterName.txt, otherwise the AI will play its normal out transition if it exists.

· If an AI is hit with SpecialDamage while working, he may optionally play a specific SpecialDamage animation rather than transition out of Work normally. For example, and AI may slump over and pass out at his desk, instead of standing up, pushing in his chair and then passing out. This animation actually plays in the SpecialDamage Goal.

· AI may play a specific death animation corresponding to his work. For example, slumping over a desk, or falling out of a chair.

SpecialDamage

· The SpecialDamage Goal handles damage types that are specific to TRON 2.0, but may act as a template for similar functionality in other titles. It handles both instant and progressive damage, and includes the following damage types:

o Sleeping

o Stun

o Bleeding

o Burn

o Choke

o Poison

o Electrocute

· Incapacitating animations and transition animations are defined through SmartObjects. Note that this goal uses SmartObjects to drive animation without the presence of an AINodeUseObject.

· Instead of playing the normal in-transition animation, the Goal may play an animation specific to the AI’s current animation, as described previously in the Work Goal. This allows an AI to slump over on his desk when knocked-out. This also allows an AI to get knocked out while sleeping or prone without getting up first.

· AI may play a specific death animation corresponding to the damage. For example, dying instantly without moving while knocked out.


FXed Reference

FxED

Overview

This document details the new system for creating special effects for TRON 2.0. It covers how to use the FxED application to create a group of FX and details the properties of each individual FX. I will go over some common uses for each FX and which FX should be used to create a specific special effect. This paper is intended as a reference tool for anyone with a creative mind who would like to create some cool looking special effects but all are welcome to read and comment on its contents. As changes are made to FxED, the individual FX and the system as a whole this document will be updated to reflect any changes or additions.

Creating special effects for previous games meant having an engineer and an artist sit down together to create and FX in code and then expose a few properties for tweaking in a text file. This severely limited the types of special effects we could have and limited the behavior of the FX we did have. For TRON 2.0 we decided to use the FxED application to create and edit all of our special effects. With FxED you can specify the length of a whole group of FX, the length of an individual FX, the scale, color and alpha at any point in time for an individual FX and you can even create a motion path for each individual FX to follow without setting up lots of key framers in DEdit.

General

You will see the word FX and GroupFX used in this document. FX refers to the individual objects that are considered special effects. A FX can be a ParticleSystemFX, SpriteFX, or even a NullFX. A GroupFX are a collection of FX. A GroupFX may contain one or many FX. When working with FxED you are creating GroupFX by adding FX to them.

Each FX has a set of properties that you can edit. Some of these properties are common between all the FX but most are specific to the individual FX. I will explain how to use each property of each FX later on.

Getting Started

FxED is the application used to create the GroupFX that will be used in the game. When FxED runs for the first time on your computer you will have to fill out a dialog box of information telling FxED where to look for resources and the file containing the FX. If you wish to run the game from within FxED you will need to edit the “App to execute…” to be the full path name of your Lithtech.exe file. You can also enter in optional information into the command line if you wish to run the game in a window or load a specific level. You must fill out the “Location of resource file…” box. This tells FxED where to look for the resources such as .ltb’s and .spr’s, this should be the full path of your Game directory. The “Location and name of clientfx.fxd…” box also needs to be filled out in order to get the list of FX you can use. This should be the full path form the “Location of resource file…” box with “\clientfx.fxd” added to the end. FxED is now ready for you to work with and will never ask you for this information again. If you made a mistake in entering in the info or would like to change some options for the command line you can do so by selecting “Edit Game Info” form the File menu.

You will now want to open the file that contains all the GroupFX for the game. Click on the open icon and open the clientfx.fxf file found on the ClientFX directory of your Game directory. You will now have a list of GroupFX that you can open and edit.

Creating A GroupFX

To create a new GroupFX simply click on the “new” icon and a blank GroupFX will appear. By default all GroupFX start off with a Phase Length of 10000. Phase Length is the lifetime of the GroupFX in milliseconds so each GroupFX is 10 seconds long by default. To change this, just click on the button that says 10000 and enter in a new time. To start adding FX to this GroupFX you will first need to add a Track. Tracks are holders for Keys. Keys are the specific individual FX. Each Key needs to be placed on a Track, you can have multiple Keys per Track or you can have each Track contain only one Key. Once you have added a Track by right clicking in the gray area of the GroupFX and selecting Add Track you will need to add a Key. Right click on an empty space in a Track and select Add Key, a popup box will appear with a list of FX you can add for this Key. Select the type of FX you would like to add and it will then appear on your Track. You can now move this Key around your Track so you can set when you would like this FX to begin playing. You can also lengthen the FX by grabbing its edges and growing or shrinking the Key to the desired length. To have the FX play for the whole duration of the GroupFX right click on the Key and select Expand Key from the menu. If you have many FX that are of the same type you may want to differentiate them from each other by giving them each a unique name. To do this right click on the key and select “Name Key” from the popup menu and enter in a custom name for this Key.

Now that you have your Key set to the desired length and start time you can edit the properties of the FX by right clicking on the Key and selecting Edit Key. A popup dialog box appears with several different properties listed for you to edit. From the same right click menu you can select options to edit the scale of the FX, the color of the FX and create motion for the FX. Not all FX types expose the ability to edit all of these options. A list of FX and properties that you can edit are listed below.

Color Keys

For FX that allow you to create and edit color keys you access this interface by right clicking on a Key in the GroupFX and select “Edit Color Keys” from the menu. This will bring up a dialog box with a large colored bar numbered from 0 to the lifetime of the Key. The full time of the FX is represented in the bar along the bottom the, the alpha of the FX at a particular time is represented on the left side. From here you can create new color keys or edit the two preexisting keys. There are always at least two color keys per FX, one for the very beginning of the FX and one for the end of the FX. By default these two keys are set to the color white and are fully opaque. To create a new key, simply click in the color bar at the time you wish the new key to be and at the alpha you want the new key to be. You are then prompted to choose a color for the key. After a key is created you can move it around to the time and alpha desired by left clicking the key dragging it to the desired values. You can change the color of a color key by right clicking on one and choosing a color from the color menu. To delete a key simply select it by left clicking and then click the Delete Key button. You cannot delete the two preexisting beginning and end keys. If you create a set of color keys that you wish to use for other FX you can save them by clicking on the “Add To Favorites” button, you can select from a list of favorite color keys by selecting the choose button.

Scale Keys

For FX that allow you to create and edit scale keys you access this interface by right clicking on a Key in the GroupFX and select “Edit Scale Keys” from the menu. This will bring up a dialog box with a large white bar numbered from 0 to the lifetime of the FX. The full lifetime of the FX is represented in the bar at the bottom and the Scale of the FX at a particular time is represented on the left side, ranging from Min Scale to Max Scale. From here you can create new scale keys or edit the two preexisting keys. There are always at least two scale keys per FX, one for the very beginning of the FX and one for the end of the FX. By default these two keys are set to a scale of 1. To change the Min and Max scale for this FX click on the numbered buttons for Min Scale and Max Scale and then enter a new value. To create new scale keys, click in the white bar at the time and scale you desire, you may move the key to the desired time and scale after creating by clicking and dragging the key. To delete a key, right click on it and then select “delete key” from the menu. You cannot delete the two preexisting beginning and end keys. If you wish to start over again click the “Reset” button. This will delete all but the two beginning and end keys and set them to be at 10% of the Max Scale value. If you create a set of scale keys that you wish to use for other FX you can save them by clicking on the “Add To Favorites” button, you can select from a list of favorite scale keys by selecting the choose button.

FX

ParticleSystem

Features

This is probably the most used FX in the list. The particle system emits individual particles based on the properties that you fill out. This FX allows you to edit it’s Color Keys, Scale Keys and Motion Keys. The particles are always facing the camera and will never rotate. You can specify the particles to use a texture or a sprite. The Color Keys and Scale Keys for this FX are per particle, not per system. This means the particle will interpolate between its scale and color keys based on its own lifetime.

Use

The ParticleSystems can be used almost anywhere for anything. They can be used as smoke from a steam pipe, fire, sparks and smoke form a gun and many other possibilities. You can set them up to be an impact FX and emit a puff of smoke when a bullet hits a wall, or as bubbles in the water.

Color Keys

This FX allows you to edit its color keys. The Color Keys for a Particle System are per particle. So every particle will use the color keys based on their own lifespan.

Scale Keys

This FX allows you to edit its Scale Keys. The Scale Keys for a Particle System are per particle. So every particle will use the scale keys based on their own lifespan.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

Sprite

The ParticleSystem can use an .spr file as its particles and each particle will loop through the textures in the sprite. To select a ,spr file click the button and browse through the Resource Browser and select the desired file.

Texture

If no Sprite is given, the ParticleSystem can use a single .dtx as its file for the particles to display. To select a .dtx file click the button and select the file through the Resource Browser.

EmissionInterval

This controls the length of time, in seconds, between emissions of the system. Typically this is set low so the system is constantly emitting particles, however if you want particle to be emitted in bursts raise the value.

ParticlesPerEmission

Every time the system emits particles, based on the “EmissionInterval”, it will emit this many particles.

GravityAcceleration

This controls the speed and direction the particles will float or sink. A negative value will make the particles sink to the ground and a positive value will float the particles up towards the sky. Gravity is always in relation to the world, no matter what the systems rotation is.

MinParticleLifeSpan

Each particle will last for at least this amount of time, in seconds.

MaxParticleLifeSpan

Each particle will last no longer than this amount of time, in seconds. The life span of each particle is a random number between the Min/MaxParticleLifeSpan. If you want every particle to last the same amount of time, making these exactly the same.

MinRadius

This is the minimum distance from the center of the system that the particles will be emitted.

MaxRadius

This is the maximum distance from the center of the system that the particles will be emitted.

EmissionPlane

This is the normal vector of the plane that the particles are emitted from. By default this is a plane parallel to the systems Up vector. If you are using a ParticleSystem as an impact FX this should be set to 0.0 0.0 1.0.

MinParticleVelocity

This controls the minimum speed and direction that each particle will have when they are emitted. The velocity is relative to the system so if you never want particles to be emitted in the downward direction of the system, make the Y component positive. For impact FX the Z component should be positive so particles never get emitted into the surface they hit.

MaxParticleVelocity

This controls the maximum speed and direction that each particle will have when they are emitted.

Type

A dropdown list box of predefined emission types for the system:

  • Sphere – The particles will emit in all directions around the center of the system a distance no less than MinRadius from the center and no more than MaxRadius from the center.
  • Point - The particles will emit from the same random point on the emission plane at a distance of no less than MinRadius from the center and no more than MaxRadius from the center. If you wish to have the particles emit from the direct center of the system make Min/MaxRadius 0.0
  • Circle - The particles will emit in a circle on the emission plane at a distance of no less than MinRadius from the center and no more than MaxRadius From the center. Playing with Min/MaxRadius can yield an emission pattern of a circle, doughnut, or ring.

Bounce

If set to Yes, each particle will collide with and bounce off geometry and solid objects in a realistic manner. NOTE: This can dramatically decrease frames and slow the game. This should be used sparingly and only with systems that have few active particles.

FlipRenderingOrder

By default the newest particle particles are drawn first, over the older particles in the system. You can change the order so older particles are drawn over newer ones by setting this to yes.

BlendMode

Depending on the texture or sprite used you may wish to set the system to use Additive or Multiply blending.

MoveParticlesWithSystem

If a particle system is moving or rotating, the particles will move and rotate with the system. You can override this behavior by setting this property to No. For speed reasons, if a system is staying still (ie. Not moving or rotating ), keep this value set to Yes.

Sprite

Features

The Sprite FX displays a sprite specified through a .spr file. The sprite can rotate, be flat against a wall, or always face the camera.

Use

There are many uses for a sprite, one of the most common is to put a rotation on it and use it as a smoke or gas cloud. You can also use it as a smoke puff coming from the barrel of a gun.

Color Keys

This FX allows you to edit its color keys. The Sprite’s color and alpha will change over time by interpolating between the color keys.

Scale Keys

This FX allows you to edit its Scale Keys. The Sprite’s scale will change over time by interpolating between the scale keys.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

Sprite

This is the sprite, .spr, file used for the Sprite FX. To select a ,spr file click the button and browse through the Resource Browser and select the desired file.

Normal

This is the normal the sprite will be facing when set to face along the normal. By default this is set to be the forward vector of the sprite.

Facing

A dropdown list of presets that tell how the sprite will be oriented.

  • CameraFacing – The sprite will always be oriented so its forward is facing the camera.
  • AlongNormal – The sprite will face in the direction specified by the Normal Property.
  • ParentAlign – If the FX has a parent then the sprite will have the same rotation as the parent object.

BlendMode

Depending on the sprite used you may wish to set it to use Additive or Multiply blending.

DisableZ

When this is set to Yes the sprite will look as though it is being drawn over everything else.

DisableLight

This controls whether or not dynamic lights affect the color of the sprite.

Null

Features

This FX is used solely to give some random motion to other FX within a GroupFX. Nothing gets drawn for this FX; its only purpose is to keep track of a position for other FX to use. Other FX, a single FX or multiple FX, should motion link to this FX to give them a position to follow.

Use

Other FX should motion link to this FX. It should not be used as a stand alone FX. You can motion link any FX to this Null FX to give them a random motion. PolyTrails should motion link to this FX to create sparks and trails. You can link multiple FX within a GroupFX to this FX so it gives them a since of motion together.

Color Keys

This FX does not allow you to edit its color keys.

Scale Keys

This FX does not allow you to edit its Scale Keys.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

GravityAcceleration

This controls the speed and direction the FX will float or sink. A negative value will make the FX sink to the ground and a positive value will float the FX up towards the sky. Gravity is always in relation to the world, no matter what the FX rotation is.

MinVelocity

This controls the minimum speed and direction the FX will have in relation to its self and not the world.

MaxVelocity

This controls the maximum speed and direction the FX will have. The velocity is determined by getting a random value between the MinVelocity and MaxVelocity so each time the FX is played the motion will be different.

Bounce

If set to Yes, the FX will collide and bounce off geometry and solid objects in a realistic manner.

LTBModel

Features

This FX allows you to display a model that can fade in and out, scale, rotate and change the default animation length.

Use

The LTBModel can be used as a chunk of something flying through the air, a dead body or you can set it up so many LTBModels are used as a gib FX.

Color Keys

This FX allows you to edit its color keys. The Model’s color and alpha will change over time by interpolating between the color keys. Alpha will only work on models with an additive RenderStyle associated with it.

Scale Keys

This FX allows you to edit its Scale Keys. The Model’s scale will change over time by interpolating between the scale keys.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

Model

This is the model, .ltb, file used for the LTBModel FX. To select an .ltb file click the button and browse through the Resource Browser and select the desired file.

Skin 0-4

The skin properties are used to texture the model. Each skin should correspond to the texture index of the models textures set in model edit. To select a skin, click the button and select the .dtx or .spr you wish to use.

Normal

This is the normal the model will be facing when set to face along the normal. By default this is set to be the forward vector of the model.

Facing

A dropdown list of presets that tell how the sprite will be oriented.

  • CameraFacing – The model will always be oriented so its forward is facing the camera.
  • AlongNormal – The model will face in the direction specified by the Normal Property.
  • ParentAlign – If the FX has a parent then the model will have the same rotation as the parent object.

OverrideAniLength

You can manually set the length of the animation or let the length of the FX determine the length by setting this to Yes.

AniLength

If OverrideAniLength is set to Yes and this is non-zero then this length, in seconds, will be used to set the length of the animation. If this is 0.0 and OverrideAniLength is set to Yes, then the lifespan of the FX is used to set the length of the animation.

RenderStyle 0-3

The renderstyle properties are used to set renderstyles on the model. Each renderstyle should correspond to the renderstyle index of the model set in model edit.

DynaLight

Features

This FX creates a Dynamic light with the color and scale specified. The color, scale and Intensity of the light can change over time.

Use

The DynaLight FX can be used to show something is bright and emitting light. A good example of this is for a MuzzleFlash or for a fire or explosion.

Color Keys

This FX allows you to edit its color keys. Intensity of the light is controlled through the color keys by setting the Alpha. Fully Opaque is fully bright and Fully Translucent is No light. The Light’s color and intensity will change over time by interpolating between the color keys.

Scale Keys

This FX allows you to edit its Scale Keys. The Light’s scale will change over time by interpolating between the scale keys. The scale is in DEdit units so for this FX the scale should be at least 100 to even show up. Because changing the scale of a dynamic light forces the engine to recalculate the lightmaps, it is better to fade a DynaLight in and out using the intensity scale. It looks better, too.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

Flicker

This will give the light a slight flicker feel to it by slightly changing the color and intensity.

PlaySound

Features

This FX allows you to play a sound at anytime during the GroupFX. You can control the radius, volume and whether or not the sound loops.

Use

Any time you want a specific sound to play like a fire crackling, or a steam vent you can use this to play a sound.

Color Keys

This FX doesn’t allow you to edit its color keys.

Scale Keys

This FX doesn’t allow you to edit its scale keys.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

Sound

This is the file, .wav, used as the sound to play. To select a sound, click the button and select the .wav you wish to use.

Loop

If this is set to Yes, then the sound will loop for the duration of the GroupFX.

PlayLocal

If set to Yes, the sound will fell as though its playing in the players head.

InnerRadius

If the player is within this distance from the center of the FX they will hear the sound at full volume.

OuterRadius

If the player is between the OuterRadius and the InnerRadius they will hear an interpolated volume for the sound. If outside this distance the player will not hear the sound.

Volume

This is the full volume of the sound heard within the InnerRadius.

Priority

How important is this sound. If there are too many sounds playing at once the lowest priority sounds are not played.

PitchShift

This is a multiplier to the playback frequency of the sound, which will shift its pitch. If you had a sound recorded at 22,000 Hz and set its pitch shift to 1.1f, then the output sound would be 24,2000 Hz and make the sound have a higher pitch.

CamJitter

Features

This FX will shake the camera around as thought the player is in an earthquake.

Use

This FX is good for simulating a shaky ground. When an explosion occurs it is a nice effect to shake the camera.

Color Keys

This FX does not allow you to edit its color keys.

Scale Keys

This FX allows you to edit its Scale Keys. The Scale Keys for a CamJitter FX controls how intense the shaking is. This allows you to fade the shaking off rather than just abruptly stopping it.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

InnerRadius

If the player is within this distance from the center of the FX they will feel the shaking at full force.

OuterRadius

If the player is between the OuterRadius and the InnerRadius they will feel an interpolated shake. If outside this distance the player will not feel the shake.

WonkyFX

Features

This FX plays with the FOV of the camera to create a wavy, watery effect. The cameras X, and Y FOV increases and decreases.

Use

The WonkyFX probably wouldn’t be used very much and might only be useful for underwater type effects, or hallucination, type effects.

Color Keys

This FX does not allow you to edit its Color keys.

Scale Keys

This FX does not allow you to edit its Scale keys.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

xMultiplier

This controls the amount of fluctuation in the xFOV. Increasing this value increases how far the xFOV stretches.

yMultiplier

This controls the amount of fluctuation in the yFOV. Increasing this value increases how far the yFOV stretches.

InnerRadius

If the player is within this distance from the center of the FX they will feel the wobble effect at full force.

OuterRadius

If the player is between the OuterRadius and the InnerRadius they will feel an interpolated wobble. If outside this distance the player will not feel the wobble.

PolyTrail

Features

This FX will draw a series of polygons following a path to create a motion trail behind the position the FX is following. This FX should be motion linked to another FX to give it more of a moving feel or attached to a node or socket of a model to give it a moving feel.

Use

Motion link a PolyTrail FX to a NullFX and you can create sparks from a bullet hitting metal, or electrical sparks from the end of a downed power line. Attach this FX to a grenade or rocket to produce a motion trail or even a smoke trail behind it. Attach this FX to a socket on a model, like a sword, to show the path of motion.

Color Keys

This FX allows you to edit its color keys. The Color Keys for a PolyTrail are per trail section and not the trail as a whole. So the section closest to the head will be the color of the first key and the tail section will be the color of the last key.

Scale Keys

This FX does not allow you to edit its Scale keys.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

Texture

The PolyTrail can use a .dtx as its file for the trail to display. To select a .dtx file click the button and select the file through the Resource Browser.

TrailWidth

This is the width of the trail. Make this small for effects like sparks.

WidthStyle

A dropdown list how the trail is drawn:

  • Constant – The trail is always at the constant width set by TrailWidth.
  • SmallToBig – The trail starts small and ends big.
  • SmallToSmall – The trail starts small, is big in the middle, and is small at the end again.
  • BigToSmall – The trail starts big and ends small.

TrailLen

This is the Length of the trail given by number of segments. For a straight line trial this should be 1 but for a very curvy trail this should be much highr.

SectionLifespan

This represents the lifetime of each trail segment in seconds.

UAdd

An offset for the texture coordinates.

SectionInterval

The time spans between trail segments, in seconds. Every time this interval is hit a new trail segment is used.

BlendMode

A drop down list of various blend mode operations that can be performed to get the desired effect.

AlphaTest

A drop down list of various alpha tests to perform when determining weather or not to draw the trail.

ColorOp

A drop down list of various color operations such as Additive and Multiply to perform when determining how to draw the trail.

FillMode

A drop down list with two options for filling the trail. Fill just draws the trail normally and Wireframe draws lines to outline the polygons of the trail.

PlayRandomSound

Features

Just like the PlaySound FX except this FX will let you play a random sound from a selected set of sounds. You provide the base sound and then it randomly grabs sound with that base and a number appended at the end.

Use

If there are several sounds available for an effect and you don’t want to use just one for fear of being redundant this is what you should use. This FX is good to use if a single GroupFX is used and played quite often to give it a more random and non set feel.

Color Keys

This FX doesn’t allow you to edit its color keys.

Scale Keys

This FX doesn’t allow you to edit its scale keys.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

Sound

This is the file, .wav, used as the base sound to play. To select a sound, click the button and select the .wav you wish to use.

NumRand

This is how many sounds there are to use and the sound will be played by getting a random number between 0 and NumRand.

Loop

If this is set to Yes, then the sound will loop for the duration of the GroupFX.

PlayLocal

If set to Yes, the sound will fell as though its playing in the players head.

InnerRadius

If the player is within this distance from the center of the FX they will hear the sound at full volume.

OuterRadius

If the player is between the OuterRadius and the InnerRadius they will hear an interpolated volume for the sound. If outside this distance the player will not hear the sound.

Volume

This is the full volume of the sound heard within the InnerRadius.

Priority

How important is this sound. If there are too many sounds playing at once the lowest priority sounds are not played.

PitchShift

This is a multiplier to the playback frequency of the sound, which will shift its pitch. If you had a sound recorded at 22,000 Hz and set its pitch shift to 1.1f, then the output sound would be 24,2000 Hz and make the sound have a higher pitch.

SpriteSystem

Features

This FX is almost identical to the ParticleSystem FX except that the Sprites can rotate about there own axis. The Sprite system emits individual sprites based on the properties that you fill out. This FX allows you to edit it’s Color Keys, Scale Keys and Motion Keys. The Color Keys and Scale Keys for this FX are per sprite, not per system. This means the sprite will interpolate between its scale and color keys based on its own lifetime.

Use

The SpriteSystem can be used almost anywhere that a Particle system can be used for and more. The major difference of the Sprite system is that the individual sprites can rotate which can create a since of movement in smoke and gas clouds. Typically ParticleSystems look and better and give better performance but for things like gas clouds and smoke puffs, adding a rotation makes all the difference in the world.

Color Keys

This FX allows you to edit its color keys. The Color Keys for a Sprite System are per sprite. So every sprite will use the color keys based on their own lifespan.

Scale Keys

This FX allows you to edit its Scale Keys. The Scale Keys for a Sprite System are per Sprite. So every sprite will use the scale keys based on their own lifespan.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

Sprite

The SpriteSystem can use a .spr file as its sprite and each sprite will loop through the textures in the sprite. To select a ,spr file click the button and browse through the Resource Browser and select the desired file.

EmissionInterval

This controls the length of time, in seconds, between emissions of the system. Typically this is set low so the system is constantly emitting sprites; however if you want sprites to be emitted in bursts, raise the value.

ParticlesPerEmission

Every time the system emits sprites, based on the “EmissionInterval”, it will emit this many sprites.

MinSpriteRotation

The minimum rotations a sprite will rotate around each axis.

MaxSpriteRotation

The maximum rotation a sprite will rotate around each axis. The sprites will get its rotation by randomizing between Min/MaxSpriteRotation.

GravityAcceleration

This controls the speed and direction the sprites will float or sink. A negative value will make the sprites sink to the ground and a positive value will float the sprites up towards the sky. Gravity is always in relation to the world, no matter what the systems rotation is.

MinSpriteLifeSpan

Each sprite will last for at least this amount of time, in seconds.

MaxSpriteLifeSpan

Each sprite will last no longer than this amount of time, in seconds. The life span of each sprite is a random number between the Min/MaxSpriteLifeSpan. If you want every Sprite to last the same amount of time, make these exactly the same.

MinRadius

This is the minimum distance from the center of the system that the sprites will be emitted.

MaxRadius

This is the maximum distance from the center of the system that the sprites will be emitted.

EmissionPlane

This is the normal vector of the plane that the sprites are emitted from. By default this is a plane parallel to the systems Up vector. If you are using a SpriteSystem as an impact FX this should be set to 0.0 0.0 1.0.

MinSpriteVelocity

This controls the minimum speed and direction that each sprite will have when they are emitted. The velocity is relative to the system so if you never want sprites to be emitted in the downward direction of the system, make the Y component positive. For impact FX the Z component should be positive so sprites never get emitted into the surface they hit.

MaxParticleVelocity

This controls the maximum speed and direction that each sprite will have when they are emitted.

EmissionType

A dropdown list box of predefined emission types for the system:

Sphere – The sprites will emit in all directions around the center of the system a distance no less than MinRadius from the center and no more than MaxRadius from the center.

Point - The sprites will emit from the same random point on the emission plane at a distance of no less than MinRadius from the center and no more than MaxRadius from the center. If you wish to have the sprites emit from the direct center of the system make Min/MaxRadius 0.0

Circle - The sprites will emit in a circle on the emission plane at a distance of no less than MinRadius from the center and no more than MaxRadius From the center. Playing with Min/MaxRadius can yield an emission pattern of a circle, doughnut, or ring.

AType

A dropdown list for determining the additive type to use for the sprites. Norm uses no additive blending and Add uses additive to render the sprites

StretchU

An offset to use to stretch the textures of the sprite.

StretchV

An offset to use to stretch the textures of the sprite.

CreateFX

Features

This a unique FX in that it doesn’t render anything or really do anything but start another premade GroupFX. You can specify the name of a GroupFX and whether or not the new FX will loop so you can combine different GroupFX together quickly and easily. You have the option to use a blinding flare by editing the Blind properties. A blinding flare will disable the Z and be drawn over everything else if there is a clear path to the camera.

Use

Whenever you want to start a preexisting GroupFX at a certain time within another GroupFX you can use this FX to set it up. The new GroupFX will begin playing at the time specified by this FX’s Key and will the run independently of the GroupFX that contains it. This could mainly be used if you have an explosion that you want to play and then a looping cloud of smoke in the middle of the explosion to keep playing after the explosion finishes.

h3>Color Keys

This FX does not allow you to edit its Color keys.

Scale Keys

This FX does not allow you to edit its Scale keys.

Properties

FXName

This is the name of the preexisting GroupFX that you wish to play.

Loop

If set to Yes, the newly created GroupFX will loop and continue to play after the GroupFX that contains it is finished.

FlareSprite

Features

The FlareSprite FX displays a sprite specified through a .spr file and will scale and fade the sprite based on angels of the camera and sprite. The sprite can rotate, be flat against a wall, or always face the camera.

Use

The most common use for a FlareSprite is as a “halo” of sorts for a light.

Color Keys

This FX allows you to edit its color keys. The Sprite’s color and alpha will change over time by interpolating between the color keys.

Scale Keys

This FX doesn’t allow you to edit its Scale Keys.

Properties

UpdatePos

This property is a drop down list of predefined ways to update the FX position

  • Fixed – This is the most common option and will keep the FX at a fixed position.
  • Follow – If the FX is motion linked to another FX UpdatePos must be set to follow
  • PlayerView – If you are using this FX as a MuzzleFlash, select PlayerView.
  • NodeAttach – If this is selected the FX will attach to the specified node.
  • SocketAttach - If this is selected the FX will attach to the specified socket.
  • PV_NodeAttach – This will attach the FX to a node in a PlayerView model.
  • PV_SocketAttach – This will attach the FX to a socket on a PlayerView model.

UpdateInterval

This is the length, in seconds, between updates for this FX. This is normally set very low so the FX can update every frame. If constant updating is not needed then the UpdateInterval should be set higher.

AttachName

If any of the “Attach” options were selected for UpdatePos this property must be filled out so the FX knows which socket or node to attach to.

Offset

If the value of this vector property is anything besides zero the FX will be placed at this position offset from its center.

RotateAdd

If the value of this property is anything besides zero the FX will rotate this amount around the axis every update.

Sprite

This is the sprite, .spr, file used for the Sprite FX. To select a ,spr file click the button and browse through the Resource Browser and select the desired file.

Normal

This is the normal the sprite will be facing when set to face along the normal. By default this is set to be the forward vector of the sprite.

Facing

A dropdown list of presets that tell how the sprite will be oriented.

  • CameraFacing – The sprite will always be oriented so its forward is facing the camera.
  • AlongNormal – The sprite will face in the direction specified by the Normal Property.
  • ParentAlign – If the FX has a parent then the sprite will have the same rotation as the parent object.

BlendMode

Depending on the sprite used you may wish to set it to use Additive or Multiply blending.

DisableZ

When this is set to Yes the sprite will look as though it is being drawn over everything else.

DisableLight

This controls whether or not dynamic lights affect the color of the sprite.

MinAngle

This is the minimum angle that the FX will use to calculate the scale, color and alpha of the Sprite. If the angle is less than this the sprite will interpolate its color, scale and alpha from 0, being the max, and MinAngle being the minimum. If the angle is greater than MinAngle, the FlareSprite is invisible.

ObjectAngle

This is a dropdown list to choose which objet to use to calculate the angle. If Sprite is chosen the MinAngle is compared against the angle from the sprites forward to the camera. If Camera is chosen then the angle used is from the forward direction of the camera to the center of the sprite.

MinAlpha

When the angle is between 0 and the MinAngle the alpha will go no lower than MinAlpha.

MaxAlpha

When the angle is between 0 and MinAngle the alpha will go no larger than MaxAlpha.

MinScale

When the angle is between 0 and the MinAngle the scale will go no lower than MinScale.

MaxScale

When the angle is between 0 and MinAngle the scale will go no larger than MaxScale.

BlindObjectAngle

You can choose which object to use for the angle, sprite or camera, to calculate the scale.

BlindSpriteAngle

This is the angle from the Sprite to the camera that is compared against for creating the blinding flare. If the angle is greater the BlindSpriteAngle then the blinding flare is not created.

BlindCameraAngle

This is the angle from the Camera to the Sprite that is compared against for creating the blinding flare. If the angle is greater the BlindCameraAngle then the blinding flare is not created.

BlindMaxScale

If the angle from the Sprite’s forward to the Camera is less than BlindSpriteAngle and if the angle from the Camera’s forward to the Sprite is less than BlindCameraAngle then the angle, specified by BlindObjectAngle, is used to calculate the scale of the sprite form MaxScale to BlindMaxScale.


Texture Scripts For Artists

What is a Texture Script?

A texture script is a small program that can be written by engineers in order to create a specific type of effect on textures. In the old system there were effect such as pan and warble. The scripts act in a very similar manner, but instead of using the pan effect, you would use a script, which tells the engine how to pan the texture. Each texture script has a list of parameters that it allows artists to set in order to customize behavior for a desired effect, which is again very similar to the old pan effect where a velocity would specified to control how fast it should actually pan. Texture scripts are essentially different types of effects that the engine can use to dynamically update textures and can be controlled through a set of parameters.

What is a Texture Effect Group?

The engine itself does not use the scripts directly. Instead scripts are contained within an object called a Texture Effect Group. The texture effect group dictates what scripts will be used, what parameters will be provided to them, and to which texture the script applies. Each effect group has a unique name as well as a series of stages. Each stage represents a script and to what it applies. To clarify here is an example: when rendering a polygon with a detail texture, there are two textures involved, the base texture and the detail texture. Each one of these textures can have a script with its own parameters applied, so the base texture could for example pan, while the detail texture warbled. The settings of the texture type, script, and parameters are called a stage. This will be clarified further in the section Creating and Editing Texture Groups. In addition, if you want one stage to act exactly like a different stage, so that it has the exact same script and parameters, you can specify that the stage is overridden, and specify which stage it should copy all the information from. When a stage is overridden, it does not have any parameters of its own, so changes to the parameters must be done to the overriding stage.

Assigning Texture Groups in DEdit

Texture groups can be assigned to brushes in DEdit through the TextureEffect property. Pressing the browse button on the property causes the Texture Group dialog to appear as shown below:

From the dropdown you can select any existing effect groups, and through the buttons new effect groups can be created or existing ones edited. Pressing OK will assign the currently selected effect group to all selected brushes.

Creating and Editing Texture Groups

When a new effect group is created, or an existing one edited, it brings up the Edit Effect Group dialog shown below:

As can be seen, the effect group has a name, which can be edited when creating a new effect. In addition it has two stages for setting up how the effect will actually work. First stage one will be examined, which in the diagram is set up to have a warble effect played on the base texture. The channel field indicates which texture will have the script applied to it, in this case it is the Base Texture, but it can also be the Detail Texture, Environment Map, Light Map, or can also be set to Disabled if this entire stage should be ignored and nothing effected. The next drop down specifies what stage overrides this one, and in this case there is nothing overriding it, indicating that it provides its own script and parameters for controlling the effect. The script is the actual effect itself, which in the example shows a warble script selected, which will cause the texture to move around in an odd fashion based upon the parameters provided. The script name cannot be edited directly, but by pressing the button to the right it allows the user to select a script through a file dialog. Once a script is selected, it will be looked at to determine what parameters it supports. Upon finding those it will display them below the script allowing the user to enter custom values in order to customize the script for the particular instance. These parameters are dependant upon the script itself.

Stage two shown below stage one is an example of modifying a different texture channel so that both can be animating. However, for this one it has been overridden to copy stage one. This means that it will use the exact same script and parameters as the first script, and if any of those parameters were to change, it would change for stage two as well. Essentially overriding allows one stage to piggyback on a different stage but apply it to a different texture channel. If this stage was not overridden though, it could provide its own effect and parameters allowing the detail texture to animate independently of its base texture.

Adding Support for Triggers

Texture scripts can have their parameters changed during runtime through triggers, allowing such effects as a player walking through a doorway and causing conveyer belt textures to begin panning or other such dynamic effects. In order to do this, a TextureFX object must be placed in the level. The TextureFX has a single property, which should be filled out with the name of the group that it is corresponding to. This object can then receive messages of the form:

SETVAR (<stage> <variable> <value>)

This will change the effect group’s parameter to the specified value. Stage represents the stage that is having the parameter change and can be either 1 or 2. Note that it cannot be a stage that is disabled or a stage that is overridden. Variable represents the index of the variable that is to be changed and corresponds to the order in which they are listed in DEdit going from left to right, top to bottom and must be from one to six. The value is the value that is to be stored at the specified location. So for example, if we had a panning script whose parameters were: DirX, DirY, DirZ, Velocity, Offset, and that was part of the effect group ConveyorBelt.tfg, we would first need to create a TextureFX object named ConveyorBelt whose parameter TextureEffect was assigned to ConveyorBelt.tfg so that it would know to modify the conveyor belt effect group. We could then set up a trigger in a doorway that would start the conveyor belt up by changing its velocity from 0 to 5. The conveyor belt uses stage one, and since velocity is the fourth parameter, our message would look like this:

Msg ConveyorBelt SETVAR (1 4 5.0)

Complete Overview

Below is a diagram that illustrates the process of creating texture effects: