The Attributes files are plaintext files that the game reads from to manage multiple critical elements, including weapons, menus, and AI behaviors. This serves as the primary method to tweak or modify these game elements. These files appear to take the structure of .ini files, but must remain .txt files in order for the game to properly detect them.
This page will list all of the available files and what their purpose is in TRON 2.0 specifically. Definitions for the fields used in the files will also be provided - unused fields will not appear here, but will still be listed in their respective files. Larger files, such as Layout, will have pages of their own.

This page is still in development, and certain definitions may be missing or unrefined. Check back every so often for updates.

The ActivateTypes file manages attributes for all of the game's various Activation Types.
ActivateTypes are options for a property in DEdit that correspond to either linear or binary actions in TRON 2.0. The property is associated with objects that the player can directly interact with in the game, such as doors, switches, or binary bits.
Because some classes in DEdit have static, unchangeable references to an ActivateType, it is not recommended to modify or remove any of the existing entries, and instead add your own to the end of the list. All ActivateTypes must contain the three properties defined below, and will malfunction otherwise.

• Name (String)
  • The user-friendly name of the ActivateType. This is what will show up in DEdit.
• StateON (Integer),
• StateOFF (Integer)
  • The string ID from CRES.DLL of the text to display when the object is in its ON and OFF states. Use -1 for no text.

See the AIButes page for information about this file.

The AIGoals file acts as the general control file for AI objectives ingame. AIGoals themselves are responsible for determining goal sets for AI routines. Put simply, this is the file that tells the AI what to do, but not how to do it. When adding a new NPC to a world in DEdit, its GoalSet property will refer directly to this file.
This file has three sections: Goal Sets, Goals, and Smart Objects.

GoalSets determine what Goals an AI can have access to.
In general, AI in TRON 2.0 are assigned either the Patrol, Guard, or Reinforcement GoalSets, on top of their defaults. These GoalSets share identical combat behavior, but vary in their relaxed and investigative behaviors. See the AI page for more details in regard to guidelines for each specific GoalSet.

• Name (String)
  • The user-friendly name of the GoalSet. This is what will show up in DEdit.
• RequiredBrain# (String)
  • The name of a Brain that the AI must have in order to use this GoalSet.
  • See AIButes for a list of Brains.
• IncludeGoalSet# (String)
  • The name of an additional GoalSet to use alongside the current one.
  • This field will only work if the GoalSet being included has already been created earlier in the file. As such, it is highly recommended that any GoalSet with this field be created at the bottom of the list.
• Hidden (Boolean)
  • Determines whether the GoalSet will appear as a selectable option in DEdit. Default is FALSE.
    • TRUE: The GoalSet will be selectable in DEdit.
    • FALSE: The GoalSet will not be selectable in DEdit.
• Permanent (Boolean)
  • Determines whether any of the Goals inside the GoalSet can be removed from an AI at any point. Default is FALSE.
    • TRUE: None of the Goals in the GoalSet can be removed.
    • FALSE: Any of the Goals in the GoalSet can be removed.

Goals define all of the specific actions an AI routine can perform. These can be assigned individually at any time, but will not become a persistent AI behavior unless assigned alongside a GoalSet.

• Name (String)
  • The name of the Goal. This is later referenced underneath the "Goal" C++ class in the game's source code.
• GoalID (Integer)
  • The function of this field is unknown, and is always set to 0.
• Importance (Float)
  • Effectively the "priority" of a goal, when it is activated.
  • This functions as a traditional priority system. An AI's Goals each have an assigned Importance value, and when a GoalSet is assigned, all of the Goals inside it are activated at the same time. From there, the Goal with the highest Importance value will be the AI's determined behavior until that Goal is either deactivated, or superseded by a Goal with a higher Importance.
• DecayTime (Float)
  • The amount of time, in seconds, that it will take for the AI to lose interest in persuing this goal, provided it has not encountered any other events in this time and the goal was not completed.
• FreezeDecay (Boolean)
  • Determines whether other Goals can decay while this Goal is active. Default is FALSE.
    • TRUE: Other Goals' DecayTime will remain active while this Goal is being performed.
    • FALSE: Other Goals' DecayTime will be frozen while this Goal is being performed.
• UpdateRate (Float)
  • The amount of time, in seconds, that must pass before the Goal's value is updated.
• DeleteWhenDone (Boolean)
  • Determines whether the Goal is deleted after it has been completed. Default is FALSE.
    • TRUE: This Goal will be removed from the AI's list when completed.
    • FALSE: This Goal will remain on the AI's list, even after completion.
• LockedAnimIsInterruptable (Boolean)
  • Determines whether other Goals can activate to interrupt this Goal while a locked animation is playing. Default is TRUE.
    • TRUE: Other Goals can interrupt this Goal during locked animations.
    • FALSE: Other Goals cannot interrupt this Goal during locked animations.
• ForceAnimInterrupt (Boolean)
  • Determines whether this Goal can activate to interrupt other Goals while a locked animation is playing. Default is FALSE.
    • TRUE: This Goal can interrupt other Goals during locked animations.
    • FALSE: This Goal cannot interrupt other Goals during locked animations.
• MakeNeutralEnemy (Boolean)
  • Currently unknown function.
• DamagePriority (Integer)
  • The priority level of the Goal when handling damage.
  • When an NPC takes damage in any way, the normal Goal priority system is paused for a split second, and the AI will instead activate the highest priority Goal on this "damage taken" priority system before returning to normal.

SmartObjects are templates that announce an AI Node's purpose to an AI, and describe the animation set to play while the AI is at that node. As a general guideline, the AI should play either a single Action animation, or a looping Idle animation with optional Fidget animations playing intermittently.

• Name (String)
  • The user-friendly name of the SmartObject. This is what will show up in DEdit.
• Flag# (String)
  • The name(s) of the SmartObject's type. Note that not all types are used in TRON 2.0, subject to further testing.
    • Alarm: AI can sound an alarm here.
    • Attackable: AI can attack enemies here.
    • Bed: AI can sleep here.
    • Coverable: AI can take cover here.
    • DamageType: Used to play a specific animation when the AI takes a certain type of damage, like the Rod Primitive stun.
    • Disturbance: AI can investigate a disturbance here.
    • Examinable: AI can look at something on a wall here.
    • LightSwitch: AI can turn on/off a light here.
    • MenacePlace: AI can play a menace animation here. A menace is an animation used for AI that appear agitated despite being unaware of an actual threat.
    • PostingPlace: Unused in TRON 2.0.
    • Ride: Unused in TRON 2.0.
    • Smashable: AI can destroy something here.
    • Sniper: AI can shoot someone from here.
    • WorkItem: AI can do generic work here. This is the catch-all for animations that don't fall into the above categories.
• Cmd# (String)
  • The command(s) that is passed to an AI when it's using the SmartObject. All commands after the first are separated from their arguments by an equals sign, e.g. LoopTime=[0,0].
    • HumanUseObject: Generic command with no arguments. Every SmartObject with a command set needs to have this one used at the very beginning.
    • Action: An Action animation property from an Animations Attribute file.
    • Activity: An Awareness animation property from an Animations Attribute file.
    • Mood: A Mood animation property from an Animations Attribute file.
    • Pose: A Posture animation property from an Animations Attribute file.
    • WeaponAction: A WeaponAction animation property from an Animations Attribute file.
    • LoopTime: The minimum and maximum amount of time, in seconds, to delay between a looped animation. Time is chosen randomly. [0, 0] means loop immediately.
    • FidgetFreq: The minimum and maximum amount of time, in seconds, to delay between a fidget animation. Time is chosen randomly.
    • LockNode: A boolean that determines if the AI Node can be reusable after the SmartObject has been used.
      • TRUE: The AI Node can be reused.
      • FALSE: The AI Node cannot be reused.
• AddAnimsLTB# (Path String - <Skeleton ID #>;<Path>)
  • The additional animation(s) that needs to be loaded in order for the AI to interact with the SmartObject.
  • This Path string must be prefaced with the ID of the Skeleton that will be using the referenced animation, separated by a semicolon. Skeleton IDs are as follows:
    • 0: Male Programs
    • 1: All ICP Variants
    • 7: Z-Lots
    • 8: DataWraiths
    • 11: Female Programs

See the Animations page for information about the Animations files.

The Attachments file acts as the control file for all of the game's different NPC attachables.
Attachments are basically anything that needs to be placed, either on or around, a character model, that acts as its own object whilst moving with the model itself. Hats, glasses, armor, etc. all fall under this definition. Attachables can be selected for a character in DEdit.

• Name (String)
  • The user-friendly name of the attachable. This is what will show up in DEdit.
• Type (Boolean Integer)
  • Determines if the attachable either has logic (an "object") or doesn't have logic (a "prop").
    • 0: Prop - A static item with no logic (ex. a hat or a moustache)
    • 1: Object - An item with logic (ex. a searchlight)
• Properties (String)
  • A string containing the object properties that the game should override for the attachable.
  • As of now this is not well-researched and should be left alone
• Class (String)
  • The name of the attachable's class. Only applicable if Type is set to 1.
• Model (Path String)
  • The model to use for the attachable. Only one model can be set per attachable. Must be in .LTB format.
• Skin# (Path String)
  • The skin(s) to use for the attachable. Must be in .DTX format.
  • Multiple skins can be assigned, but it's not yet known how the game decides which to use or prioritize.
• RenderStyle# (Path String)
  • The render style(s) to use for the attachable. Must be in .LTB format.
  • Multiple render styles can be assigned, but it's not yet known how the game decides which to use or prioritize.
• DeleteOnDeath (Boolean Integer)
  • Determines whether the attachable should be deleted when a character dies.
  • In TRON 2.0, the "death" animation is the derez animation by default, with other animations specified for unique entities such as a Seeker. The game seems to have its own way of handling entity deletion when a character is derezzed, although this is not confirmed.
    • 0: The attachment will be deleted upon death.
    • 1: The attachment will carry over to the dead body.
• HiddenInDEditToAIWeaponList (Boolean)
  • Determines whether the attachable will appear on the list of AI weapons in DEdit.
    • TRUE: The attachment will not appear on the list.
    • FALSE: The attachment will appear on the list.
• Translucent (Boolean Integer)
  • Determines whether the attachable will appear translucent when rendered.
    • 0: The attachment will not be translucent.
    • 1: The attachment will be translucent.
• DetachWhenShot (Boolean Integer)
  • Determines whether the attachable will fall off of a character if it is hit by a weapon.
    • 0: The attachment will remain on the character when damaged.
    • 1: The attachment will come off of the character when damaged.

Given Monolith's original description of this file, it seems that it was, at one point, responsible for storing information for all of the ingame bosses in TRON 2.0 during development. Most of this data was later transferred to AIButes, meaning whatever was left in this file - which is just data for a Thorne bossfight - is either unused, or could not be moved in time before release.
It is not yet known whether the Thorne data here corresponds to the Thorne bossfight in the Progress Bar.

The ClientSND file (short for Client Sound) does one thing and one thing only: specify the path to the folder containing the game's voice lines in Single Player.
All voice lines in the game must have their name set only to their associated ID, as well as a .LIP file that translates the voice line into lip syncing animation instructions. When the game calls the ID of a string in CRES.DLL to use for subtitles, it will also call the voice line and .LIP file of the same ID in this directory.

• Dialogue (Path String)
  • The path to the folder containing the game's voice lines, with the Game folder acting as the root. Must end with a backslash to note the end of the path, but does not need one at the beginning of the path.

The Commands file is meant to store commands that run immediately when the player starts a campaign or a specific map. Primarily, this is used solely for variable declaration, because in order to use a variable in a command in DEdit, that variable needs to be declared in this file first. A level can have up to 255 variables max. The file is split into two sections: one for global commands, and one for level-specific commands.

Global commands are executed once when the player starts a new game and enters the first level of the first mission. Because of the inherent complexity of a global scope, the only commands accepted in this section are variable declarations. However, said variables will be accessible in any level, and their value will get saved across all levels.
Level commands are executed once every time the player enters a specific map. Unlike globals, any command is valid to use here; however, that command will not carry over to any other level. Additionally, level commands accept a "name" argument before its command list, though it is not specified what this does.

• Name (String)
  • The name of a level. This argument can only be declared with level-specific command sets.
  • It is not clear at this time what the game uses this for.
• Cmd# (String)
  • The command to be processed. Each command must be on its own line; however, it is safe to declare as many of these as needed.
  • See [TBD] for a reference list of valid commands.

The DamageTypes file manages attributes for all of the game's various Damage Types. A majority of these are unused from NOLF 2, with most of TRON 2.0's Damage Types being named after the weapon that deals them.

• JarCamera (Boolean Integer)
  • Determines whether the Damage Type causes the camera to be "jarred". Monolith doesn't define what this means, and neither does Google, so further testing is needed to know what this is.
    • 0: The camera will not be jarred.
    • 1: The camera will be jarred.
• Gadget (Boolean Integer)
  • Determines whether the Damage Type is a gadget.
  • Unused, strictly a NOLF thing. Testing needed to figure out if the game will crash without this field.
    • 0: The Damage Type is not a gadget.
    • 1: The Damage Type is a gadget.
• Accuracy (Boolean Integer)
  • Determines whether the Damage Type will "count towards player accuracy". Once again, testing is needed to understand what that actually means.
    • 0: The Damage Type will not count.
    • 1: The Damage Type will count.
• SlowMovement (Float)
  • The amount of time, in seconds, that this Damage Type will cause the player to temporarily walk slower. Monolith says it's unrelated to the ForceWalk value, whatever that is. Set to 0.0 for no slowdown time.

This file is unused, remaining as one of the many fragments of NOLF 2 development that never got removed before TRON 2.0 was released. Monolith has specifically designated this file as unused, and thus it is highly unlikely that its functionality can be restored.

This file is unused, remaining as one of the many fragments of NOLF 2 development that never got removed before TRON 2.0 was released. It is not known at this time whether this functionality can be restored for other potential uses.

This file is unused, remaining as one of the many fragments of NOLF 2 development that never got removed before TRON 2.0 was released. It is not known at this time whether this functionality can be restored for other potential uses.

See the Layout page for information about the Layout file.

The Music file is responsible for "importing" the music control files into the game itself, and allow it to set up its dynamic music system.

In TRON 2.0, the music system is not a simple linear track; rather, it is a system that uses track segments, which is exactly what the name implies: it accepts tracks, splits them into segments, and then uses an internal system to play all of the segments in a sequence that is set by a dedicated control file. Other attributes, such as the timings the game will use to properly overlap the segments, are stored in that specific segment's companion file, which uses the .SGT format.
The only way to properly add your own music into the game is to use Microsoft DirectMusic Producer, which is responsible for making the .SGT files that the control file can read from. A tutorial on how to do so may appear at a later date, but no guarantees.
This file has two sections: Settings and Tracks.

There are two elements of the dynamic music that are controllable: moods and events. These concepts are represented in the music's intensities and motifs respectively.

Moods are essentially the game's normal background music, and are the system responsible for allowing the music to respond to the current game state.
At any given time, only a single mood will be playing. Any number of events/motifs can play on top of this mood. There are four moods in total:

1. None - Silence. In TRON 2.0, this isn't supposed to occur naturally, however does still happen every so often. The "music" that plays in this mood is just set up to reference no sound files at all.
2. Routine - Ambient music. This should be the default state of music in TRON 2.0. If the mood is set to None, it can easily return to this state, or a higher one, whenever there is any AI activity near the player.
3. Investigative - Moderate intensity music. This plays when a hostile AI has become aware of the player's presence, but is not yet engaged in combat.
4. Aggressive - Combat music. This will pretty much always be playing when an AI is engaged in combat, regardless of whether it is with the player, or with other AI.

The game determines the current mood by constantly checking these four states top-down (from Aggressive to None) and seeing if each specific mood is being stimulated by an AI that is within the player's visibility. If it can't find any AI, then it will default to None as the mood. If multiple intensities are assigned to a single mood, the game will pick one at random when transitioning to it.
This logic is not set in stone, however. The MinMusicMood DEdit property can change the default minimum music mood. The two most notable examples of this are the Transport Station (Vaporware) and the Main Power Pipeline (Antiquated). A command can also easily force the music intensity to change to a different mood at any time.

Events, as stated before, are additional music cues that can play on top of the current mood when an AI either dodges, or dies from, an attack. Although TRON 2.0 does not actually use events, they can still be set up by adding motifs inside the music control files themselves. If multiple motifs are assigned to a single event, the game will pick one at random to play on a per-event basis.

This section defines specific settings pertaining to the music.

• DodgeChance (Float),
• DieChance (Float)
  • The percentage change that the game will play a motif when an AI dodges or dies from an attack respectively. Any values above 1 will be treated as 1, but it is recommended to keep the value between 0 and 1.
  • This is unused in TRON 2.0, but is still fully functional.

This section defines all of the specific music tracks the game can use. Because they are strictly based on their name, they do not need to be defined in a specific order; however, all of the section headers must be fully lowercase.

• None# (Integer),
• Routine# (Integer),
• Investigate# (Integer),
• Aggressive# (Integer)
  • The intensity to read from the control file for each of the four different moods.
• AIDie# (String),
• AIDodge# (String)
  • (Optional) The name of a motif to play when an event occurs while this track is currently playing. The name must directly correspond to the same name as defined in the track's control file.
  • This is unused in TRON 2.0, but is still fully functional.

Despite being a file consisting of literally nothing, NoMissions is still used for the sole purpose of aiming TRON 2.0's Mission manager away from the Single Player missions when loading Multiplayer maps. Monolith even went so far as to call this the "Empty Missions" file, and they'd be correct. It's empty.

The Pings file sets up all of the necessary elements to display the HUD element reminding the player of various progression-related events, such as a character calling them over an I/O Node, or an info mark telling the player they have received a new objective, subroutine, help file, or version number upgrade.
This file has two sections: Pings and Characters.

This is the section that defines individual pings and assigns them to characters. Generally speaking, the game will just reference the same ping whenever its invocation is needed. With the exception of Mercury, no two I/O Node callers overlap one another, and other ping types use a different, likely hard-coded set of rules.

• Name (String)
  • The name of the Ping. It's usually recommended to set this to be the same as the Character field.
• Character (String)
  • The Character name (defined in the Characters section) that the Ping will be assigned to.
• Trigger (String)
  • (Optional) The trigger command to send if the player chooses to respond to the Ping.
  • Note that in most cases this goes unused, and is highly discouraged.
• Cancel (String)
  • (Optional) The name of the Ping to remove when this Ping is activated. Only used in cases where one Ping replaces another.
  • Note that in most cases this goes unused, and is highly discouraged.

This is the section that defines all of the specific characters that can appear in a Ping. This serves as a general term to differentiate Pings; which means things like the "new objective" and "new help file" icons count as Characters despite being simple indicators.

• Name (String)
  • The name of the Character. This is what the Pings reference.
• NameID (Integer)
  • The ID of a string in CRES.DLL to use for the Character's name ingame.
• Portrait (Path String)
  • The texture used for the Character's portrait. This overrides a Ping's default portrait.
• IsCharacter (Boolean Integer)
  • Determines whether or not a ' has pinged you!' message will appear onscreen when a Ping with this Character is activated.
    • 0: The message will not appear when the Ping is activated.
    • 1: The message will appear when the Ping is activated.

The Ratings file defines some of the core parameters with regard to the five Performance Ratings. It also manages the Transfer Rate rating's transfer times specifically.
TRON 2.0 Performance Ratings are fairly straightforward. The player collects Build Points throughout the campaign, which contributes to increasing their major version number. Once the player has received a major version upgrade, they are given a number of Build Points to allocate to these five ratings. As a rating improves, so too does the respective stat being upgraded. Once a rating has received a maximum point investment, it will enter Surge status, in which the mechanic receives a significant boost as a reward for reaching that point. All point allocation is irreversible once the Subroutines menu is closed, but unallocated points are saved indefinitely for future allocation at any time.

• PointsPerLevel (Integer)
  • The amount of points that are awarded to the player whenever they reach a major version upgrade.
• InitialPoints (Integer)
  • The amount of points that are given to the player at the start of a campaign, or when loading into a custom map.
  • Because this is a global setting, it is highly discouraged to change this, and instead use the AddBuildPoints command in DEdit to provide the player an initial version number greater than 0.
• MinValue (Integer),
• MaxValue (Integer)
  • The minimum/maximum amount of points that can be allocated to each of the five Performance Ratings. This is a permanently shared setting that cannot be changed per rating.
• InitialValue (Integer)
  • The amount of points initially allocated to each of the five Performance Ratings at the start of a campaign, or when loading into a custom map.
  • Because this is a global setting, it is highly discouraged to change this, and instead use the AddBuildPoints command in DEdit to provide the player an initial version number greater than 0.
• <ItemTransfer> (Custom Vector)
  • The remaining fields all set transfer times (in seconds) for all of the game's item types, including transfers from Archive Bins and Core Dumps.
  • The field's accepted data value is in the syntax of a Vector. All values are times in seconds.
    • The first value defines the transfer time when the Transfer Rate rating is at the MinValue.
    • The second value is intended to define the transfer time when the Transfer Rate rating is at the MaxValue. However, this value is not ever truly reached, because a rating at MaxValue goes directly to Surge status, and therefore uses the third value instead.
    • The third value defines the transfer time when the Transfer Rate rating has reached Surge status.
  • The different types of transfers are described as follows:
    • AlphaSubTransfer, BetaSubTransfer, GoldSubTransfer: For Alpha, Beta, and Gold Subroutines respectively.
    • ProceduralTransfer: For the Disinfect, Defrag, and Port Procedurals. Fully functional, although no Procedurals are obtained in this way in the game.
    • PrimitiveTransfer: PrimitiveTransfer: For the "5" Primitive weapons. The "Hands" "weapon" counts under this category, but getting it in this way doesn't actually have any visible effects. The other four work as intended.
    • PsetTransfer: For the 8 in-game Permissions.
    • EmailTransfer: For Email files.
    • HelpFileTransfer: For Help Files. Fully functional, although no Help Files are obtained in this way in the game.
    • CustomTransfer: CustomTransfer: For an arbitrary "item", or an item that does not apply to any of the above categories, like a Video Archive. Transferring a Custom item simply executes a custom command, or does nothing if no command was given.

The RelationData file mainly serves to set up AI "factions", which should be applied to all AI in the game. This allows NPCs to know how to react when encountering both the player and each other. This process includes creating specific AI categories, which are then assigned a single set of relations. It's possible to dynamically modify these relations by assigning them to a Collective, though this is not used in TRON 2.0.
This file has four sections: RelationalObjects, Collectives, RelationSets, and RelationData.

RelationalObjects are responsible for the first step of the process, which is to create AI categories. Every NPC in TRON 2.0 that isn't part of a cutscene or doing a scripted action will be required to have an assignment to one of these categories in order to properly exhibit traditional behaviors. Without one, the AI has no way of receiving a Relation configuration, and will subsequently react to absolutely nothing.
The primary way to assign these to an AI will be by setting its Alignment attribute in AIButes to one of these RelationalObjects. That assigns a default relation data set to the AI, which can then be overridden as needed by setting the Alignment attribute in the AttributeOverrides menu in DEdit.
It's important to clarify the use of the word "Alignment" in this section, because literally every other part of the dev tools (that we can see) refers to these as Alignments and not RelationalObjects. Actual alignments are set in the RelationData section.

• Name (String)
  • The name of the RelationalObject. This is the key that all of the other tools will use to interface with this file.
• RelationSet (String)
  • The name of the RelationSet to assign to this RelationObject. Only one RelationSet can be assigned. Use an empty string ("") if no RelationSet is to be used.
• RelationData (String)
  • The name of the RelationData to assign to this RelationObject. Only one RelationData can be assigned. Use an empty string ("") if there is no RelationData to be used.
• Collective (String)
  • (Optional) The name of the Collective to assign to this RelationObject. Only one Collective can be assigned. Use an empty string ("") if there is no Collective to be used.
  • Although it appears as if Collectives were experimented with during development, they are effectively unused in the final Retail release, although potentially still functional.

Collectives are meant for 'Collective-minded' NPCs, who all think alike in some way. By nature, this means that they should be used ONLY in situations where they are obviously meant to exist. All Collectives are assigned to a RelationSet which it will dynamically change over time.
NPCs' RelationSets will subscribe to Collectives as sources of information. Information which is not in the Collective may still be different for these NPCs. Whenever information matching that listed in the Collective is uncovered, the Collective learns that information, and it remains until the Collective releases it.
Collectives are unused in TRON 2.0, as all NPCs in the game are intended to have static alignments. Use at your own risk.

• Name (String)
  • The name of the Collective.
• RelationSet (String)
  • The name of the RelationSet to assign to the Collective. This is where the Collective will store the information it learns.

RelationSets are where all the pieces actually come together. All of the values deciding whether an NPC likes, dislikes, or tolerates other NPCs (or the player) are controlled here.
If a RelationSet is assigned to a Collective, it should contain only a Name and RelationTimeout. From there, the Collective will store all Relations it accumulates into that RelationSet over time. It is not currently known how this data is saved.

• Name (String)
  • The name of the RelationSet.
• RelationTimeout (Float)
  • The amount of time, in seconds, that the RelationSet will remember a dynamic relation change following the last stimulus that triggered it.
• Relation# (String)
  • A string composed of three arguments that determine how the Alignments will react to each other. It is recommended to have a Relation for all active Alignments on every RelationSet in order to ensure expected behavior, though this is not required.
  • All strings are case-sensitive, and must be composed in this exact format: "Alignment [Relationship] [AlignmentName]"
    • For example: "Alignment HATE ResourceHog"
  • Valid Relationships: LIKE, TOLERATE, HATE, UNDETERMINED
  • Valid AlignmentNames: Security, Player, ByStander, Corruption, PlayerAlly, Seeker, FconMonster, ResourceHog, AbsoluteGood, AbsoluteBad, Neutral
    • Modify this list with any Alignments that are added or removed. Alignments are declared in the RelationData section of this file.

RelationData acts as a self-identification for a RelationalObject, which sets its Class and Alignment. It is not currently known what the relevance of the Class assignment is.

• Name (String)
  • The name of the RelationData.
• Data# (String)
  • A string composed of two arguments that allow the RelationData to set its own Class and Alignment. This field accepts a maximum of two entries.
  • All strings are case-sensitive, and must be composed in this exact format: "[TraitName] [ObjectID]"
    • For example: "Class Player"
  • Valid TraitNames: Class, Alignment
  • Valid ObjectIDs: Any string with no spaces.

This file is unused, remaining as one of the many fragments of NOLF 2 development that never got removed before TRON 2.0 was released. It is not known at this time whether this functionality can be restored for other potential uses.

The ServerButes file is responsible for managing attributes for server-based entities; however, almost none of it is used, as it is still mostly based on NOLF 2's multiplayer infrastructure.
Documentation of this file is currently on hold, awaiting further multiplayer testing.

This file is unused, remaining as one of the many fragments of NOLF 2 development that never got removed before TRON 2.0 was released. The intent of this file appeared to be managing necessary settings for hosting multiplayer games; however, TRON 2.0 opts to use a completely different method to modify said settings, rendering this file useless.

This file is unused, remaining as one of the many fragments of NOLF 2 development that never got removed before TRON 2.0 was released. It was replaced by the Performance Rating system, which means its functionality cannot be restored. See the Ratings file for more information.

The TriggerTypes file manages attributes for all of the game's various Trigger Types.
TriggerTypes are responsible for associating specific map triggers - ones that the player should be made aware of - with icon textures that will appear on the HUD to inform the player that they are nearby one of these triggers.
This file allows for the selection of TriggerTypes in DEdit, but only appears in the basic Trigger class. The game will then use this file to associate the TriggerType with the icon texture that it's supposed to display, and show it when the trigger's HUDLookAtDist and/or HUDAlwaysOnDist parameters have been satisfied. There are only two TriggerTypes defined here, and TRON 2.0 only uses the second one for exit triggers. TransAM is unused, assumedly a leftover fragment of NOLF 2.
Adding a new TriggerType is safe and has no effect on the game. It's recommended to use a 64x64 texture to display on the screen. The texture's exact positioning on the screen is unfortunately locked and cannot be manipulated.

• Name (String)
  • The user-friendly name of the TriggerType. This is what will show up in DEdit.
• Icon (Path String)
  • The texture that will appear in the HUD when the Trigger's conditions are met.