Objects and identities

Section titled “Objects and identities”

This page covers formation organisation, headquarters capacity, command propagation, support attachments, deployment and transport. It separates the reusable organisation blueprint from the live chain of command and from temporary support assignments.

Formation size and HQ command capacity use ground-unit size in tons, not soldier headcount or the number of subordinate formations. Race, species, population, ship, parent and support target are independent links. Window checks protect particular editing paths. Many other actions assume that a valid object was chosen before they run.

Construction costs, training throughput, mineral and wealth accounting and replacements are covered in ground force construction and replacements. Movement order timing and cargo operations are covered in movement and logistics. This page focuses on the relationships those operations keep or change.

Object and stored ID Meaning
Ground unit class (FCT_GroundUnitClass.GroundUnitClassID) Design of one unit, covering size, armour, components, HQ capacity (HQCapacity) and capabilities
Formation template (FCT_GroundUnitFormationTemplate.TemplateID) Reusable composition of class and count element rows, with name, abbreviation and an optional required rank
Formation (FCT_GroundUnitFormation.FormationID) An actual formation with its own elements, race, population or ship, commander, field position, original and replacement templates and organisational relationships
Formation element (FCT_GroundUnitFormationElement.ElementID) A class, count and species aggregate in a live formation. It carries morale, supply, fortification and targeting state
Template element The same kind of element record, held by a template instead of a formation. It is stored separately as template, class and count rows (FCT_GroundUnitFormationElementTemplates)
Organisation node (FCT_OrganizationNode.OrganizationID) A reusable blueprint tree node, optionally holding a formation template, with a parent node (ParentOrganizationID) and a field position
Organisation link (FCT_GroundUnitFormation.OrgLinkID) A race-local construction link on a live formation, used to attach queued formations that complete separately. It differs from OrganizationID and FormationID
Parent formation (ParentFormationID) The live command hierarchy. Each subordinate formation points to its parent
Support target (AssignedFormationID) The formation a formation supports. It does not change the supporting formation’s parent

A formation keeps no list of its children. The game finds subordinates by searching every formation in the game for those whose parent is this formation. Changing a template or a blueprint does not rewrite the live parent tree. Template elements have no stored ElementID in the template table, whereas actual elements do.

A live formation can keep a parent at another location after embarkation or movement. Parent membership and the ability to receive parent bonuses are therefore separate questions (see own and parent bonus propagation). The location shown for a formation is its population name first, then its ship name, then Unknown.

Blueprint hierarchy and creation

Section titled “Blueprint hierarchy and creation”

Editing the reusable tree

Section titled “Editing the reusable tree”

The Organizations tab of the Ground Forces window holds the blueprint tree. Creating a node takes a parent, an optional template and a name. It assigns a new OrganizationID and adds the node to that race’s nodes. Node creation does not enforce HQ ordering, same race, location, species or a tree free of cycles. A node without a template is a named grouping node, not an empty formation. A node with a template shows the template abbreviation and name plus a field-position suffix. The suffix is “(FA)” for Front Line Attack, “(SP)” for Support, “(RE)” for Rear Echelon and none for Front Line Defence. This label can differ from the node’s OrganizationName, which the tree uses for sorting.

Dragging on the Organizations tab refuses a drop on the same node and refuses formation-element nodes. It walks up the target’s ancestors to prevent moving a node below its own descendant. Dragging a root node copies its subtree under the target. Dragging a node that already has a parent moves it by changing its parent node. This differs from live formation attachment. The blueprint drag makes no HQ capacity or commander-rank test.

Copying a subtree creates new IDs for nodes with templates and keeps the same formation template, field position and expanded or collapsed display state. Grouping nodes without a template are not copied as extra nodes. Their children are copied directly under the destination parent. Delete Node removes the node’s blueprint descendants and the node itself. It does not delete existing live formations made from them.

The tab’s Field Position button can change only the selected node, the selected node and all its descendants, only its descendants, or all nodes that use the same template. These choices change blueprint field positions for future creation, not the deployment of existing formations.

Queued construction versus instant creation

Section titled “Queued construction versus instant creation”

The Construct Org button requires a selected root node with no parent and a selected construction population. The population list holds the race’s own colonies with at least one Ground Force Construction Complex (raw installation count above 0), sorted by name. Queueing visits the blueprint recursively. Each node with a template gets:

Children are queued after their parent. Names come from the template’s next formation name. Each name adds 1 to the template’s trained count (FCT_GroundUnitFormationTemplate.FormationsTrained) and returns that count as an ordinal (1st, 2nd, 3rd and so on) followed by the template name. With Enter Names ticked, a name dialogue opens for each formation. Cancelling it keeps the generated name. Naming themes, automatic naming and hull numbers covers the wider naming rules.

When training completes and the item’s ParentLinkID is above 0, the population looks for the first formation in the game whose OrgLinkID equals that parent link. It then creates the formation with its own OrganizationLinkID. The search covers all formations and has no race or location condition. The completion itself has no later step that reconnects a child whose expected parent was absent at that moment.

A node without a template sets the queued link to 0 for its own children. Descendants below that grouping node therefore receive ParentLinkID 0, even when the incoming parent was a real formation node. Instant creation instead carries the incoming parent through a node without a template, so its template children are created under the nearest actual parent. Queued and instant trees can therefore differ for the same blueprint when it contains an intermediate grouping node.

The Instant Org button also requires a root node and a selected population with a Ground Force Construction Complex. It creates the formations recursively at once, with OrgLinkID 0 and the population’s species. After each formation it subtracts the formation’s total cost, cut to a whole number, from the race’s starting build points (FCT_Race.StartBuildPoints). It subtracts only when that pool was above 0 at that step. The root-node and construction-complex checks belong to the button, not to the creation step itself.

Creating a formation from a template sets both the original and the replacement template to that template. It records the parent and the organisation link and copies the template’s class and count rows into new live elements with the chosen species and morale 100. The required rank is the template’s stored rank when it has one, and otherwise the calculated rank (see required rank). A formation made from one of the game’s automated templates takes that automated design’s field position instead of the supplied one. Creation makes no check of HQ order, total capacity, cycles, species, race or location. An empty formation, such as the new formation made when an element is dragged to a population, starts with no templates and no parent.

Live parent and support attachments

Section titled “Live parent and support attachments”

Command hierarchy attachment

Section titled “Command hierarchy attachment”

On the Order of Battle tab of the Ground Forces window, dropping a node on itself does nothing. Dropping a formation on empty tree space clears its parent. Dropping it on another formation first checks location:

  • When the dragged formation is at a population, the target must be at that same population.
  • When the dragged formation is aboard a ship, the target must be aboard that same ship.
  • When the dragged formation has neither a population nor a ship, the check passes.

The refusal message reads “A formation can only be transferred to a parent formation located in a population on the same system body or on the same ship”. The population rule is stricter than sharing a body. Race and species are not checked. The displayed tree normally limits the choices to the selected race.

For a parent attachment, the target’s highest own-element HQ capacity must be above 0 and strictly greater than the dragged formation’s highest own-element HQ capacity. The drop does not compare combined tonnage with capacity, does not limit the number of children, does not scale capacity by HQ unit count, and does not require the new commander to outrank the child’s commander at that moment. On success the target becomes the formation’s parent and the tree node moves under it. A parent attachment does not clear an existing support target.

The Order of Battle drop has no ancestor walk against cycles. A strict HQ increase along each parent link made there normally prevents cycles while designs and capacities stay unchanged. Other ways of setting a parent, such as creation from a blueprint and relationships restored from a save, do not enforce that rule. The searches that walk down to children or up to ancestors have no protection against a cycle. The blueprint editor of the Organizations tab does have the ancestor check described above.

The Clear Hierarchy button clears only the selected formation’s parent. It does not remove a support assignment or the commander.

Ground formation support targets

Section titled “Ground formation support targets”

When the target’s HQ capacity is 0 or not larger than the dragged formation’s, the drop tries a support assignment instead of a parent attachment. Both formations must be at populations on the same system body. The supporter must also meet one of two conditions:

  • it is a superior formation of the target, anywhere up the target’s chain of parents,
  • it has no subordinate formations and its own parent is a superior formation of the target.

“No subordinate formations” counts every formation in the game. A target without a parent has no chain of superiors and cannot be supported this way. When either formation has no population, the game shows error Function #1774 and refuses the support. This route therefore has no shipboard equivalent.

A successful support assignment sets the dragged formation’s support target and keeps its parent. A support target means directed support, not ownership of units or a new HQ chain. Positions, targeting and support covers what support does in combat. Each time the Order of Battle tree is rebuilt, a supporting formation loses its target when the target or the supporter has no population, or when their populations lie on different system bodies. Two different populations on the same body keep the support in that cleanup, even though a new drop between them is refused by the exact-population location check. The cleanup runs while the tree is filled, not whenever a support target is set.

Aircraft and orbital bombardment support

Section titled “Aircraft and orbital bombardment support”

A support ship dropped onto a ground formation must have its fleet in orbit of the target’s population body. The forward fire direction (FFD) capacity is FFD = sum over the target's own elements of units x class FireDirection, where the class value is the total DIM_GroundComponentType.FireDirection of the unit class’s components. A target with 0 FFD refuses the ship. Each FFD provides 6 slots. A ground support ship costs 1 slot. An orbital bombardment support ship, whose fleet holds a Provide Orbital Bombardment Support order, costs 6 slots.

Existing assignments count against the slots only when the ship belongs to the target’s race, its fleet orbits the target’s body and the fleet holds the matching Provide Ground Support or Provide Orbital Bombardment Support order. free slots = FFD x 6 - used slots, and they must be at least the incoming requirement. An assignment records the ship’s support target (FCT_Ship.AssignedFormationID). It does not reparent ground formations.

The Ground Support Aircraft group of the tree lists the ships of fleets with an arrived Provide Ground Support order at the population’s exact coordinates in the same system, whose largest ship is 10 HS or smaller. Docked parasites are left out. The Orbital Bombardment Support group likewise requires an arrived Provide Orbital Bombardment Support order at the exact coordinates and system, lists only independent ships, and sorts them by class size descending, then class name, then ship name. Docked aircraft must be launched to appear in these lists. When the tree is rebuilt, the game clears an independent support ship’s assignment when the target has no population or when the ship’s fleet no longer orbits the target’s body. Breakthrough and air support covers what these ships do in combat.

HQ capacity and command bonuses

Section titled “HQ capacity and command bonuses”

What capacity measures

Section titled “What capacity measures”

A ground unit class stores its HQ capacity (FCT_GroundUnitClass.HQCapacity) as the value entered when the class was created. The class’s component maximum is a separate value, the highest DIM_GroundComponentType.HQMaxSize among its components. On the Unit Class Design tab, the Headquarter Capacity box applies when the primary component has HQMaxSize above 0. The preview strips characters other than digits and reads a whole number. Neither the preview nor class creation clamps the entered capacity to the component’s HQMaxSize. Leaving the box with a value that parses to 0 or less changes it to 1. HQ size and cost growth is a production matter. It does not multiply command capacity by unit count. Ground-unit class design covers the class recipe.

For an actual formation, own HQ capacity is the highest unit class HQ capacity among its elements, or 0 when it has no elements. It does not add HQ ratings together, multiply by units, apply armour or weapon technology, damage or environmental modifiers, or test that units are above 0. Reducing an HQ element from 10 units to 1 therefore keeps the same command capacity. An HQ element kept at 0 units still counts until it is removed from the element list. Templates use the same maximum over their template elements. The formation summary’s HQ maximum can include descendants when the summary includes child formations, whereas command capacity uses own elements only.

During increment preparation, the game stores each formation’s own size as sum of unit class size x units, cut to a whole number. It then adds those already-cut own sizes over the formation and all its descendants, wherever they are, into the formation’s total command size. Afterwards it refreshes the capacity modifier of every commander who commands a formation. Attachments elsewhere therefore still add to HQ load even when location blocks their inherited bonuses, and the stored values can be stale until the next refresh.

Overcapacity is an integer-division cliff

Section titled “Overcapacity is an integer-division cliff”

The capacity modifier starts at 1. When the formation’s total command size exceeds its own HQ capacity, the modifier becomes:

modifier = own HQ capacity / total command size, divided in whole numbers.

Both values are whole numbers and the division drops the remainder before the result is stored. For any positive overcapacity the modifier is therefore 0, not a fractional ratio. Equality keeps 1. A commander without a formation command gets 0. Overcapacity does not reject or remove children. It suppresses the commander’s bonus excess through this modifier instead.

For example, an HQ of 10000 commanding a total of 10000 keeps modifier 1. An HQ of 10000 commanding a total of 10001 gets modifier 0. Reading this as 10000/10001, about 0.9999, would misdescribe the game.

Own and parent bonus propagation

Section titled “Own and parent bonus propagation”

For a commander’s raw bonus multiplier B and stored capacity modifier c, the adjusted own multiplier is 1 + (B - 1) x c when c is below 1, and B otherwise. The commander’s effective ground command multiplier is that adjusted own multiplier times the factor inherited from the formation’s chain of parents.

Each eligible parent contributes:

1 + (parent raw bonus - 1) x 0.25 x parent capacity modifier.

The share of 0.25 is fixed. These factors multiply up the chain, each parent’s factor times the factor of its own parent. A link stops the inheritance and contributes 1 when:

  • the formation has no parent,
  • the parent has no population,
  • the parent is at a different population from the child,
  • the parent has no commander.

A missing commander at an intermediate HQ therefore prevents higher HQs from being reached through that link. Being aboard the same ship does not satisfy the population requirement. Each factor uses the parent’s raw bonus and capacity modifier, not the parent’s whole effective multiplier a second time.

Combat preparation uses the effective multiplier only for a formation that has its own commander. Otherwise the Ground Combat Defence, Offence, Logistics, Manoeuvre, Artillery and Anti-Aircraft multipliers stay 1. A subordinate without a commander does not gain higher-HQ bonuses through these combat multipliers. Two formation-level values use the effective multiplier as well:

  • the formation’s total construction rating, which is (sum over elements of units x unit class ConstructionRating) x commander's effective Production multiplier,
  • morale training, which uses the commander’s effective Ground Combat Training multiplier (see supply, fortification and recovery).

The construction rating of a single element is instead units x ConstructionRating x raw Production bonus, using the raw bonus of its own formation’s commander. These are separate uses and do not form one universal bonus path.

Ranks and commander assignments

Section titled “Ranks and commander assignments”

Required rank

Section titled “Required rank”

Ranks use a decreasing FCT_Ranks.Priority for increasing seniority. The next higher rank is the rank of the same type at Priority - 1. The next lower rank is at Priority + 1. Ranks, themes and seniority covers the rank records themselves.

The required ground force commander rank is the first matching tier for the formation’s whole-number own size S and its own highest HQ capacity H:

Grade Condition
1 S <= 5000 and H <= 5000
2 S <= 12500 and H <= 12500
3 S <= 25000 and H <= 25000
4 Otherwise, H <= 125000
5 Otherwise, H <= 500000
6 Otherwise, H <= 2500000
7 H > 2500000

Grade 1 is the most junior ground force commander rank, the one with the highest Priority. Grade 2 is the next rank up, and so on. Beyond grade 3, own size is no longer part of the test. When the race has no rank at that grade, the game falls back to the ground force commander rank with the lowest Priority, which is the most senior.

A template’s stored required rank (FCT_GroundUnitFormationTemplate.RequiredRank) overrides its calculation. A live formation’s stored required rank (FCT_GroundUnitFormation.RequiredRank) likewise gives its Priority at once. Only when a live formation has no stored rank does the game calculate its size and HQ tier. It then raises the requirement to one rank above any direct child commander whose rank Priority is at or below the current requirement. This child test looks at direct children with no location or race filter. Ordinary creation from a template stores a required rank, so later hierarchy changes do not necessarily reach this dynamic calculation.

Assignment eligibility and replacement

Section titled “Assignment eligibility and replacement”

The assignment list of the Commanders window shows formations of the commander’s race. With Eligible Only ticked, it keeps formations whose required rank Priority is at or above the commander’s. With Available Only ticked, it keeps formations without a commander. It sorts the list by HQ capacity descending, total cost descending, then name. Assigning from the list refuses a rank that is too low and an assignment the commander already holds.

The assignment itself repeats no rank, race, species or location check. It clears the incoming commander’s old assignment and clears the assignment of the formation’s current commander. It sets the commander and formation links both ways and sets the command type to Ground Force Commander (FCT_Commander.CommandType 5). It copies the formation’s population and transport ship to the commander’s location and records the assignment time and a history entry. The assignment model covers assignments of all commander types.

Automatic assignment considers active ground force commanders of the race who are not in a lifepod and not prisoners. It visits the race’s formations without a commander, largest own size first. It makes two passes:

  1. The first pass uses unassigned commanders at exactly the required rank.
  2. The second pass uses commanders promoted more than a year ago and not marked Do Not Promote (FCT_Commander.DoNotPromote), at the next lower rank. It promotes the chosen commander.

The second pool does not require the commander to be unassigned, so the chosen commander may be taken from another command. Promotion and demotion covers promotion itself.

The commander is chosen by the formation’s role. Each role first requires a bonus above 0, then sorts. Ties go to the higher promotion score in every row:

Formation role Commander qualifies with Sorted by
Ground artillery Ground Combat Artillery Artillery + Ground Combat Training + Political Reliability
Ground anti-aircraft Ground Combat Anti-Aircraft Anti-Aircraft + Ground Combat Training + Political Reliability
Survey Survey Survey, then Ground Combat Training + Political Reliability
Xenoarchaeology Xenoarchaeology Xenoarchaeology, then Ground Combat Training + Political Reliability
Engineering Production or Xenoarchaeology Production, then Xenoarchaeology + Political Reliability
Decontamination Decontamination Decontamination, then Ground Combat Training + Political Reliability
Planetary defence Tactical Tactical + Ground Combat Training + Political Reliability
Ground attack Ground Combat Offence or Ground Combat Manoeuvre Anti-Aircraft + Ground Combat Training + Manoeuvre + Political Reliability
Ground defence Ground Combat Defence Defence + Ground Combat Training + Political Reliability
Ground logistics Ground Combat Logistics Ground Combat Logistics + Ground Combat Training + Political Reliability
Generic Ground Combat Offence, Defence or Training Anti-Aircraft + Offence + Defence + Political Reliability

Two rows hold literal scoring quirks. Ground attack qualifies on offence or manoeuvre but sorts on anti-aircraft, training, manoeuvre and reliability. Generic qualification includes training, but its score uses anti-aircraft, offence, defence and reliability. A commander without a percentage bonus has the default multiplier 1 for it, and every bonus in this table is a percentage bonus (DIM_CommanderBonusType.Percentage 1). A test for a value above 0 therefore does not mean that a specialist has any positive percentage excess.

The formation role comes from own-element tonnage. Each tonnage is unit class size x units for the elements that match. Non-logistics size is total size - logistics size. The rules apply in this order, and the first that is met sets the role:

Order Role Test
1 Ground logistics size of elements with a logistics component > 2 x non-logistics size
2 Ground artillery size of elements with a bombardment weapon > 0.4 x non-logistics size
3 Ground anti-aircraft size of elements with an anti-aircraft weapon > 0.4 x non-logistics size
4 Engineering stored total construction rating > 0.4 x non-logistics size
5 Survey size of elements with a geological survey component > 0.4 x non-logistics size
6 Xenoarchaeology size of elements with a xenoarchaeology component > 0.4 x non-logistics size
7 Decontamination size of elements with a decontamination component > 0.4 x non-logistics size
8 Planetary defence size of elements with an STO component > 0.4 x non-logistics size
9 Ground attack medium vehicle size > 0.6 x non-logistics size
10 Ground defence static size > static size x 0.6
11 Generic no test passed

The engineering rule uses the formation’s stored total construction rating, not the tonnage of its construction elements. The ground defence rule compares static size with itself, so any positive static size passes when no earlier rule gave a role.

Deployment and transport

Section titled “Deployment and transport”

The Order of Battle tab’s Field Position button can change the selected formation, the selected formation and its whole descendant tree, only its descendants, or the formations with the same original template at the same population. A formation without a population takes no part in the same-template change. Switching to Front Line Attack resets own-element fortification to 1. The only-descendants choice leaves the selected formation’s position unchanged, but the fortification reset to 1 still applies when the selected formation’s own position is already Front Line Attack. The change through descendants has no location filter. Blueprint field position and live field position stay separate until creation.

Available troop transport capacity is the ship’s undamaged troop transport component capacity, without commander bonus and cut to a whole number, minus the whole-number total size of all formations already aboard that ship. Formations load whole. The available capacity must be above 0 and at least the formation’s exact own size. A hierarchy can spread across ships because its children load as separate formations.

Loading a formation into a fleet’s transports (Load Ground Unit or Load Ground Unit from Stationary Fleet) requires at least one ship of the fleet with an undamaged troop transport. The selected formation must still exist. With the sub-units option, the game builds a list with descendants first and the selected parent last. Each formation tries the transports in list order. The first formation that fits no ship stops all later loading. Earlier successful loads are not undone. Load Assigned Ground Templates instead looks for formations at the order’s population whose original template matches each template assigned to the ship class. It tries the assigned number per transport.

When the game gathers a formation and its descendants, it can restrict the gathering to one population or to one ship. The population restriction never takes effect, because the ship-restricted or unrestricted list of children replaces it. Descendants at other populations are therefore still included. A ship restriction does limit each step down to the direct children, and the selected formation itself is always included.

A successful load puts the formation aboard the carrier, clears its population, resets element fortification to 1, and keeps its parent, support target and templates. Loading from a stationary fleet checks that the formation’s ship belongs to the order’s target fleet. Loading at a colony checks that the formation is at exactly the order’s population. The load reports success once capacity suffices, even when neither location test matched, so the order can report success without moving the formation. No separate species or race check applies. Parent bonus inheritance stops while the parent has no population. The hierarchy’s tonnage can still burden the parent’s capacity.

Unload Ground Unit and Orbital Drop Ground Unit unload specified formations. Each candidate must be aboard the executing ship before the game clears its ship and sets its population to the order’s population. Unload All Ground Units from Transport Bay and Orbital Drop All Ground Units visit every formation aboard. Both kinds reset fortification and keep parent, support and template links, and neither updates the commander’s location. The combat-drop record of the specified unload tests for Orbital Drop All Ground Units on both sides of its condition and never for Orbital Drop Ground Unit. A single-formation orbital drop is therefore not recorded as a Combat Drop - Formation or Combat Drop - Transport measurement. Where measurements come from covers the effect on medals.

A formation aboard a parasite ship stays linked to that ship, while its physical location is the location of the ship’s fleet or mothership. The Order of Battle grouped by location labels carried parasite ship nodes with their mothership’s name in brackets. Parent links are not rewritten when a carrier docks or launches a parasite. Cargo countdowns and order completion rules are in troop formations.

Transfers replacements and removal

Section titled “Transfers replacements and removal”
Operation Relationship behaviour
Moving a formation tree to a population Sets the population and clears the ship for the whole descendant tree. Keeps parents, templates and support links
Transferring control to a population Clears the commander, changes race and population, maps the required rank to the new race’s rank with the same Priority, and clears its own support target, current combat target and original and replacement templates. It can repeat for the children. It does not clear the ship or its own parent
Moving units from an element Moves units by class. An existing receiving element keeps its species. A new element copies the species, morale, supply and fortification of the giving element. Formation parent links stay
Absorbing a formation Merges class and count elements, then removes the absorbed formation. It does not detach or reparent that formation’s children or clear its commander
Delete Formation and Scrap Formation buttons Clear the commander, detach direct children to roots, and remove the selected formation. Scrapping also recovers resources
Destroying a formation Retires the commander as killed or clears the assignment, then removes the formation. It does not detach the formation’s children

Moving a formation tree to a population makes no location or race check of its own. Dragging a formation onto a population on the Order of Battle tab allows only a formation at a population on the same body, unless Spacemaster mode is active. Dragging an element onto a population to create a new formation follows the same rule. Dragging an element onto another formation reads both populations directly and checks that they share a body. A formation aboard a ship, or with no location, makes that drag end with error Function #1859. Spacemaster interventions covers the Spacemaster overrides. Colony conquest and control transfer covers the main use of control transfer.

A merge into an element of the same class sets morale to (receiving morale x receiving units + giving morale x moved units) / (receiving units + moved units), rounded down. Supply steps use the same weighted average, rounded down. No species compatibility condition applies. Whole absorption creates a new element for each unmatched class and copies its fortification, while a matching receiving element keeps its own fortification. Moving units removes an emptied giving element but does not remove an empty formation.

Delete Formation and Scrap Formation explicitly detach direct children. Deeper descendants stay under those children. Scrapping is allowed only for a formation at a population. Destruction of a formation and removal of combat losses are different paths. A parent link to a removed formation can therefore remain until a cleanup on that path or a reload.

Replacement manufacture adds units to the existing formation. It does not rebuild the command tree. The Copy + Upgrade button of the Formation Templates tab points the replacement template of the race’s formations that used the copied template, and the blueprint nodes that used it, at the new template. It leaves current live element designs and parents unchanged. Reinforcement from existing units prefers the same unit series and population and uses the element unit move above, so the formation hierarchy stays. Replacement manufacture and existing-unit reinforcement covers charges, priorities and shortage behaviour.

Organisation supply chains

Section titled “Organisation supply chains”

An element’s supply chain starts with its own formation at depth 1 and then follows the parent links upward with increasing depth. Supply consumers visit the greatest depth first, which gives the highest HQ ancestors the first opportunity. Leaf formations directly below those chain members whose role is ground logistics can also supply. The consumer’s own formation is never used as such a leaf. A leaf here has no subordinate formations anywhere in the game. The logistics role comes from the role classification above, not from a separate permanent flag.

Actual consumption of logistics units requires the donor and the consumer to be at the same population. A donor other than the consumer may use only Light Vehicle elements with positive logistics points. A formation supplying itself may use logistics elements of any base type. Choosing a donor applies no race or species check. A parent at another location stays in the chain, but its units cannot pass the same-population test. The support target plays no part in building this chain.

Supply is stored partly as ten internal element steps (CurrentSupply) and partly as logistics-unit counts that are consumed. A demand of 0 or less succeeds at once and consumes nothing. Donor elements are tried by descending unit count. An element is used only when logistics points per unit x units covers the remaining demand, where its logistics points per unit are the sum of DIM_GroundComponentType.LogisticsPoints over its components. When the demand exceeds one unit’s points, the game spends floor(demand / points per unit) whole units and takes their points off the demand. A d1000 roll at or below (remaining demand / points per unit) x 1000 then spends one more unit. The search does not stop after a successful element, and the remaining demand is not cleared after that roll, so several qualifying donor elements can be consumed. Emptied elements are removed.

In combat, a success at a leaf logistics formation is replaced by the chain formation’s own supply attempt that follows it, so the leaf result can be overwritten. When combat supply succeeds with internal supply below 10, the element also tries a full refill from the chain formations, without their leaf children, for unit supply cost x units x (10 - current supply) x 0.1. The construction-cycle refill runs for elements below full supply in formations at a population. It uses the same demand, except that when the formation has a commander the demand is multiplied by Logistics bonus - 2, using the commander’s own Logistics bonus value (not Ground Combat Logistics), and the product is rounded to one decimal (an exact half goes to the even neighbour). Because a commander’s Logistics bonus is capped at 1.5 (DIM_CommanderBonusType.MaximumBonus), that multiplied demand is always 0 or less, so the construction-cycle refill of a commanded formation succeeds without consuming any logistics points. It also tries the leaf logistics formations of each chain member. The combat refill applies no commander multiplier. These rules can matter when a chain contains several logistics donors. Supply, fortification and recovery states the combat demand and the logistics waiver, and upkeep, supply and recovery has the full resource and refill accounting.

Displays and persistence

Section titled “Displays and persistence”

View structure is not hierarchy mutation

Section titled “View structure is not hierarchy mutation”

Without location grouping, the Order of Battle roots are the race’s formations without a parent. They sort by HQ capacity descending, abbreviation, then name. With Sort Creation ticked, the formation ID replaces the name after the first two keys. Children sort by HQ capacity descending, abbreviation, then name. With Location ticked, systems sort by the race’s system name, populations by name and transport ships by display name. Formations whose parents are at other populations or ships appear as local roots, and their stored parent is not cleared. Shipboard trees likewise include formations whose parents are elsewhere.

On the Organizations tab, blueprint roots that have a template and no parent appear in a separate preview tree. Roots without a template and without a parent appear in the organisation hierarchy tree. Roots and children both sort by OrganizationName, even when the shown label comes from the template name.

Formation labels can show “(FA)”, “(SP)” or “(RE)” for field position, a replacement priority other than the default 10 as “(P” followed by the priority and “)”, “(A)” for active sensors, “(DNR)” for Do Not Recover, and an arrow (“—>”) to the support target. A summary that includes child formations gathers the descendant elements recursively. Location filtering then keeps only those at exactly the same population or ship. The summary’s HQ maximum can come from those descendants and is not the own HQ capacity that attachment and command checks use. Displayed state and refresh covers when such views are rebuilt.

Save/load reconstruction

Section titled “Save/load reconstruction”
Table Core identities and links
FCT_GroundUnitFormation FormationID, RaceID, OriginalTemplateID and ReplacementTemplateID, PopulationID and ShipID, ParentFormationID, AssignedFormationID, RequiredRank, OrgLinkID, and field position, boarding, sensor and replacement flags
FCT_GroundUnitFormationElement ElementID, FormationID, ClassID, SpeciesID, units, morale, fortification, supply and targeting. A live element’s TemplateID is saved as 0
FCT_GroundUnitFormationElementTemplates FormationTemplateID, ClassID and Units. Template elements have no saved individual ElementID
FCT_GroundUnitFormationTemplate Template ID, name, abbreviation, race, rank and related template state
FCT_OrganizationNode OrganizationID, RaceID, ParentOrganizationID, FormationTemplateID, name, FieldPosition and NodeExpanded
FCT_GroundUnitTraining and FCT_GroundUnitTrainingQueue ParentLinkID and OrganizationLinkID, with the template and population links that rebuild queued creation attachment
FCT_Commander command record CommandType 5 (Ground Force Commander) and the formation as CommandID. The link back from the formation to its commander is restored separately

A save writes parent and support IDs from the current links. Loading creates the formations, binds the rank, templates and locations that still exist, and keeps a row when its saved ShipID or PopulationID is not 0. A second pass then resolves parents and support targets. A non-zero saved location ID keeps a formation even when that location no longer exists. A row with both IDs 0 is not loaded. A missing parent or support target becomes no link, while the numeric saved ID stays on the formation. Loading does not recheck HQ order, capacity, race or species compatibility, or cycles. Relationship IDs and lookup behaviour covers the general reload rules.

Actual elements load only with an existing formation, class and species. Template elements load from their separate table. Missing original or replacement templates leave those links empty. The organisation link (OrgLinkID) is stored separately from the parent FormationID, so it is not what links a formation to its parent after a reload.

Organisation node loading accepts nodes of an existing race and binds the template when it exists. It then resolves ParentOrganizationID against the combined node list of all races. A missing parent becomes no parent, and a missing template stays empty. Such a node can move to a different root or preview category. Reconstruction applies no cycle or race check. Commander loading sets the commander’s formation command and the formation’s commander when the command ID exists. A missing formation sets the commander’s CommandType to 0 (none).

Worked examples and mechanics caveats

Section titled “Worked examples and mechanics caveats”
  • One HQ is enough to keep the full rating: ten HQ units of a class with capacity 25000 and one surviving HQ unit of that same class both give H = 25000. The capacity disappears when that class element is actually removed, not in proportion to casualties.
  • Attach versus support: a formation with HQ 5000 dragged onto a target with HQ 25000 at the same population becomes a child. A formation with HQ 25000 dragged onto a target with HQ 25000 is not a parent attachment. It can only become support if the superior or leaf rules qualify.
  • Overload suppresses the bonus excess: a raw own bonus of 1.2 with c = 0 gives an adjusted own multiplier of 1. A parent at the same population with raw bonus 1.4 and capacity modifier 1 contributes 1 + 0.4 x 0.25 x 1 = 1.1. A commanded child with own 1.2 under that parent receives 1.2 x 1.1 = 1.32. A child without a commander keeps the default 1 in combat preparation.
  • Transport keeps the tree but interrupts inheritance: with the parent at Colony A and the child aboard Transport B, the child keeps its parent link and remains part of the parent’s total command size. The different or missing population blocks inherited bonuses and same-population supply.
  • A grouping node changes queued attachment: for a blueprint of real HQ, then a grouping node without a template, then a battalion, instant creation keeps the HQ as the battalion’s parent. The queued battalion receives ParentLinkID 0 through the grouping node.
  • Copied template elements share lists with the original: Copy + Upgrade, and the template copies made for a newly independent race, copy each template element shallowly and then clear its attack report, STO recharge and detecting-race lists. Those lists are shared with the original element, so the original’s lists are cleared too. The race the copy is made for plays no part in the element copy. This differs from the fresh elements made when a formation is created from a template.

Concept map

Section titled “Concept map”

Resources

Section titled “Resources”

Related community documentation and developer posts. These may describe a different game version.