Database reference

Phantom Brigade is a sprawling project with a myriad of different systems and databases. It can be hard to know where to start. In this article, we'll try to provide a brief overview of each database. This reference is not as comprehensive as a fully fledged tutorial on each database, but we hope it could serve as a useful starting point.

General notes

All databases are available through the DataModel prefab and are split into Collections and Global databases. The databases marked with the *️⃣ icon are very frequently used, tie into important parts of the game or are otherwise a great fit for modding.

In contrast, we recommend ignoring databases marked with 🟨 or 🟥 icons. They can be useful as a reference in some special cases, but generally, they are better left alone:

• 🟨 - Modification not recommended
• 🟥 - Modification not supported or the database is no longer in use

Collection databases

Collection databases have multiple files (e.g. individual items, pilot traits, dialogs and so on). The databases a further split by domain like combat, overworld, etc. You can browse the files underpinning each database by opening the Settings foldout and clicking the folder icon next to the path. Make sure to check the View Options foldout available on many databases to see additional options (for example, "Show Inheritance" available on data with parent hierarchies).

You can filter the displayed entries using the Filter field. We strongly recommend always having the Filter on, as this changes the interface and provides more options, such as easily renaming and duplicating existing configs.

Collections / Overworld

*️⃣ CampaignSteps
Key 2.0 DB. The highest level of data for the overworld campaign, defines the overarching step your campaign is at. Key elements:

• What happens on entry to a province with this step (typically, a quest starts)
• What happens on liberation of a province when in this step (typically, next province selection quest begins, a victory event etc.)
• What the the possible branches continuing from this step (e.g. does the campaign let you to go to the capital or does it loop back to another run of a different step)
• For each branch, what are the possible province links (for example, if you're in a branch not qualified to approach the capital, what are the two provinces you can access, how are these provinces randomly decided, what are the modifiers and level of these provinces etc)

*️⃣ Quests
Key 2.0 DB. Second highest level of data for the overworld campaign. Defines the objectives, reactions to events and stages you go through while within a particular province. Key elements:

• Quest steps: akin to stages of a combat scenario or pages of a dialog tree. Each step has their own objectives, text, reactions to events, effects on start and end, a link to next step etc.
• Shared effects: sets of functions that can be invoked by a key to reduce data duplication, typically called from multiple places within the steps. Can include reused elements like spawning question mark events, refreshing missions on the map, spawning patrols etc.

*️⃣ Interactions
Key 2.0 DB. Supercedes the old Events DB from 1.0. Defines the interaction events (dialogs) you encounter in the overworld.

• The interactions include the contextual events (such as dialogs upon approaching the frontline bases and enemy missions), fullscreen events (such as multi-choice screens between liberation phases) and immersive events (such as narrative beats with video backgrounds you see when traveling to a new province).
• One of the most powerful tools for integrating new content in mods: for instance, creating a high-priority interaction event that requires a frontline base and absence of a certain memory key, then sets that memory key when opened is a really simple way to quickly give the players new items introduced in a mod.
• This database supports multi-parent inheritance. Carefully check the parents field and explore the parents configs or enable Show Inheritance in the View Options to show the full extent of the data on each config.
• To reduce data duplication, the options in steps of interactions can be taken from other interactions (for example, a "Continue" option is mostly defined in one place and reused elsewhere). Keep an eye out for optionsReused data blocks under steps or text/data reuse data blocks under options.

PointsOfInterest
Key 2.0 DB. Supercedes the old EntityBlueprints DB from 1.0. Defines the points you see on the overworld map, including the mobile base, enemy missions, frontlines and question mark events.

*️⃣ Rewards
Key 2.0 DB. Defines the rewards (or more precisely, rules for generating randomized rewards) that can be referenced from points of interest and interactions.

*️⃣ Modifiers
Key 2.0 DB. Defines the province modifiers that are referenced by province links within campaign branches within campaign steps. Province modifiers are a very powerful way to modify how a province plays out, so make sure to thoroughly check built-in modifiers to learn the possibilities.

• They can range from simple multipliers to something like drastically altering liberation quests or injecting large modifications into every fight, up to deploying enemy ace pilots.
• Most effects are not referenced by name and are discovered via tags.

BaseEffects
Individual effects encountered by players after finishing camping or resupplying. Can trigger global game state changes or relate to modifying one of the mechs or pilots a player has selected during camping.

• Effects can declare conditions (for example, completing workshop projects is conditional on having workshop projects; a pilot having regrets about friendly fire is conditional on a memory of that incident etc.).
• Most effects are not referenced by name and are discovered via tags.

BaseEffectSequences
Sequences of BaseEffects that tell the game what should occur during a given type of a time skip (camp, resupply, travel). This is the DB to modify if you're after inserting additional deterministic effects into these mechanics (e.g. subtracting -1 quest progress at every camp stop).

BaseParts
Base upgrades. Can modify base stats and execute arbitrary effects on installation or on load.

• We recommend using on-load effects for any effects that can be safely called multiple times without compounding consequences. For example, a base upgrade that unlocks a certain workshop blueprint should use on-load effects, so that any user loading a save with that upgrade retroactively acquires it.

BaseStatGroups
Simple database defining groups of base stats displayed in the base upgrade screen sidebar.

BaseStats
Numerical stats for the mobile base. Have no innate effects. Stats values are calculated based on installed BaseParts and their effects on the world depend on the various game systems reading those stats.

OverworldActions
Largely deprecated database defining overworld actions: special entities that exist over time and can execute effects on start, over time or at expiration. Used for campaign objectives, repair mechanics and more in 1.0; no longer used for anything but workshop queue in 2.0.

FactionBranches
Definitions for the branches of enemy forces (army, reserves, spec ops etc.). Branches are primarily defined by filters: they filter UnitGroup tags (squad definitions), UnitPreset tags (individual unit definitions) and PartPreset tags (items equipped on units, per socket).

Memories
This database defines optional metadata for persistent memory keys. Persistent memory is a string/float map (dictionary) available on every pilot, mech and overworld entity, including the mobile base. The memory DB allows the game to reason about the memories of different entities, e.g. determine whether some memories need to be cleared on travel or determine how to present a memory on the screen.

NameGroups
Used by PointOfInterest configs, these configs are presets for name randomization (town names, military base names, convoy names etc). Rarely seen in the game, since most of the POIs players encounter are hostile mission sites that do not have a visible name.

*️⃣ ProvinceLandscapes
Metadata for the visual aspect of a province. They reference a 3D asset and provide information about where different types of PointsOfInterest can appear, which biome and weather can appear at which altitude, the rules for generating trees etc. See the Creating new regions tutorial for more information.

*️⃣ Provinces
Metadata for the high-level properties of a province. Includes name, description, rules for being visible on the world map, tags that determine how links in branches in CampaignSteps filter for a province to select, position on the world map, etc. See the Creating new regions tutorial for more information.

Starts
A special database defining custom campaign modes. Each config not marked hidden: true will add a button next to Full Campaign and Quick Start options in the New Game menu (provided that global overworld settings in overworld.yaml have customStartAllowed: true).

Collections / Economy

Resources
Configs for resources used in overworld mechanics, such as camp supplies, unit cores, part components etc.

WorkshopCategories
Categories for the workshop screen at the mobile base.

WorkshopProjects
Projects that player can build in the workshop.

• Largely unused in 2.0 after the redesign of the workshop crafting for parts and subsystems, only used for non-part, non-subsystem workshop projects such as building mechs or resource conversions.
• Do not create workshop projects for modded items like in 1.0, inheriting from existing Subsystem/PartPreset with workshopInfo or declaring workshopInfo separately will automatically register your part/subsystem into the workshop system.

WorkshopVariants
Sets of changes that can be applied to workshop projects. Largely unused in 2.0, previously used for letting players select different output rarities with different final cost etc.

Collections / Equipment

Groups
Categories of parts or subsystems. Used to allow players to filter items in their inventories and to display subtitles/expanded descriptions when inspecting items. Based on tags assigned to Subsystems or PartPresets.

Lights
Lighting profiles for firing weapons in combat. Unrelated to other special effects like muzzle flashes and smoke, concerned strictly with light. Referenced from Activation data blocks in Subsystems.

*️⃣ Liveries
Materials & colors that can be applied to mechs. Immediately available to players when added to the game.

• We recommend referencing existing livery configs to learn how to use smoothness, metalness (material) and other properties in this config
• We also recommend configuring the priority field and giving your livery filenames a consistent prefix to ensure they show up next to each other in the in-game grid
• The name and source fiels are remnants of Early Access UI and are not used in the game

LiveryPresets
Presets determining how an entire unit can be painted using one or more liveries (at the root level, socket level and/or hardpoint level). Describes unit customization in a way similar to player-facing livery customization screen.

• Used to differentiate different branches of the invasion forces and different squad types within these branches.
• This database supports parent inheritance. Carefully check the parent field and explore the parents configs or enable Show Inheritance in the View Options to show the full extent of the data on each config.

*️⃣ PartPresets
Parts are containers for subsystems and PartPresets are effectively blueprints telling the game how to create parts. They are one of the main data types related to units in Phantom Brigade.

• To make an analogy, each part in player inventory is akin a concrete manufactured car, whereas a PartPreset is a model of that car. Each PartPreset describes how to assemble that model, what it's called etc. Once an item is created, it maintains a soft reference to the PartPreset but can be modified further over time.
• This database supports multi-parent inheritance. Carefully check the parents field and explore the parents configs or enable Show Inheritance in the View Options to show the full extent of the data on each config.
• The most important field in PartPresets is genSteps (generation steps). Carefully check genSteps on existing equipment and on base configs like body_top, body_arm and body_bottom to learn how equipment generation is structured.

🟨 PartSockets
Sockets are slots in units that parts are attached to. Referenced in the body plan dictionary in the UnitBlueprints database (defining which part slots a unit type possesses) and on the PartPreset definitions (defining where a part can be installed into).

• We do not recommend adding more sockets to the game without careful consideration. Each new socket requires support on the unit prefabs (which are not modifiable without code injection) and is only necessary if you are after giving a mech a separately leveled, separately visualized and separately controlled part.
• A common idea is adding new sockets to attempt making quadruped mechs, weapon arms, additional arms etc. Unfortunately, all of these ideas can not be realized without hundreds or even thousands of additional animation clips, IK setups and lines of animation code. The mechs in Phantom Brigade are closer to playable characters in third person action games than to units in RTS games, and are not possible to extend in this manner without a qualified animator and direct access to the source project.
• We recommend working within the constraints of existing sockets and experimenting with adding new unit Hardpoints (slots within parts) if you're after expanding the depth of unit customization. Subsystems do not have the same issues with parent transforms, animations, IK and other complexities that a new socket would involve.

🟨 Recoil
Configs determining how the recoil is animated in combat. Referenced from the activation data block in weapon subsystems.

Shockwave
Configs determining the shape and timing of shockwaves created by melee attacks.

• We strongly discourage modifying built-in shockwave configs, as they were fine-tuned to match specific dimensions and timing of built-in mech animations.
• New shockwave types can be potentially added to differentiate modded melee weapons.
• Each new config must have a counterpart with an _inv suffix depicting an inverted attack (to support melee weapons held in the left hand or melee attacks inverted via Ctrl).

SubsystemHardpoints
Slots for installing subsystems. Referenced in PartPresets (specifically in AddHardpoint steps under the generation steps lists, defining subsystem slots added to each part) and on subsystem blueprints (defining where a given subsystem can be mounted to).

SubsystemStatDistributions
Used to simplify definitions for external armor subsystems.

• Effectively a set of multipliers that totals 100% that can be used on a subsystem and checks its hardpoint to determine how to multiply the stats from its parent. Examine the subsystems like armor_[set name]_head, armor_[set name]_leg etc. to see how distribution applies.
• Due to a bug in the SDK, the field might not appear in the inspector. This should not be a significant blocker since there is only one stat distribution available (armor) and we expect new armor_[set name]_* configs to be created by duplicating equivalent configs from existing sets.

*️⃣ Subsystems
The most important source of data for all units. A config that defines nearly everything you can think of about an item within a unit: stats, visuals, activation and projectile (if it's a weapon), user facing text, tags etc.

• The tags on subsystem blueprints are extremely important. Subsystems are often filtered instead of referenced by tag. Carefully review tags on subsystems themselves and on PartPresets and other filters. Try to base new subsystems on existing subsystems in the same role to ensure you start from correct set of tags.
• This database supports parent inheritance. Carefully check the parent field and explore the parent configs or enable Show Inheritance in the View Options to show the full extent of the data on each config.
• This database makes extremely heavy use of optional fields. Keep an eye out for the optional component dropdown in the bottom right of each config and do not use plaintext YAML to learn the full available surface of this config. There are optional fields within optional fields within optional fields (such as optional inputs into the guided flight program of projectile data block).

Collections / Units

Blueprints
Configs defining body plans, part compatibility, 3D asset references and other values that differ between each unit type.

• We do not recommend creating new unit blueprints unless you have mastered modding of UnitPresets, PartPresets, Subsystems, PartSockets, SubsystemHardpoints, unless you have a very good reason for avoiding every single existing blueprint and unless you have a plan for making existing body prefabs compatible with your new blueprint. Majority of potential unit changes can be accomplished without creating new unit blueprints, via UnitPresets and other means (for example, bosses do not utilize new unit blueprints at all).

Checks
Pre-flight checks for units that run every time unit state changes in overworld and every time you prepare to enter a mission.

• Checks marked as warnings show up in unit tooltips.
• Checks marked as critical errors will block deployments.

Composites
Complex data container primarily used for defining bosses. Allows the game to glue multiple conventional units into a single meta-unit (hence the name "composite").

• All constituent units must belong to unit_system blueprint, and therefore must have only one socket.
• The trios of UnitPresets + PartPresets + Subsystems utilized in bosses are usually created via the UtilityUnitSystemBuilder component available on the Units object above the Composites database inspector.
• This database supports multi-parent inheritance. Carefully check the parents field and explore the parents configs or enable Show Inheritance in the View Options to show the full extent of the data on each config.
• Each composite usually includes a layout (body plan referencing individual units, their local positions under the root unit) and a director (a special AI definition that is a tree of conditional nodes).

🟨 HitTables
Configs determining how hits from different precise directions directions (like 78 degrees to a unit right) translate to damage to the limited number of unit sockets (for example, "for a hit from the right quarter arc, there's a 60% chance the damage goes to an arm and a 40% chance it goes to legs").

PerformanceClasses
Configs defining ranges of specific stats and declaring user facing icons and text associated with that range. They help the UI summarize unit stats to players (e.g. display whether a unit is fast, heavy etc).

*️⃣ Presets
UnitPresets are similar to PartPresets, but instead of being instructions for manufacturing an individual part, they are instructions for manufacturing a unit.

• This database supports multi-parent inheritance. Carefully check the parents field and explore the parents configs or enable Show Inheritance in the View Options to show the full extent of the data on each config.
• Part Tag Preferences allow for loosely restricting which parts appear on entire groups of sockets like the full body. Useful for restricting armor.
• Parts allow for specifying content of individual sockets. Typically used to set weapons.
• Each per-socket override can override or filter for parts, and even override subsystems independently from part generators. You can use UnitPreset to force a certain set of armor to spawn with a different reactor, bolt an additional subsystem hardpoint and subsystem instance that are not even present in the original PartPreset and so on.
• In the developer mode, you can use Num 7 in combat to browse and spawn UnitPresets directly. The Generate button in that developer menu is an invaluable tool for iterating on UnitPreset configs: it can show you how every condition you specify affects the final unit loadout and can be rerolled repeatedly to see all the random permutations.

Roles
Small configs with text and an icon attached. Can be referenced on units in combat to allow UI to display unit classification.

• Name override toggle makes roles supercede customizable unit names. Useful for key enemy units (e.g. you can create a role reading "VIP", "Generator", "Key Target" etc.).
• Selectable toggle makes a role selectable in the mech customization screen.
• Consider sideloading additional sprites via the Textures folder if you are planning to add new Roles and require new icons.

Stats
Configs for stats referenced in subsystems. Most of the config consists of UI inputs, determining display format, locations where a stat can be displayed, etc.

Status
Status effects that can affect a unit.

• A very powerful tool that can be triggered from subsystems, pilot traits and a myriad of other sources. Status effects are used to implement "Well rested" and "Exhausted" mechanic, overheat burn mechanic, electrical and incendiary weapons etc.
• Referenced in the buildup section of weapon subsystems
• Can execute completely arbitrary effects on attachment, expiration, tick etc.

Collections / Pilots

AppearancePresets
Configs describing the full appearance of a pilot. Optionally referenced in CreatePilot functions and combat unit customization data blocks to override randomly generated appearances. Similar data structure to pilot appearance configs in player saves (opening YAML files for AppearancePresets and player saves side by side is a quick way to fill these configs).

🟨 AppearanceProperties
Configs for individual customizable properties in the pilot appearance editor. We do not recommend modifying this database, it's mainly a convenience database for UI systems and no useful moddable surface. Refer to global Pilots database if you're after adding new customization options.

Checks
Pre-flight checks for pilots that run every time pilot state changes in overworld and every time you prepare to enter a mission.

• Checks marked as warnings show up in pilot tooltips.
• Checks marked as critical errors will block deployments.

🟨 Events
Metadata for pilot events: game state changes involving pilots that are called out by the game and can be tapped by pilot traits.

• The main moddable field is the experience value attached to some of the events.
• We do not recommend modifying anything else in this database.

🟨 Personalities
Configs for sets of animations randomly attached to pilots. The personalities have no effect on gameplay and are tightly coupled to animation assets built into the game, so we do not recommend modifying this database.

Profiles
Special configs used to create persistent pilots: enemy aces created from special province Modifiers and persisted between several fights. Each config lets you declare a unit the ace spawns with, special logic, responses to various key events like deployment or defeats, and even a basic AI system running on top of standard unit AI (for conditional special attacks etc).

• Profile key can be changed over the course of pilot life. The built-in ace pilot ("Major Payload") switches profile keys each time he is defeated, which is how the game makes that pilot appear in a new mech with altered behavior and dialog every time you face him.

Stats
Metadata for pilot stats. Primarily referenced from Traits database.

• We do not recommend modifying any existing stat names, or values (outside of UI display fields and limits), as some of the existing stat configs are tightly coupled to game logic.
• Stats prefixed with ability_ with an Action Link data block are used to track the number of charges for performing an ability (combat Action)
• Target Unit Part data block can be used to make a pilot stat affect any mech stat on all or select parts. This can be used to create a wide variety of pilot traits affecting piloted mechs.

Traits
Random perks generated in the progression tree of each pilot.

• The tags on the traits are extremely important. Carefully reference tags on existing traits when creating new traits and examine how slots under pilot Types filter for traits by tag. Correctly assigned tags allow any new traits you add to correctly appear in random pilot generation.
• Traits can be used to execute completely arbitrary logic on any pilot event. This is an extremely powerful tool that can be used for anything from simple heal-on-kill perks to special behavior attached to enemy ace pilots.

Types
Configs for pilot classes. Conceptually similar to unit blueprints and especially PartPresets, featuring a sequence of trait slots attached to different levels, with potential candidate traits filtered by tags. Refer to the Creating pilot classes tutorial (coming soon) to learn more.

Collections / Combat

Actions
Actions available to units in combat. Automatically refreshed when unit state changes (e.g. a unit loses a limb) and every time a new turn begins.

• Actions can be used for a myriad of different purposes ranging from simple attacks to special abilities linked to subsystems, pilots or unit types.

AITargetingProfiles
Config determining weights given to different factors affecting how high of a priority each potential player unit is to a given AI unit. Referenced from UnitPresets and unit spawn slots. We do not recommend modifying this database unless you are familiar with the combat AI code and know how each of the weighted factors is determined.

*️⃣ Areas
Levels used in combat and their metadata (tags, spawn positions, trigger volumes etc.)

• This is a special database that consists of more than one file per entry. Instead of each level being a solo .yaml file in a shared folder, each level is a subfolder named after the data key. Inside that subfolder, there is the main config main.yaml and a large number of additional files encoding the level structure and properties.
• This database can not be filtered. Use the dropdown on top of the inspector to view one entry at a time.
• The shape of the level is modified through a separate component called AreaManager (Area in the hierarchy of game_extended_sdk scene). Once you click Select on a chosen Area config, you will see a button allowing you to quickly jump to the level editor. Make sure you have installed the optional assets, otherwise the level editor will not be available.
• Most areas are filtered by tag and not referenced by exact key. This means that any level you add to the game will naturally appear in standard missions, provided it has appropriate tags.
• The subject of creating new levels warrants a separate tutorial, similarly to creating new regions. Check out the Creating new levels tutorial (coming soon) to learn more.

Biomes
A config determining how the landscape and vegetation appear in combat. Controls ground textures, vegetation color, presence of snow and other related values.

• Referenced from ProvinceLandscape layers. This allows, for example, making fights in the snow-capped peaks load into snowy biomes while making fights at lower ground load into green biomes.
• Can be optionally filtered or directly set from scenarios and points, forcing certain POIs or missions to have a fixed biome (see the capital fight configs, first province POI configs etc).

🟥 Modifiers
Combat modifiers were removed from the game with 2.0. What was previously implemented using combat modifiers can be implemented via modification of PointsOfInterest, province modifiers and conditionally injected scenario parents.

QualityTables
...

🟥 Reinforcements
External reinforcements were removed from the game with 2.0. Similar functionality can be achieved via the conditional parent injection feature of the scenario system. Check out scenarios with inj_ prefix to learn more.

*️⃣ ScenarioComms
Combat dialog. Each dialog is attributed to a specific source and can contain multiple lines. Depending on selected modes, multiple lines can be treated as random variations or a sequence that advances every time a dialog is triggered.

ScenarioCommsSource
The speakers the dialog is attributed to.

ScenarioGroups
Classification configs for scenarios. Similar to equipment groups: require specific tags to be present on a scenario for that scenario to be classified as having a given group. The group with a highest priority provides displayed scenario name and description, lower priority groups are displayed as hints in the mission information UI.

*️⃣ Scenarios
Mission blueprints. One of the most important and feature rich databases in the entire game.

• This database supports multi-parent inheritance. Carefully check the parents field and explore the parents configs or enable Show Inheritance in the View Options to show the full extent of the data on each config.
• Most scenarios consist of steps (similar to dialog steps) and states (objectives and conditional reactions).
• Check out the Creating scenarios tutorial (coming soon) to learn more.

🟨 Stats
Configs for stats measuring various characteristics of a completed fight: duration, travel distance, damage, etc. We do not recommend modifying this DB, it mostly provides metadata for UI and the DB can't be used to introduce new stats without dedicated tracking code.

Strikes
Definitions for various artillery strikes and airstrikes you can encounter in the game.

• Effectively a blueprint for a special type of an owner-less attack action that is recognized by the prediction and execution systems and bakes information about firings from a specific weapon at a specific position.
• Optionally reference an animated asset (mostly a plane doing a low pass over the map) and transforms on that animated asset. This allows making a strike where a plane fires missiles sideways, or fires a gun forward etc.

*️⃣ UnitGroups
Squads that players encounter in combat.

• One of the most important configs referenced by FactionBranches and Scenarios (they do not reference individual units, only squads).
• Used primarily through tag filters. Adding new squads with the right tags will ensure they automatically appear in game without any additional integration steps.
• Each squad can declare up to 3 grades: different, progressively advanced versions (standard, veteran, elite). These grades are used by the escalation system to scale the difficulty of a scenario (or can be directly requested by a scenario squad slot).

Collections / Other

🟨 AssetPools
Configs for pooled assets. Currently, the game does not support side-loading new pooled assets through AssetBundles, so we recommend against modifying this database or adding new entries to it. The only value that might be worthwhile to modify is the limit value: increasing it would increase the number of instances (like missiles) that can simultaneously exist, at the cost of higher RAM and VRAM usage.

Codex
Articles available through the Codex screen. Assembled out of a list of interface entries, allowing for variable structure (the same slot can be a header, text, quote, image, video, etc). Can utilize textures from any TextureManager group, including sideloaded textures.

🟨 CutsceneVideo
Configs for video cutscenes. We do not recommend modifying this DB as there isn't much that can be reasonably adjusted on these configs.

*️⃣ DifficultySettings
Configs for difficulty settings available in the pause menu or when starting a new game. Modifying existing difficulty settings by adding entries to the levels dictionaries is a quick way to add mod fine grained options.

🟨 GameSettings
Configs for different game settings (input, graphics, etc). We do not recommend modifying this database as the built-in values are tightly coupled to implementation of the settings in game code and there isn't much that can be added through configs alone. About the only potential target for modding in this database is adding more resolution options to the resolution setting.

🟨 InputActions
Configs for individual actions a player can map inputs for (Confirm, Execute, Move camera etc). Modification not recommended.

🟨 InputHints
Configs for input hints displayed in some parts of UI ([User hotkey]: Skip cutscene etc). Modification not recommended.

Tutorials
Linear tutorials displayed to the player at different moments throughout the game. A powerful system for linear content that can trigger completely arbitrary effects at every step, point out parts of the screen, block input and tap into progress in external systems. Can be potentially useful for mods (e.g. to interrupt gameplay to teach a player about a modded gameplay feature or issue items).

UIColors
A utility database for various colors used in the UI. Doesn't cover every color that appears in the interfaces across the game, only used in some special cases requiring perceptually uniform hue variations.

Global databases

🟨 CombatBiomes
Combat landscape texture references. Already links to every available texture, modding not recommended.

🟥 History
Tracks collection database key changes during development, enables save upgrading.

🟨 SettingsAI
A small number of inputs for combat AI.

🟨 SettingsAnimation
Every input required for the mech animation system. Most values are highly dependent on animation clips so changes are not recommended.

🟥 SettingsAnimationAudioEvents
Audio events called on specific animation events. Existing configuration is the only valid configuration, modification not recommended.

SettingsArea
Small set of inputs for the combat navigation grid generator and level destruction physics.

🟨 SettingsAudio
Small set of inputs for the combat audio system. In sync with the internal audio system settings, best left unmodified.

SettingsCamera
Camera-relative shadow distance per game context, some audio settings related to interpreting camera position, and mech mounted camera presets.

🟥 SettingsDebug
Special DB controlling debugging flags (developer mode, logging, etc.) intended to be overridden from the user folder. Should never be modified in a mod. To utilize debug flags, copy the debug.yaml file from that DB and place it into AppData/Local/PhantomBrigade/Settings and modify it as you see fit, e.g. to enable developer mode.

🟥 SettingsEscalation
Settings for the 1.0 war system. Unused by 2.0 overworld systems, will be removed in the future.

SettingsMusic
Inputs for the dynamic combat music system.

*️⃣ SettingsOverworld
A myriad of values related to overworld mechanics and economy. Second largest config among the global databases. We strongly recommend using config editing to modify this DB to avoid collisions with other mods.

SettingsPilots
Primarily stores inputs for the systems managing 3D pilot visuals. Everything under the Colors tab is an easy fit for a mod (e.g. adding additional hair colors). Modifying floats under the Values tab is not recommended, with exception of camera angle presets. The Shapes tab relates to customization sliders and should not be modified as all data is synced with 3D models. The Assets tab can't be modified at the top level (references to in-project assets), but secondary properties like suit color variants can be reasonably modified.

🟥 SettingsProvinces
Settings for the 1.0 province system. Unused by 2.0 overworld systems, will be removed in the future.

🟨 SettingsRendering
Settings for the custom instanced rendering pipeline used to render the destructible levels in combat. We strongly recommend avoiding any changes in this config: this is a low-level system that can cause hard crashes and extreme performance degradation if misconfigured.

*️⃣ SettingsSimulation
One of the most important configs configs in the game storing a myriad of key values, multipliers and settings. We strongly recommend using config editing to modify this DB to avoid collisions with other mods.

SettingsUI
Various UI settings like color presets, multipliers for targeting calculations etc. We recommend limiting modifications to contents of the Colors tab.

🟥 Tilesets
Settings for combat level tilesets. Not a true collection data linker, inaccessible to the mod system.