Movement and logistics

Coordinates clocks and movement dispatch

A fleet’s stored speed, a hull’s effective maximum speed, the position of an orbiting body and the time stamp of a contact are separate pieces of state. A transfer’s stock limit, its rate allowance, the unused time it hands back and the completion of its order are also separate results. The formulas on this page keep those distinctions and do not assume one universal movement or loading rule. Where this page says a value is cut to a whole number, the fraction is dropped toward zero. Where it says a value is rounded, an exact half goes to the even neighbour.

Unit or stored value	Meaning
Coordinates, distance, speed	Kilometres and km/s. Mkm is 1,000,000 km and a billion km is 1,000 Mkm.
AU	149,600,000 km. Used for the orbital radius of every body that is not a moon and for the stored Distance of a Lagrange point.
HS and tons	One hull space (HS) is 50 tons. A jump drive’s ComponentValue limits the escorted hull in HS. Cargo mass uses tons.
Game day, month and year	86,400, 2,592,000 and 31,536,000 seconds. The month is 30 days, so twelve months are 360 days, not the 365-day year.
Sub-pulse length (SubPulseLength in FCT_Game)	The seconds budget of one movement and logistics pass. An operation can hand back part of it for the next order.
FCT_SystemBody.Year and FCT_Star.OrbitalPeriod	A body’s orbital period in hours, and a star’s orbital period in years. Neither is a fleet travel time.
Fuel, MSP and ordnance	Litres, maintenance supply points, and whole missile counts whose Size uses transfer and storage points. Moving n missiles spends n x missile size in transfer points. Missile-size points are distinct from maintenance MSP.

The OrbitalDistance of a body that is not a moon is in AU, and that of a moon is in kilometres. The two period values in the table are not interchangeable.

The main orbital update runs once per construction cycle. It moves bodies by all the seconds that have built up since the previous cycle. It is not an orbital step for each fleet sub-pulse. Fleet move orders and anchored formation movement run every sub-pulse. Conditional orders are checked before movement starts for a time increment. Standing orders run after the increment only when the increment lasted more than 60 seconds. Idle civilian freighters receive new freight assignments only when the increment lasted more than 3600 seconds. Both thresholds are strict, so an increment of exactly 60 or exactly 3600 seconds does not qualify.

Automatic and movement-step supply calls

The automatic supply phases run only for fleets that have no queued move orders. In each sub-pulse they run before movement orders, in this sequence:

1. Tanker fuel.
2. Parasite fuel.
3. Parasite MSP.
4. Fleet MSP.
5. Collier ordnance.
6. Parasite ordnance.

The game removes duplicate fleets from the tanker, supply ship and collier lists after it picks the fleets. The two parasite phases count each ship once and then take its fleet, so a fleet with several qualifying parasites is handled once per parasite. A fleet with several qualifying parasites can therefore run the whole fleet refill several times in one sub-pulse. This multiplies the work on top of the budget for each parasite. Moving and anchored fleets also run the fleet replenishment steps with the length of their movement interval, as described under order scheduling.

After each processed move order, five replenishment steps receive the seconds spent on that order. They run as tanker fuel, parasite fuel, fleet MSP, parasite MSP and collier ordnance. When an anchored fleet reaches its formation position, it runs the same five steps with the full sub-pulse length. Neither of these includes the separate carrier ordnance step. Each repeated run resets the markers that record which recipients already received fuel or supplies in the pass. One of these runs is therefore not necessarily the whole game sub-pulse.

Propulsion speed fuel and nebula limits

Physical travel burns fuel according to engine power and hours of movement. Crossing a jump point changes the system and the coordinates directly once the fleet reaches it. Navigation treats docked parasites (ships aboard a mothership) and ships held by a tractor beam separately from the hulls that propel the fleet.

Effective ship and fleet speed

A ship’s effective maximum speed is worked out as follows:

• available thrust = undamaged engine capacity x OverhaulFactor
• effective mass = class Size, in HS
• when the ship tows another ship, add the towed ship’s class Size
• otherwise, when it tows a shipyard, add shipyard capacity / 25 x number of slipways
• maximum speed = whole-number(1000 x available thrust / effective mass) km/s, kept between 1 and 270,000

Undamaged engine capacity is sum of undamaged engine count x ComponentValue over the engines. Commander bonuses are not applied to it. A ship gets 1 km/s when it is held by a tractor beam, when it is under maintenance, when its thrust is zero or less, or when it belongs to a player race and its Fuel is exactly 0. Zero fuel does not trigger this fallback for NPRs. Crew grade, morale and commander or rank bonuses do not multiply this propulsion formula. Overhaul condition (OverhaulFactor) does.

A fleet’s maximum speed is the slowest effective maximum among its independent ships that are not under tow. It is 1 when no such ship exists. Docked parasites and towed hulls do not limit it directly. Towing mass slows the tug instead. Cargo in the hull and the mass of docked parasites do not count toward the effective mass.

A speed the player sets is limited to the fleet maximum and then raised to at least 1. Setting maximum speed copies the current computed maximum. When UseMaximumSpeed is on, the movement step recomputes the maximum at the start of the fleet’s pass. When it is off, travel keeps the stored speed, apart from the dust cap. A speed chosen earlier by hand is not checked again there against a maximum that damage or fuel has lowered. Fleets with any ship under maintenance are left out of order processing altogether.

Fuel burn and shortage-limited motion

The travel fuel step counts only the ships of the fleet that are neither docked nor under tow. For each powered hull:

• E = undamaged engine capacity, without the overhaul multiplier
• Vmax = effective maximum speed of the ship
• current engine power = E x fleet speed / Vmax
• requested fuel = current engine power x class FuelEfficiency x requested seconds / 3600

For each player hull that lacks the requested fuel:

• fuel-limited seconds = requested seconds x hull fuel / requested fuel for that hull
• available fleet seconds = min(requested seconds, fuel-limited seconds of every player hull)

When a hull lowers the available time, the game logs an event that the ship has insufficient fuel to complete the orders of its parent fleet. Every included hull is then charged current engine power x FuelEfficiency x available fleet seconds / 3600. Fuel that would fall below zero is set to zero. Exactly sufficient fuel allows the full requested movement. A ship without engine capacity is skipped when power and limits are worked out, but the final charge still uses the engine power value it last stored. The step does not pool fleet fuel and does not move tanker fuel automatically.

The charge uses raw undamaged engine power, while effective maximum speed includes OverhaulFactor and towing mass. Overhaul and towing therefore change the share of power needed to hold a chosen speed. This is not a fixed design fuel rate. Lowering the speed lowers the power linearly here. Docked parasites and towed ships burn no movement fuel of their own.

NPR hulls never shorten movement because of missing fuel, although the game still charges their fuel and stops it at zero. Shipping-line fleets and the Swarm skip the travel fuel step entirely, in ordinary and in anchored movement. NPR maximum speed also ignores empty tanks. These are deliberate differences in how movement runs, not estimates taken from displayed endurance.

The movement step limits the planned distance to fleet speed x remaining sub-pulse seconds, or to the distance to the destination when that is smaller. Arrival time scales the same way. When fuel shortens the time, the distance is scaled by available seconds / requested seconds. The fleet stops at that intermediate point and uses up the rest of the pass. For player races the game logs that the fleet cannot complete its current order due to a fuel shortage. Partial travel also ends the pass. On full arrival, the travel time is cut to whole seconds before it is subtracted from the remaining sub-pulse seconds, so the fleet keeps a fractional-second benefit. Distances below 1 km count as zero.

Displayed endurance is an estimate

The displayed fuel range of a ship uses undamaged engine power x OverhaulFactor, or 1 when that product is zero. It computes the design-mass speed as whole-number(1000 x effective engine power / class Size), caps it at 270,000, and then returns:

• range = Fuel / (effective engine power x class FuelEfficiency) x calculated speed x 3600 km

This estimate leaves out towing mass and dust limits. The fleet’s displayed range is the minimum across all its ships, carried and towed hulls included, unlike the fuel limit applied during travel. The displayed range can therefore differ from the distance the fleet can actually travel.

Nebula/dust speed caps and entering a new system

In ordinary order movement and in anchored formation movement, a system with a positive DustDensity (in FCT_System) applies this cap:

• dust-safe speed = minimum fleet armour thickness x 2500 / DustDensity
• when the dust-safe speed is below the fleet speed, the fleet speed becomes whole-number(dust-safe speed)

The armour minimum scans every ship in the fleet, parasites and towed ships included, and uses each class ArmourThickness. The conversion drops the fraction, and no minimum of 1 follows. Zero armour, or a cap below 1, can therefore set the fleet speed to zero instead of the general propulsion fallback of 1. This speed cap deals no dust damage.

This is a travel-time cap that uses the fleet’s current system. A jump transit does not recompute it. After arrival in another system, the next movement leg uses the destination system’s density. UseMaximumSpeed can restore propulsion speed at the next fleet pass before the local dust cap applies. With maximum-speed mode off, the cap only lowers the stored speed and does not raise it again after the fleet leaves the dust. The stored MaxNebulaSpeed in FCT_Fleet plays no part in these movement rules.

Body star and moon motion

Periods and position approximation

When a body’s environment and orbit are recalculated, the orbital period in hours of a body that is not a moon is:

• Year = sqrt(orbital distance³ / star mass) x 8760, with the distance in AU and the star mass in solar masses

For moons:

• Year = sqrt((orbital distance / 398600)³ x 837 / (moon mass + parent mass)) x 24, with the distance in km and the masses in Earth masses

A computed period of zero becomes 1 hour. A secondary star’s orbital period is sqrt(distance³ / (own solar mass + parent solar mass)) years, with the distance in AU. When a secondary star is set up with a random starting bearing, an orbital distance of zero is first moved out to 0.1 AU and the bearing is a d360 roll.

For an ellipse with semimajor axis a and eccentricity e:

• periapsis = a(1 - e)
• apoapsis = a(1 + e)
• semiminor axis b = a x sqrt(1 - e²)

The game advances a bearing measured from the ellipse centre and rebuilds a point on the ellipse. It does not solve Kepler’s equation and does not integrate gravitational acceleration. The normalised speed values are mean = sqrt(1/a) and current = sqrt(2/r - 1/a), where r is the current distance from the focus. They act as a dimensionless ratio, not as physical km/s. For bodies with nonzero eccentricity the bearing decrease per update is:

• 360 x elapsed seconds / (Year x 3600) x current / mean, with Year in hours

Circular bodies use a ratio of 1. Stars with a Component number above 1 use the same ratio, with their OrbitalPeriod in years converted at 31,536,000 seconds per year. Component 1 has its mean and current orbital speeds reset to 0. Stars update in ascending Component order, so a parent star’s coordinates are updated before later components. A negative bearing gains 360 repeatedly until it is no longer negative. The orbital update does not repeatedly reduce large positive bearings.

The radius R from the ellipse centre at bearing B is b at bearings 0 and 180, and a at bearings 90 and 270. At any other bearing, with the normalised angle A = (450 - B) degrees, R = a x b / sqrt((b cos A)² + (a sin A)²). The coordinate angle is B - 90. A circular primary body sits at star position + a x km per AU x (cosine, sine) of coordinate angle. An eccentric body offsets the ellipse centre by a x e from the star at the focus, rotates that centre by EccentricityDirection, and rotates the coordinate angle by the same orientation. A moon with a parent body and no Trojan offset uses a circular radius in kilometres centred on its parent, whatever its eccentricity.

Which bodies move

The whole orbital update does nothing when the game option for planet and moon orbital motion (OrbitalMotion in FCT_Game) is 0, unless the update is forced. In the normal update:

Object	Movement rule
Planets and comets	Every object that is not a fixed body (FixedBody) updates, with the eccentric speed ratio where it applies
Independent asteroids	Update only when TrojanAsteroid is 0 and the asteroid orbital motion option (OrbitalMotionAst in FCT_Game) is 1, or when the update is forced
Moons	Update after their parent bodies. Bearing decrease is 360 x elapsed seconds / (Year x 3600), without the eccentric speed ratio
Trojan asteroids	Bearing becomes parent bearing + TrojanAsteroid offset, then the coordinates are rebuilt. The independent-asteroid option does not gate them
Fixed bodies with a fixed-body parent (FixedBodyParentID)	Copy the parent’s X and Y, bearing, base temperature and distance to the parent

The first planet and comet list excludes fixed bodies. The separate moon and Trojan lists do not repeat that exclusion. Fixed-body copies happen afterwards. The game also runs a single-body refresh when a body’s orbit decays (see system disasters). That refresh updates the body directly and then its moons and Trojans. Its fixed-body copy step still covers every linked fixed body in the game.

When an eccentric body updates, the game also recomputes its base temperature as max(4, 255 / sqrt(distance / sqrt(star luminosity))), with the distance in AU. It then refreshes the body’s hydrosphere, atmosphere and dominant terrain. Eccentric Trojan asteroids recompute their base temperature the same way. Moons of an eccentric parent take the parent’s base temperature and refresh the same environment parts. A changing orbital position therefore matters for colony conditions as well as for travel distances.

Lagrange point creation and motion

Generation, construction and position

System generation gives a natural Lagrange point to every generated superjovian and to every generated gas giant with a mass strictly greater than 200 Earth masses. The imported Sol system gives Jupiter one explicitly. Creating a point directly does not itself check mass, uniqueness or body type.

The movement window offers the Stabilise Lagrange Point order only when the fleet has a jump point stabiliser, the destination is a system body with a mass of at least 0.25 Earth masses, the body is a planet or a moon, and no Lagrange point is already tied to that body.

Stabilisation time uses the fastest usable stabiliser ship. It does not add ships or modules together:

• base seconds = 60 / sqrt(anchor body mass) x 2,592,000, with the mass in Earth masses and 2,592,000 seconds per month

When commander bonuses apply and the ship has a commander, the time is multiplied by 2 - commander Production bonus. When the ship’s current crew is below its class crew, the time is multiplied by class crew / current crew. The result is the smallest time across stabiliser ships, cut to whole seconds. Without any undamaged stabiliser the time is 0. Arrival stores this time. The arrived order checks the capability again and builds the point once the countdown finishes with positive time left over. No minerals and no wealth are charged in this order.

A new point starts at body bearing + 60 degrees. A point created by a stabilisation order adds another 90, which gives body bearing + 150. The game subtracts 360 once when needed. A planet point stores the planet’s semimajor radius in AU as its Distance. A moon point stores the moon’s radius in kilometres converted to AU. The first position uses circular polar geometry at that distance, around the star for a planet and around the parent body for a moon. The system’s Lagrange points are then renumbered. On every later orbital update each point resets to body bearing + 60 and uses its own orbital geometry, including eccentric planet geometry or a moon’s circular geometry around its parent. A player-stabilised point therefore loses its extra 90-degree offset at the first later orbital update, and an eccentric starting position is rebuilt with the ellipse approximation.

Fleet arrival and following

An Intra-system Jump order travels to its entry point (DestinationID) and then moves instantly to its exit point (DestinationItemID). Completing it sets the fleet’s current, previous and increment-start coordinates to the exit coordinates, records LastMoveTime, and resets the increment-start positions of contacts on the fleet. It does not create an orbit link or an ongoing tie to the Lagrange point. A completed move to a Lagrange point likewise sets no follow link when the order ties the fleet to its population and body. A fleet left at a point’s old coordinate therefore does not follow the point just because it arrived there. A movement order that is still running uses the point’s latest coordinate each time it is evaluated.

Automatic insertion of Lagrange point legs belongs to route planning. When an order is queued, the game may insert an entry and exit leg if the distance with that leg is strictly shorter than direct travel. The point’s later movement and the order’s stored IDs are separate from that distance snapshot.

Anchoring fleets parasites and contact positions

A population’s map position is the current coordinate of its system body, or 0 when it has no body. A population has no movement of its own.

When a fleet starts an order it has not yet reached, the game clears its assigned population and orbit body and flags the fleet as moving. On arrival at a system body or a deep-space population with a MinDistance of 0, the game sets the orbit body. A population named on the order becomes the assigned population. Arriving at a waypoint tied to a body can also set the orbit body. Many cargo and replenishment actions explicitly tie the fleet to the order’s population and body. Fleet destinations take over the target fleet’s orbit body.

Before orbital motion, the game gathers the fleets that have an orbit body and keeps only those whose X and Y are exactly equal to the body’s old X and Y. After the bodies move, it resets the current, previous and increment-start coordinates of those fleets. With an OrbitDistance of 0 they go to the new body coordinates. Otherwise they go to a fixed polar offset given by OrbitDistance and OrbitBearing. Because of the exact-equality filter, a fleet that already sits at a nonzero offset is normally left out of later following, even though an offset reposition rule exists. These repositionings do not use normal fuel-burning travel and do not update LastMoveTime. Stationary replenishment rules that test LastMoveTime therefore do not react to changed orbital coordinates.

The Extended Orbit action first targets body Y coordinate - order OrbDistance. It does not integrate a separate satellite orbit around the body. The stored orbit distance and bearing and the coordinate-follow eligibility above are separate matters.

Missile salvos, waypoints and wrecks tied to an orbit move to their body’s coordinates. Ship, salvo and population contacts tied to orbiting objects are relocated by the orbital update too, without advancing their LastUpdate. Ship contacts do not repeat the fleet’s exact-equality filter. A contact’s coordinate can therefore be recalculated even when the fleet itself was not repositioned. In a single-body refresh, salvo and population contacts are selected by a system test that cannot match, so they are normally not moved by that refresh.

Docked parasites share their mothership’s fleet. Landing records the mothership and moves the ship into the destination fleet, rather than giving it a second free-flying orbital position. Landing on an assigned mothership then overwrites the copied sub-fleet with the new landing sub-fleet. That new sub-fleet exists only for the Land on Assigned Mothership as Sub-Fleet order, so other assigned-mothership landings leave the ship without a sub-fleet. Only specified-mothership and squadron landings keep the copied sub-fleet aligned. A docked ship’s location comes from the containing fleet until it detaches.

Anchored fleet formation movement

Anchored formation movement runs after ordinary move orders. It selects fleets with an anchor fleet (AnchorFleetID) whose LastMoveTime is no later than the start of the sub-pulse. It clears references to anchors or threat records that no longer exist and skips anchors in a different system. It picks a formation reference in this order:

1. The specific detected threat (SpecificThreatID), when its contact is current.
2. The nearest current hostile known warship, when GuardNearestKnownWarship is set.
3. The nearest current hostile ship, when GuardNearestHostileContact is set.
4. The anchor’s first move-order destination, when UseAnchorDestination is set.

A contact is current when its LastUpdate equals the start of the sub-pulse.

With a nonzero reference position, the desired bearing is bearing from anchor to reference - 180 + AnchorFleetBearingOffset. The desired position lies on that bearing at AnchorFleetDistance from the anchor. A zero reference position defaults to the anchor’s coordinates. This is real fleet travel, subject to maximum speed, dust and fuel limits, not an instant copy of the anchor’s coordinates. It clears the fleet’s population and body ties. When the fleet reaches its formation position, it runs fleet replenishment with a full sub-pulse length.

Destinations interception and route planning

A contact has a game-wide unique UniqueID. A move order with the Contact destination type stores that value in DestinationID. ContactID identifies the actual ship, population or salvo and is not the key that movement uses. A contact holds its coordinates, previous coordinates, increment-start coordinates, speed and time stamps. The observation and knowledge lifecycle covers how contacts arise and age.

When a race detects a ship, its contact record stores the fleet’s coordinates and speed. A record last updated exactly one sub-pulse earlier (current game time - sub-pulse length) counts as continuous. It adds that many seconds to ContinualContactTime. If the contact is still in the same system, its stored X and Y become the previous coordinates. Otherwise the continuous time resets, Reestablished is set and the increment-start position is reset. The record then takes the new X and Y, LastUpdate and system. Stale contacts are not moved by dead reckoning in this update. Contact snapshots and the projection of actual fleets are separate.

The destination lookup maps each destination type to a coordinate:

DestinationType	Destination	Coordinate taken from
1	Jump point	The jump point with that ID, or a supplied override position when the ID exists
2	System body	The system body with that ID. The ID is a body ID, and the population is stored separately on the order
15	Deep-space population	The system body with that ID. The ID is a body ID, and the population is stored separately on the order
4	Survey location	The survey location with that ID in the given system
5	Waypoint	The waypoint with that ID
6	Contact	The contact with that UniqueID, subject to the required last-update time
7	Lifepod	The lifepod with that ID
8	Wreck	The wreck with that ID
10	Fleet	The fleet with that ID, projected when it is moving and a pursuing fleet is supplied
12	Lagrange point	The Lagrange point with that ID
14	Aether gate	The Aether gate with that ID

For contact destinations, a missing ID leaves the default position (0,0). So does a LastUpdate older than the required time, when a requirement is set. A ship contact chased by a pursuing fleet projects the actual target fleet when it is in the same system. Other contact cases use the stored X and Y. A ship contact in a different system from the pursuing fleet is unresolved. Ordinary order execution requires the contact to have been updated at the start of the current sub-pulse. Fleet destinations get an explicit check for a missing fleet or a fleet in another system before the lookup. Route planning resolves a destination without a pursuing fleet and without a freshness requirement, so it accepts a stale stored contact position.

The movement step treats (0,0) as unresolved. It logs that the destination of the fleet cannot be found, asks for new orders and clears all move orders. A genuine target at the system origin is therefore mistaken for an unresolved destination. When MinDistance is above 0 and the projection has not already applied it, the game computes a point that far short of the target. When the fleet and the target have identical coordinates, the target first gains 100 km on each axis to give a direction. Distances below 1 km count as zero.

When a contact track is lost, the game moves Contact orders from its UniqueID to a current track of the same actual ship seen by the same observer, when one exists. Without a current alternative, NPR observers can create point-of-interest or urgent point-of-interest search waypoints at the last location and at reachable known jump points. The reach is class MaxSpeed x seconds since the lost contact's last update. If any Lagrange point in the system lies within that reach, the NPR creates waypoints at all Lagrange points of the system. Player observers skip this search.

Contact lookups by age accept a LastUpdate at or after current game time - maximum age, equality included. Expired contacts are removed only when LastUpdate is older than current game time - 31,536,000 seconds (one year). A retained stale contact is therefore not the same as a currently usable follow destination.

Interception projection

The projected position of a fleet serves moving-fleet destinations and the pursuit of current ship contacts. The interceptor can be a fleet or a missile salvo. If the target has not moved this sub-pulse, the game uses its current position, shortened by the minimum distance when one is set. Otherwise, while the separation is larger than the minimum range, it samples a constant-heading extrapolation based on the target’s actual current and previous positions and its stored speed. It does not simulate the target’s future order queue or fuel.

For initial separation D, interceptor speed Vi, target speed Vt, minimum range M and sub-pulse length P, the sample step is max(D / Vi / 100, P). For each sample i from 1 to 199:

• t = i x step
• target distance = Vt x (t - P)
• interceptor reach = Vi x t + M
• candidate = the target’s current position advanced along its inferred heading by the target distance

The game returns the first candidate within the interceptor’s reach. While candidates stay out of reach, it keeps a candidate only while the remaining separation improves, and returns the previous best as soon as improvement stops. After all samples it returns the best kept point. Some projections mark the minimum distance as already applied, so the movement step does not shorten the target twice. This numerical sampling is an approximation, not an exact intercept solution.

Inter-system auto-routing

The reachable-system search and the danger test behind auto-routing are in route planning and danger.

The nearest auto-route destination search is breadth-first across explored linked systems. It finds the first eligible destination by jump depth and listing order, not the shortest total fuel, time or distance. Each link requires the viewing race’s Explored value of 1 (in FCT_RaceJumpPointSurvey) and a linked jump point. When ungated routes are excluded, the search requires a gate only on the departure side. Systems marked NoAutoRoute are left out when requested.

The route search applies AvoidDanger, the player’s AvoidAlienSystems, the shipping-line filters for military and restricted neighbouring systems, and the NPR destination rules where they apply. See system danger ratings and route avoidance. An option to include unstabilised jump points overrides the planner’s onboard-drive check. It does not bypass the transit checks made at the moment of the jump. Queuing a route to a system turns the stored path into Standard Transit orders, updates the departure and destination survey record of each leg, and can clear the existing queue first.

Automatic Lagrange-point shortcut selection

When an order is queued, the game can insert an Intra-system Jump before it. This happens when automatic Lagrange point routing (AutoLP) is on, the requested destination is not itself a Lagrange point, and the starting system has at least two Lagrange points. The game starts from the end point of the queue so far and compares the direct distance against every distinct entry and exit pair:

• candidate travel = distance(queue end point, entry point) + distance(exit point, destination) km

It picks a pair only when the candidate is strictly shorter, counting the jump between the two points as zero distance. Ties keep the earlier choice or the direct route. The inserted order stores the entry point as DestinationID and the exit point as DestinationItemID. This is geometry at queue time with current positions. The route is not optimised again as the bodies move.

Completing an intra-system jump moves the fleet to the exit point, resets its previous and increment-start coordinates and the contact start positions, and records LastMoveTime. It applies no intersystem jump shock. The fleet pays approach fuel and time to the entry point, and the jump leg itself charges no fuel in this step.

Jump modes drives gates and shock

Drive ratings and usable components

For each ship, the game takes the first undamaged jump drive in its class design. When special drives are excluded, only drives with no special function (SpecialFunction) qualify, which rules out commercial drives. When special drives are allowed, any jump drive qualifies. The game does not pick the best drive on that ship. Fleet checks then compare the drive found for each eligible ship.

A jump drive design stores the largest hull it can escort in ComponentValue (HS), the squadron size in JumpRating (a whole number) and the scatter radius in JumpDistance (a whole number). These come from the design capacity and the researched squadron size and squadron radius technologies. Commanders and ranks do not adjust them at transit time. A commercial drive multiplies the designed ship size by 5 and carries the commercial jump drive special function. The Swarm adds 3 to the designed squadron size.

Common jump-shock gate

How a jump gate is built, and which end it covers, is in jump gate construction.

Transit validation first rejects the jump if any independent ship has a SensorDelay above 0. It logs that the fleet cannot conduct a transit because one or more ships suffer from jump shock. Independent means not docked in a mothership, so towed ships are in this group. The rejection comes before the jump gate check, so a gated departure point does not bypass existing jump shock. Docked parasites are left out of this test but receive the new shock afterwards.

Standard transit and available drive coverage

For Standard Transit and Transit and Divide Fleet, a departure jump point with a JumpGateStrength above 0 is enough for the check to succeed. The check does not compare hull size with gate strength, look at the gate owner, require a gate on the linked side, or use up any gate resource. One direction can therefore be gated while the return direction is not.

Without a departure gate, independent hulls are split by their class MilitaryEngines flag. The military-engine group excludes special jump drives, and the other group allows them. Each group that has ships needs a ready drive whose ComponentValue is at least the largest class Size in the group. This tests the largest hull, not the sum of escorted masses, the combined towed mass or the number of ships. Standard transit ignores JumpRating and escort slots. A fleet with no independent ships fails the check.

Drive coverage for a group is sought in this order:

1. Ready drives that belong to the group itself.
2. Ready drives on any ship of the fleet.
3. An independent ready ship at the departure point whose fleet uses the same system survey record as this fleet.
4. An independent ready ship of this race at the linked point, when this race has already explored the jump point.
5. An independent ready ship of an Allied race at either point, subject to the system checks described next.

Ready means a SensorDelay of 0 and an undamaged eligible drive. Being at the departure or linked point means a difference of strictly less than 1 km on the X axis and on the Y axis, not a radius of 1 km. The linked side counts only when the linked position is known, which requires an Explored value of 1 and a linked jump point.

Foreign-drive caveat. The foreign candidates come from this race’s alien race entries whose ContactStatus is Allied. Friendly status is not tested. The foreign query on the departure side also requires the other fleet to use the very same system survey record as this fleet, while the query on the linked side compares the actual system. Foreign support therefore follows these uneven rules, not a general Friendly access rule. The earlier departure query (step 3) has no race filter but requires the same survey record match.

The planning check for an unstabilised transit runs the military and commercial tests without a specific jump point. Planning therefore requires onboard coverage and ignores tenders waiting at either end. Auto-route planning can exclude an ungated route even when a specific transit could use such a tender.

Squadron transit

The squadron jump test looks at a group of ships. If any member has military engines, special drives are excluded for the whole group. Among ready first-usable drives with a ComponentValue at least equal to the largest hull of the group and a JumpRating above 1, it picks the highest JumpRating. Success also requires that rating to be at least the number of ships in the group, and the drive’s JumpDistance must be nonzero. Equal capacity and an equal ship count both qualify. Squadron transit never borrows a tender at the point and does not treat a departure gate as a bypass. A failure logs that the fleet cannot carry out a squadron transit because no available jump drive can escort it through the jump point.

An NPR transit order turns into Squadron Transit automatically when the fleet’s independent group qualifies. Player orders keep the action the player chose. A successful normal transit first arrives at the actual linked point. A squadron transit then scatters the whole fleet using a d360 bearing and a distance of d(JumpDistance x 1000) km. The distance is a whole number drawn uniformly by radius, not by area of the disc. Zero distance cannot occur for positive die sizes.

After arrival, an NPR fleet that meets any other race’s fleet in the destination system can scatter again or split into escort squadrons. A single ship with a normal usable drive scatters again. Several ships split into transit squadrons, and the detached groups can scatter independently. This presence check is not restricted to detected hostile fleets.

Splitting into transit squadrons sorts the ships that have a normal drive by size, largest first, and picks noncommercial ships without a normal drive as escorts. For each drive it forms a squadron with JumpRating - 1 escort slots, moves escorts no larger than the drive’s ComponentValue, records the JumpDistance and sets a fleet to rejoin. It does not make another intersystem jump itself. Its main use here is the NPR scatter after arrival.

Transit-by-subfleet and transit-and-divide caveats

Sub-fleet structure, squadrons and the detachment rules these transits use are described in detachment.

Squadron Transit by Sub-Fleet runs the squadron jump test on each sub-fleet. Qualifying sub-fleets become new fleets, leave their sub-fleet container and receive the computed squadron transit range. Sub-fleets that fail log a failure event. The original order is then marked complete and the rest of the pass is used up. Each detached fleet then attempts its jump with that same original order. A parent fleet left with no ships is removed.

Mode mismatch. Transit validation handles Squadron Transit, Standard Transit and Transit and Divide Fleet, but it has no rule for Squadron Transit by Sub-Fleet and rejects it. A player’s detached fleet therefore fails that later jump despite passing the earlier test. An NPR’s automatic conversion can replace the shared order’s action with Squadron Transit before validation. Passing the earlier test does not guarantee a successful player sub-fleet transit.

Transit and Divide Fleet shares standard jump validation. The order’s follow-on action then divides the fleet into single-ship fleets, detaching the independent ships and marking the original fleet for deletion. Parasites stay with their ships through the detach and transfer rules. A failed jump also reaches this same follow-on action, so the division does not strictly depend on jump success.

Successful jump state changes and failures

A jump transit validates first and runs the departure-side sensor checks. It explores or creates the connection when the destination system has no survey record yet. It moves the fleet to the linked point and to the destination survey record, and then runs the arrival-side sensor checks. Squadron scatter happens after those arrival checks. The jump then assigns shock and sets the previous and increment-start coordinates to the final position. It records the linked entry jump point (EntryJPID), updates the fleet’s move and transit time stamps, resets the contact increment starts and marks the order complete. A normal jump charges no extra fuel and no movement time beyond the approach travel and the order delay handled outside it.

If validation fails, the jump does not happen. The fleet stays at the departure point and uses up its remaining time. A player’s ordinary failed transit stays queued for a later attempt. An NPR failure marks all queued orders complete. A missing or invalid destination can instead clear the orders before the jump is reached.

Shock delays, crew condition and cooldown

Jump shock sets these values on every ship of the fleet:

• crew performance = (1 + round(sqrt(GradePoints) - 10) / 100) x CrewMorale x OverhaulFactor
• shock multiplier = 2 - crew performance
• standard fire delay = whole-number((120 + d60) x shock multiplier) seconds
• squadron fire delay = whole-number((10 + d20) x shock multiplier) seconds
• SensorDelay = FireDelay
• LastTransitTime = current game time
• the ship is marked as having received a delay in this sub-pulse

Squadron Transit and Squadron Transit by Sub-Fleet use the shorter formula. All other actions use standard shock. NPR Standard Transit halves the resulting whole-number delay and drops any remainder. That halving does not apply to every NPR transit mode. At a crew performance of 1, standard shock is 121 to 180 seconds and squadron shock is 11 to 30 seconds. Better crew condition shortens both. No separate ship commander or rank multiplier and no limit apply to this assignment.

The delay update lowers positive delays by the sub-pulse seconds and stops them at zero. It skips ships that received a delay in this sub-pulse and then clears that marker. SensorDelay is the cooldown that governs the next transit. Validation has no separate fixed jump timer. New shock is not reduced by the same sub-pulse’s delay update.

Special Aether-gate path

Aether gate transit is a separate path used by the Eldar NPR (see special race lifecycles). It adds gate cooldown of class Size x 5 seconds for each commercial ship and class Size x 50 seconds for each other ship, counting every ship of the fleet. Outbound use arrives at the gate coordinates and applies Standard Transit shock. Return to the capital moves the fleet to (0,0) in the capital system and refills fuel, MSP and ordnance. It clears armour and component damage, and empties cargo, prisoners and embarked ground formations. Eldar troop transports then receive as many new Eldar assault groups as fit in their troop capacity. The origin gate is removed when no fleet of the race remains in the origin system. These are special-race rules, not ordinary jump gate replenishment rules for players.

Order queues delays repeats and conditional rules

Order construction and execution priority

The 120 move actions, their flags, availability rules and executors are catalogued in the move action catalogue.

Queuing an order gives it a new ID and a sort position one above the highest existing one (saved as MoveOrder in FCT_MoveOrders). The order stores its destination and a separate item ID, an optional population, and links to a new system and jump point. It also stores MaxItems, MinDistance, MinQuantity, OrderDelay, the remaining delay, OrbDistance and LoadSubUnits. DestinationItemID identifies the cargo, component, formation or exit Lagrange point, not the travel destination.

Each sub-pulse, the movement step selects fleets that have queued orders, have not had their movement settled this sub-pulse, and have no ship under maintenance. It computes a reaction delay multiplier of 1 - fleet reaction bonus fraction, which comes from the Reaction bonuses of the ship commanders and the administrative command. Fleets whose multiplier is zero or less are dropped. The rest act from the highest multiplier down. This sets the order in which fleets act. The multiplier does not scale cargo or countdown times here. Orders are sorted by sort position and fixed at the start of the fleet’s pass. UseMaximumSpeed refreshes speed first. Fleets marked for deletion are skipped.

Each fleet receives the sub-pulse length in seconds. The current order keeps running while it is not complete. A positive OrderDelayRemaining is used up before travel or arrival work. If the delay uses the whole pulse, processing stops. Both travel and operations can leave seconds for later orders in the captured list. On completion the game adds a history entry and, when the fleet cycles its orders, appends a fresh copy. Completed entries are removed after the fleet has been processed. Copies appended during processing are not in the list already captured. An empty queue clears the active conditional diversion state. The Orders Completed event (type 45 in DIM_EventType) is normally suppressed for fleets with applicable standing orders, for civilian lines and for NPR fleets.

Partial timers and persistent actions

The order timer works like this. If TimeRequired is greater than the elapsed seconds, the timer drops by the elapsed seconds and returns 0. Otherwise TimeRequired becomes 0 and the timer returns elapsed seconds - old TimeRequired. Many arrived actions run their final transfer or build only when the returned time is strictly positive. Reaching a TimeRequired of 0 exactly at the end of a pulse therefore leaves the order arrived, with the final action waiting for a later pass with positive time. This differs from simply completing when the timer reaches zero.

Travel subtracts the travel time, cut to whole seconds, from the remaining time. Partial travel and running out of fuel use up the rest of the pulse. Follow reaches its standoff position but leaves the order incomplete and sets the remaining time to 0, so the follow command continues. Planetary support orders likewise stay arrived and incomplete. An interrupt request sets the remaining time to 0.

When a fleet destination disappears or moves to a different system, or a destination cannot be resolved or fails the freshness check, the game logs a failure and clears the whole order queue. A failed jump transit is different. The fleet stays at the jump coordinate and uses up its remaining time, and an NPR marks all captured queued orders complete. Processing still continues into the order’s follow-on action, so action effects such as Transit and Divide Fleet can happen despite the failed jump.

Progressive fuel, MSP and ordnance operations hand back unused seconds, not an amount of moved stock. The movement step cuts that remainder to whole seconds and marks the order complete only when the result is positive. A zero remainder keeps the order active. Missing colony support or stock can hand back the full pulse and so finish an order without delivering any supplies. This is separate from an explicit order that waits for stock.

Repeating and cycling

Repeating orders appends the chosen number of copies of a snapshot of all current orders. A request for 0 becomes 1, so it adds one repetition, not none. It requires a nonempty queue and a first start system equal to the final end system. The final end system is the new system of the last order when it has one, otherwise its start system. With r repetitions the queue holds the original plus r copied sets.

Cycling orders (CycleMoves) copies each completed order onto the end of the queue before completed entries are removed. Cycling switches itself off with an event when the queue has only one order, or when the completed order’s start system does not match the end system of the current last order. The copy keeps the configured IDs, quantities, standoff distance, original delay and survey-point value. It resets OrderDelayRemaining to the original OrderDelay and starts with default arrival, completion and TimeRequired values. It copies SurveyPointsRequired as it stands at copy time, not a separately stored original survey requirement.

Clearing orders empties the queue, resets the conditional diversion state to none and clears the NPR redeployment state. It does not refund cargo already moved and does not reverse past operations.

Standing and conditional orders

The catalogue of all 47 standing orders and 13 conditions, with the checks each receives and the Naval Organization window controls, is in the standing order catalogue. This subsection keeps the execution rules that the order queue applies.

Standing orders run only for idle fleets that have ships and assigned standing rules, have IgnoreStanding off, and have no ship under maintenance or in a shipyard. Priorities run from the lowest number up, and rules are tried until one creates movement orders. Immediate changes to sensors, shields or speed can take effect without creating orders, which lets lower rules run in the same pass. A player fleet that is not civilian receives an event when no orders result. Restricted civilian fleets may first queue a move to the nearest allowed exit into a neighbouring stable system.

Conditional orders can interrupt a queue that is not empty. A fleet qualifies when it has ships and rules, no conditional diversion is active, IgnoreConditional is off, and no ship is under maintenance or in a shipyard. Priorities run from the lowest number up. A rule reports whether its condition was true even when no route could be generated, so the first true condition ends the scan. When that rule has CreateFWP set (in FCT_FleetConditionalOrder), the game creates a fleet waypoint at the fleet’s current position.

Condition (ConditionID, name in DIM_Condition)	Exact test
6, Speed: Less than 100%	Fleet speed is below the fleet maximum, not merely different from it
9, Hostile Active Ship Contact in System	The race has hostile contacts in the fleet’s system
3, 2, 10, 11, 12 (Fuel: 10%, 20%, 30%, 40% or 50% or Less)	Any ship has Fuel at or below class FuelCapacity x percent / 100
1, Fuel: 100%	Any ship has Fuel exactly equal to class FuelCapacity. Not every ship needs to be full
13, Deployment Exceeded	Any ship has (current time - LastShoreLeave) / 2,592,000 > class PlannedDeployment
8, 7, 14 (MSP: 10%, 20% or 30% or Less)	Any ship has CurrentMaintSupplies at or below class MaintSupplies x percent / 100

Fuel and supply tests use the stored class capacities. The percentage tests include equality, as the “or Less” names say.

Running a conditional standing action saves the current orders, clears the move queue and attempts the chosen rule. If the rule produces a usable change, the game keeps the replacement route, sets the conditional diversion state to the requested active state and switches off CycleMoves. If no usable change results, it restores the original orders, with their partial timers and progress. A successful diversion does not keep the interrupted queue for automatic resumption. A separately chosen waypoint or standing return rule is a different mechanism. The Clear Order List rule (standing order 37, IA: Clear Order List) is a quirk. It empties the queue without marking the change as kept, so when a condition triggers it, the saved orders are restored at the end of the attempt.

Standing rule families generate survey, colonist, automated mine delivery, fuel and MSP replenishment, overhaul, salvage, gas giant, mothership, rendezvous and fleet waypoint, exploration and operational group actions. The only installation rules load and deliver automated mines. These are standing orders 21 (LD: AM from Population) and 22 (UL: AM at AM Colony). The trade location rule, standing order 23 (MV: Trade Location), has no action behind it. Local destination searches generally fall back to inter-system auto-route searches when the family supports one. A MaxStandingOrderDistance above 0 overrides the default search radius. Otherwise the default radius of 10,000,000,000 km (10,000 Mkm) applies.

Freight queue reservations and quantity gates

This is the freight planning used by civilian shipping and autonomous logistics. When an idle freighter fleet looks for installation work, its capacity is the sum of the free cargo tons of its ships. The game looks for export requests of the fleet’s own race. Civilian fleets exclude military-restricted colonies (MilitaryRestrictedColony). Supplying colonies are sorted by travel distance with Lagrange point shortcuts, and requests by total cargo points, largest first. A request’s cargo points (amount x installation CargoPoints) must be at least the fleet capacity. The game queues a load and a matching unload. It immediately subtracts fleet capacity / installation CargoPoints from both the export demand and the destination’s import demand. This is demand bookkeeping during planning, before any stock moves. It is not a physical reservation of installations. If no destination can be found, the game clears the proposed queue and carries on.

For trade routes, the fleet capacity is converted to trade-good units (free cargo tons / 2,500, whole units). A supplying colony needs a highest trade balance strictly above that capacity and an eligible trade partner. The civilian restricted-colony exclusion also applies. Each good’s export balance must be strictly above capacity. Supplying colonies are sorted by distance with Lagrange point shortcuts, and goods by category and then balance, largest first. Load capacity already queued for the same colony and good is subtracted. That amount is the whole-number sum, over the queued fleets, of free cargo capacity / 2,500. The remainder must be at least the capacity. Infrastructure at colonies designated as colonist destinations is skipped, and a positive shortfall against the colony’s required infrastructure also blocks its export. The route is queued within the system or between systems. The proposed orders are cleared when no unload destination exists.

Cargo capacity support and operation timing

This section covers how stocks move between colony and ship, between tankers or supply ships and fleets, with stationary fleets, between carriers and parasites, and by cargo transports. Production and maintenance spending are separate from these transfers. Production mechanics covers manufacture and routine consumption. Transfer steps generally rely on the order to have checked the destination and the position. Their own stock and support checks are described below.

Resource	Stock and unit	Transport capacity or work unit
Fuel	Colony FuelStockpile and ship Fuel, in litres	Undamaged fuel storage capacity
Maintenance supplies	Colony MaintenanceStockpile and ship CurrentMaintSupplies, in MSP	Effective maintenance capacity, not cargo hold tons
Missile and decoy ordnance	Loaded ordnance entries, in whole counts	missile Size x count in missile-size points, distinct from maintenance MSP
Minerals	Mineral amounts, in decimal units	2 cargo tons per unit
Installations	Installation cargo and colony installation amounts, in decimal units	The installation’s CargoPoints tons per unit
Ship components	Component cargo and stored components, in decimal units	component Size x 50 tons per unit
Trade goods	Trade good cargo and trade balances, in decimal units	2,500 cargo tons per unit
Colonists	Colonist cargo, in whole persons	Undamaged colonist transport plus passenger module capacity
Troop formations	The ship or population that holds the formation	Whole formation size against troop transport capacity

Free cargo capacity is total undamaged cargo hold capacity - installation tons - component amount x size x 50 - trade good amount x 2,500 - mineral amount x 2. Negative free capacity becomes zero and the result is cut to a whole number. Colonists, troops, ordnance, fuel and MSP have their own stores and do not count against normal cargo mass.

Effective maintenance capacity uses undamaged engineering capacity E and maintenance storage S:

• if E is above 0, capacity = floor(E / (class Size x 0.04) x class Cost / 2 + S)
• otherwise, capacity = S

Fuel shortfalls likewise use undamaged storage capacity, which can be below the nominal capacity of its class.

Normal ordnance capacity is undamaged magazine, missile launcher and fighter pod bay capacity. Decoy capacity comes from decoy launchers. Free capacity subtracts the matching ordnance size x count. Free capacity for the current loadout adds the normal and decoy free values together. These free ordnance values have no floor at zero.

Shuttle and commander support

For a colony transfer, each ship’s shuttle multiplier is built from these terms:

• G = ship commander Logistics bonus x administrative command Logistics bonus for the current system x colony governor Logistics bonus x sector governor quarter Logistics bonus. The colony governor and sector governor bonuses are described on their own page.
• L = race CargoShuttleLoadModifier
• Q = undamaged cargo shuttle bay capacity for ships above 10 HS, or Q = 1 for ships of 10 HS or less
• ship contribution = Q x G x L

A missing commander counts as 1. The 10 HS rule gives a small ship one shuttle equivalent even without a bay, and it replaces the installed bay capacity rather than adding to it. A colony with cargo shuttle capacity of 1 or more adds L separately, and that addition is not multiplied by G. For MSP operations that count maintenance facility support, a colony without cargo shuttles can instead add L when it has positive maintenance facility capacity. It can also add L when a fleet assigned to it has at least one undamaged maintenance module. Only one of these additions applies.

The ship-to-ship multiplier is undamaged donor shuttle bay capacity x ship commander Logistics bonus x administrative Logistics bonus x L. It has no automatic 10 HS shuttle equivalent and no governor or sector term. Installation and mineral fleet transfers can add one support point when the receiving fleet has positive shuttle capacity, or otherwise positive maintenance module capacity. The check for each ship accepts a positive sum of the donor multiplier and that fleet-wide support.

The race’s CargoShuttleLoadModifier, MaxRefuellingRate, UnderwayReplenishmentRate and MaxOrdnanceTransferRate (in FCT_Race) come from the AdditionalInfo value of the corresponding researched technology. These are the cargo shuttle, refuelling system, underway replenishment and ordnance transfer system technologies. The shuttle modifier, the refuelling rate and the ordnance transfer rate are whole numbers and drop any fraction. Only the underway replenishment rate keeps its decimals.

The carrier operations multiplier uses the full Carrier Operations bonus of the CAG when the primary flight control is undamaged. It is multiplied by half of the ship commander’s bonus when effective command and control is available. A ship of 20 HS or less counts as having command and control when it has none.

Fixed-duration loading/unloading

On arrival, load and unload actions set TimeRequired from the load time or the unload and transfer time below, and mark the order arrived. The cargo then moves in one operation after the countdown, not a fraction each pulse. Fuel, MSP and ordnance operations use their own progressive handlers instead, and the whole seconds they hand back decide completion.

Base time per ship:

Action family	Base seconds
Load colonists	free colonist slots x 10
Load minerals, trade goods, components, installations, reserve-level balancing and until-full loads	free cargo capacity x 20
Load assigned ground templates	free troop capacity x 20, when positive
Load a specified ground formation	min(whole formation size, free troop capacity) x 20, including child formations when requested
Unload colonists	carried colonists x 10
Unload minerals	selected or all carried minerals x 2 x 20, at 2 tons per unit
Unload components	carried selected or all component HS x quantity x 50 x 20
Unload trade goods	selected carried amount x 2,500 x 20, at 2,500 tons per unit
Unload or transfer installations	selected or all installation cargo points x amount x 20
Unload ground formations	actual selected or all formation tonnage x 20. The timing for one formation without its child formations does not itself require that formation to be aboard the current ship
Orbital drop and boarding	0

The fleet waits for the longest adjusted ship time, cut to whole seconds, not for the sum. When crew is below the requirement, the time is multiplied by required crew / current crew. At a colony, the time is divided by the shuttle multiplier only when that multiplier is positive, without maintenance facility support. A fleet transfer divides by donor ship-to-ship multiplier + 1 when the recipient has shuttle bays, or by the same multiplier plus 1 when it has maintenance modules instead. A zero multiplier does not make the operation impossible here. It leaves the base time, although the transfer itself may refuse unsupported cargo later. Base load time usually uses the full available capacity, not the order’s MaxItems or the actual stock. The working time value is not reset between ships. A ship that matches no timing rule can therefore reuse and adjust the previous ship’s time.

Most ordinary timed load and unload actions mark the order complete after the transfer, even when missing stock, capacity or support meant that little or no cargo moved. Maximum and minimum values are passed to the transfer where relevant. They do not cause general retries.

Load Mineral when X available is the explicit wait for stock. If MinQuantity is above 0 and the selected mineral stock is below MinQuantity, the order uses up the pulse without lowering the timer or moving cargo. Equality qualifies. Once the threshold is met, the order advances its existing timer and loads, passing on MinQuantity and MaxItems.

Load All Minerals Until Full advances its timer and attempts loading without logging a nothing-loaded failure. It completes only when free cargo capacity is 0. Otherwise it recomputes a full load timer for the remaining capacity and sets the remaining pulse to 0. It can keep waiting and retrying when the colony lacks minerals. It does not finish just because the stockpile is empty.

Cargo loading unloading and fleet transfers

Cargo moves when a timed action reaches its transfer, not gradually during the timer. The quantity and support limits below are checked again when the cargo moves.

Components and installations

Loading components at a colony selects fleet ships with an undamaged cargo hold. Each ship needs free cargo tons and a nonzero colony shuttle multiplier:

• component quantity = min(free cargo tons / (component Size x 50), the colony's stored amount, the remaining positive quantity limit)

Amounts are decimal and not rounded down, so fractional components can be carried. The colony’s stored components drop by that amount. The cargo merges with an entry for the same component, or creates a new entry that records the colony it came from. A positive starting MaxItems is a shared fleet total. Each ship’s loaded amount reduces it, and loading stops when it runs out. A starting quantity of zero or less means no limit.

Installation loading works the same way, with tons per unit equal to the installation’s CargoPoints, and removes the installations from the colony. Fractional installations are allowed. For NPR ships and shipping-line freighters, installation loading first clears the installation cargo already aboard. Player ships outside shipping lines keep it.

Unloading a specific installation moves min(carried amount, remaining positive limit), adds it to the colony, and removes or reduces the cargo entry. Unloading all installations moves every installation and clears the cargo, reporting zero instead of the moved amount. The fleet-level unload of all types explicitly switches off its limit. Unloading components likewise adds every selected carried amount to the colony and removes the entry. No selected component means all types, and there is no quantity limit. When an unload of all components has no shuttle support, the game fails while it writes the “unable to unload” event, because no component is named. It reports error Function #2787, logs no event and unloads nothing.

Minerals and reserve levels

When all types are selected, mineral loading goes through the minerals in their fixed list order and recalculates free tons between types. Shuttle support is required. The minimum available quantity is a test on the colony’s gross mineral stock. The loadable stock is then gross stock - reserve level for that mineral (the reserve columns of FCT_Population, such as ReserveDuranium). Equality at the minimum passes. The attempted quantity is free tons / 2, limited by positive loadable stock and by the remaining quantity. Loading from a player colony records the amount as loaded into a freighter in the colony’s mineral usage record.

Quota quirks when loading all minerals. The load checks the quantity still outstanding, but when it caps the amount it uses the original requested quantity. Once the remaining quantity reaches zero or below, the positive-only limit stops limiting later types. An all-mineral load can therefore exceed its requested amount within a single ship. A failed minimum-availability test ends loading at once instead of moving on to later minerals. The all-minerals sequence starts with a “no specific mineral” step, so a positive minimum can end all-type loading there.

The overwrite with the original limit also bypasses the earlier stock and free cargo limits, so it is more than an order quota overrun. For example, take an original limit of 10 and a first mineral load of 5. A second mineral then has 6 units in stock, no reserve and at least 10 units of free capacity. The remaining limit is 5. Because 5 is less than 6, the load takes 10, leaves the second mineral’s stock at -4 and loads 15 units in total. If free capacity had instead limited the second candidate to 6 with plenty of stock, the same overwrite loads 10 and overfills the cargo hold. Nothing afterwards restores those limits.

A positive minimum with an all-mineral action is reachable through the normal movement window. Select Load Mineral when X available, enter a positive minimum, then switch to Load All Minerals before queueing the order. The window does not hide the minimum available box when the action changes. The box can stay visible with the old value, and that value is passed into the new order. The all-type load then meets the “no specific mineral” step with that positive minimum and stops before loading later minerals.

Unloading a specific mineral honours a positive remaining quantity and moves equal stock. Unloading all minerals credits the whole cargo, records player usage, clears the cargo and reports zero. It ignores the per-ship limit it receives. The fleet limit therefore does not limit an all-type unload.

Load/Unload Minerals to Reserve Level first unloads carried minerals into the colony’s reserve shortfalls. It then loads stock above the reserves into the newly freed cargo space, in list order. It uses equal decimal debit and credit, no MaxItems limit, and colony shuttle support. It can unload one mineral to fill a reserve and use the freed space for another.

Fleet-to-fleet installations and minerals

Receiving cargo ships need positive undamaged cargo hold capacity. Shuttle bay or maintenance module capacity anywhere in the receiving fleet gives one shared support flag, so the receiving cargo ship need not carry the support itself. The donor’s own ship-to-ship multiplier plus that flag must be nonzero. These transfers do not check location, stationary status or race themselves. Order eligibility governs those.

Transfer Installation and Transfer All Installations go through donor cargo entries and receiving ships in turn:

• quantity = min(receiver free tons / CargoPoints, donor amount, remaining positive limit)

Amounts are added and removed equally, and the record of the colony the cargo came from is kept. When a new receiving cargo record is created, the new cargo entry is recorded against the donor ship, although it sits in the recipient’s cargo. Donor records that reach zero are not removed. A positive limit that reaches zero does not stop the transfer. Later recipients, types and donors treat zero as no limit and can exceed MaxItems.

Transfer All Minerals moves cargo only when no specific mineral is selected. A specific mineral type moves nothing and hands back the remaining quantity. That no-op arises only for an edited order or a direct transfer with a mineral set. The normal Transfer All Minerals action (226 in DIM_MoveAction) has DestinationItemType 0 and is queued with DestinationItemID 0. Queuing assigns a selected mineral only for mineral and carried-mineral item types. The normal action therefore selects no specific mineral and reaches the all-type transfer. For all types it reduces the recipient’s free tons after every move, so the cargo capacity budget holds. The same positive-only limit test can still resume unlimited movement after the limit reaches zero.

Colonists

Colonist loading takes the smallest of three amounts. The first is undamaged colonist transport and passenger module capacity - whole-number(people already carried). The second is the colony’s population in millions x 1,000,000. The third is a positive requested limit. Shuttle support is required. The load creates colonist cargo with the species and colony of origin, and marks it Neutral when the colony’s ProvideColonists is 1. It reduces the colony’s population by the selected decimal load quantity, while the cargo amount keeps only the whole number, so fractional people can be lost. The fleet reduces its limit by the whole-number cargo amount, not by the decimal debit.

For example, selecting 2.9 people reduces the colony by 0.0000029 million but stores two people. The load guards only against zero capacity and then moves only a positive calculated quantity. It does not invent capacity for a damaged, overfilled transport. Shipping-line ships also reduce the colony’s AvailableColonists and record the load distance, and a failure can clear their orders.

Unloading requires the same species, shuttle support and, for Neutral cargo, a destination outside the system of origin. Each accepted entry adds amount / 1,000,000 to the colony’s population and is removed. Rejected entries stay aboard. This unload has no partial quantity and no MaxItems limit. The fleet then recalculates the colony’s infrastructure figures (see colony and population lifecycle).

Trade goods

A trade good load moves min(free cargo tons / 2,500, positive trade balance of the colony), with shuttle support. It creates or merges decimal cargo and reduces the colony’s balance. It takes no MaxItems value. Unloading all of the selected carried good removes its cargo record. Goods of the Infrastructure category become Infrastructure installations. Other goods add to an existing trade balance at the destination. Shipping revenue and taxes are described in trade goods delivery, taxes and civilian contracts.

Troop formations

Free troop capacity is whole-number(undamaged troop transport capacity) - whole-number(summed sizes of carried formations). A formation is never divided between ships. The whole formation size must fit one transport. Loading at a colony requires the formation to be at the order’s population. Loading from a stationary fleet requires the formation’s current ship to be in the fleet named by the order’s DestinationID. A successful load puts the formation aboard the receiving ship, removes it from the population and resets every element’s FortificationLevel to 1. The load reports success whenever the free capacity was large enough, even if the location test made no change.

Loading a formation into troop transports tries the transports in fleet order and stops at the first formation that cannot load. With LoadSubUnits it selects the formation and its child formations. When loading from a stationary fleet with LoadSubUnits, the child formations are chosen from the order’s population rather than from the donor ship’s holdings. That selection can differ from the check made for the individual transfer. Load Assigned Ground Templates picks the first colony formation matching each original template and repeats up to its class template count, until one is missing or cannot load. These troop loads have no shuttle check of their own and no MaxItems formation count.

Unloading specified or all troops removes the formations from the ship, places them at the destination population, logs their arrival and resets fortification to 1. Specified loads and unloads can include child formations. Neither unload checks cargo shuttles directly. The combat-drop record that feeds commander measurements is attached to the Orbital Drop All Ground Units order only, but troop transports send that order to the unload-all step, which records nothing. No unload therefore records a combat drop. The actual support, time and destination gates of the orders are covered in the order section.

Colony fuel and maintenance transfers

Let H = sub-pulse seconds / 3,600. Refuel from Colony requires a population on the order, a nonzero refuelling point capacity at the colony and a positive FuelStockpile. The refuelling point capacity comes from the colony’s installations. Each ship receives its own rate allowance:

• target = undamaged fuel capacity
• target = MaxItems when MaxItems is above 0 and below that capacity
• transfer = min(positive target - current fuel, colony stock, race MaxRefuellingRate x H)

MaxItems is a target fuel level in litres per ship, not a total fleet transfer. It does not drain a ship that is above the target. The colony loses exactly what the ship gains. Refuelling at a colony does not require the recipient to mount a refuelling system or to be a tanker. The rate allowance resets for each recipient while the colony stock is shared, and refuelling stops once the colony stock reaches zero. NPR ships carrying survivors at a colony with a population of at least 1 million also unload their prisoners during this step.

Resupply from Colony requires a positive MaintenanceStockpile and a nonzero recipient shuttle multiplier with maintenance facility support counted. Each ship receives:

• transfer = min(positive effective MSP capacity - current MSP, colony MSP stock, 10 x H x shuttle multiplier)

The allowance of 10 MSP per hour applies to each ship. Resupply ignores MaxItems.

Both operations hand back unused sub-pulse seconds to order processing. If a ship’s shortfall is at least the available transfer amount, the remainder becomes zero, even when the colony stock rather than the rate causes the shortage. Otherwise used seconds = shortfall / available transfer amount x full sub-pulse, and the remaining seconds are cut to a whole number. The divisor is min(colony stock, rate budget), so scarce stock can change the calculated duration. The fleet result is the smallest remainder across the ships processed.

Refuel and Resupply from Colony gives both operations the full pulse and hands back the smaller remainder. Refuel, Resupply, Load Ordnance from Colony runs all three operations with the full pulse. It returns the MSP remainder at once when that is below the fuel remainder, without comparing it with the ordnance remainder. Its result is therefore not always the smallest of the three.

Returning stock to a colony

Transfer Fuel to Colony requires an existing destination population, nonzero refuelling point capacity, a ship designated as a tanker (FuelTanker in FCT_ShipClass) and at least one undamaged refuelling system. Each donor moves min(Fuel - MinimumFuel, class RefuellingRate x H), only when the surplus is positive. Unlike fleet-to-fleet fuel donors, this surplus does not cut Fuel to a whole number first.

Transfer Maint Supplies to Colony requires the supply ship designation (SupplyShip) and a nonzero colony shuttle multiplier with maintenance support. Each donor moves min(CurrentMaintSupplies - MinimumSupplies, 10 x H x multiplier), only when the surplus is positive. MaxItems is unused. The colony gains exactly what the donor loses. Both returns set the remaining time to zero when the whole rate budget is used. Finishing early hands back a remainder cut to whole seconds.

Tankers supply ships and stationary support

What replaced refuelling hubs

AuroraSteve’s Refuelling Changes post in the official v2.6.0 patch notes topic states that the separate refuelling hub format and its dedicated order routes were removed. Multiple refuelling systems now give a tanker a higher combined flow. The post also documents minimum-level stationary tanker orders. The rules below describe the rates and gates the game applies.

Refuelling now uses ordinary tanker ships with refuelling systems and stationary-fleet orders. The ordnance transfer hub remains a separate component and is still used for ammunition. Its presence does not mean that the removed refuelling hubs still exist.

A class’s refuelling rate (RefuellingRate in FCT_ShipClass) is set to the total value of one class component entry, so several copies of the same refuelling system design add flow. Different refuelling system designs overwrite the rate one after another as its class design is read. The rate is therefore not a sum over different designs. A class’s OrdnanceTransferRate is set to one ordnance transfer system’s ComponentValue, without multiplying by the count. Transfers generally use these nominal class rates after checking that at least one required system is undamaged. They do not scale throughput by the number of surviving systems.

A class with a positive refuelling rate below 20,000 litres per hour and a Size above 20 HS has its class rate set to zero. It receives the design warning “Small Craft Refuelling System can only be used on ships of 1000 tons or less”. A tanker with a low rate refuels only recipients of 20 HS (1,000 tons) or less. The threshold is 20,000 litres per hour.

Automatic fleet tanker transfers

Automatic tanker refuelling selects tankers whose refuel status (RefuelStatus) is not none. It does nothing when every ship in the fleet is an active tanker, so the Refuel Fleet Tankers status does not transfer within a fleet made only of active tankers. Each tanker needs an undamaged refuelling system. Each donor receives one budget shared across all its recipients:

• B = class RefuellingRate x H
• B is multiplied by the race’s UnderwayReplenishmentRate when the fleet’s LastMoveTime equals the current game time
• available donor fuel = whole-number(Fuel) - class MinimumFuel
• shared allowance = min(B, available donor fuel)

Recipients receive min(positive shortfall against effective capacity, remaining donor allowance). Refuel Fleet Tankers serves other tankers. Refuel Fleet serves ships that are not tankers across the fleet. Refuel Subfleet serves ships that are not tankers in the donor’s sub-fleet. All three sort recipients by ship RefuelPriority, then class RefuelPriority, then effective fuel capacity, smallest first. A recipient with a positive shortfall is marked as having received fuel in this pass, even if the donor fills it only partly. Later donors in the same pass skip it. The donor’s unused allowance shrinks as recipients are filled.

For example, take a tanker rated at 20,000 litres per hour, a one-hour pulse, 15,000 litres above its minimum and two recipients each missing 10,000 litres. The tanker gives 10,000 and then 5,000. This is one 15,000 litre donor allowance, not 15,000 per recipient. The second recipient is still marked as served and cannot receive its missing 5,000 from another tanker in that pass.

Automatic fleet MSP transfers

Automatic fleet resupply selects supply ships whose resupply status (ResupplyStatus) is not none. It requires an undamaged cargo shuttle bay on the donor, even when another source could give shuttle support. The shared donor budget is:

• B = 10 x donor shuttle multiplier x H, with the shuttle multiplier taken with no colony and no maintenance facility support
• B is multiplied by UnderwayReplenishmentRate when LastMoveTime equals the current game time
• shared allowance = min(B, the whole-number part of CurrentMaintSupplies - MinimumSupplies)

Recipients are ships that are not supply ships, in the whole fleet (Resupply Fleet) or in the donor’s sub-fleet (Resupply Subfleet). They are sorted by ship ResupplyPriority, class ResupplyPriority and effective MSP capacity, smallest first. Partly served recipients are marked and skipped by later donors in that pass. A positive shortfall against effective capacity is required, and the donor loses exactly what the recipient gains.

Ordered transfers between fleets

Refuel from Stationary Tankers and Refuel Stationary Fleet share one stationary fuel transfer. It can take fuel from tankers in the destination fleet or give fuel to the destination’s ships. The destination must exist and must not have a LastMoveTime equal to the current game time. No tankers are available when the destination fleet’s first order is not a stationary action (one with StationaryAction set in DIM_MoveAction). Otherwise the available tankers are designated tankers with undamaged refuelling systems, richest first by Fuel / class FuelCapacity. This differs from the test that picks a fleet as a refuelling source for support, which requires no orders at all and a donor with Fuel above 2 x MinimumFuel.

Ordered fuel transfers use the same donor reserve (whole-number(Fuel) - MinimumFuel) and one class-rate budget per tanker across recipients, without the underway multiplier. They apply the 20 HS recipient limit for low-rate donors, the normal priority order and the served-this-pass exclusion. A positive MaxItems below effective capacity is a target fuel level in litres for each recipient.

The accepted actions include Refuel to Minimum from Stationary Tankers, but the check that sets the minimum target names Refuel Stationary Fleet to Minimum twice and never names Refuel to Minimum from Stationary Tankers. Giving fuel with Refuel Stationary Fleet to Minimum can therefore target each recipient’s MinimumFuel. Taking fuel with Refuel to Minimum from Stationary Tankers does not apply that minimum target in this transfer. The minimum target overrides any MaxItems target.

Resupply from Stationary Supply Ship and Resupply Stationary Fleet take MSP from stationary supply ships or supply the destination fleet. Available supply ships need undamaged shuttle bays and either a stationary first order or no orders. The transfer uses the automatic MSP donor rate and reserve without the underway multiplier, targets full effective capacity and has no MaxItems limit. The test that picks a fleet as a replenishment source is stricter. It requires no orders, a fuel donor above twice its minimum, and a supply ship with an undamaged shuttle bay and positive MSP.

Ordered fuel and MSP transfers start with a full unused sub-pulse. A recipient that needs more than the remaining donor allowance forces the remainder to zero. Otherwise each completed recipient sets the remainder to min(old remainder, full pulse x remaining donor allowance / donor nominal rate budget). The starting allowance can already be limited by stock, so this is not always the full pulse minus the time used at the nominal rate. A missing donor or destination, or a destination that is moving, hands back the full sub-pulse.

Carriers parasites and hangar transfers

Free hangar capacity is undamaged hangar deck and commercial hangar deck capacity - Size of the ships docked in this ship, with Size in HS. Assigned free capacity subtracts the ships that are docked in it or assigned to it as their mothership. These values are separate from cargo holds and troop transports, and a negative result is not raised to zero.

Land on Assigned Mothership requires the destination fleet to contain each ship’s assigned mothership, with free hangar capacity of at least the ship’s Size. Ships already docked are skipped. A successful landing records the mothership, moves the ship and its survivors into the fleet, and can create a landing sub-fleet. Landing on a specified mothership or as a squadron likewise checks the destination carrier’s free space for each ship, adjusts squadron membership and normally updates the assigned mothership. Land on Specified Mothership (No Assign) keeps the previous assignment. Hangar space is used up ship by ship, so earlier ships can fill it and later ships fail.

Detaching a squadron creates a fleet at the carrier fleet’s position and orbit. It clears the mothership and the current squadron and sub-fleet membership, keeps the assigned squadron (AssignedSquadronID), and moves the ships. It does not replenish stocks during this change. The order section covers movement and time eligibility around these steps.

Carrier fuel and MSP

Parasite fuel candidates are docked ships below their class fuel capacity. The carrier qualifies when its Fuel is above MinimumFuel. Shortfalls use the parasite’s effective undamaged capacity. For each parasite:

• the fuel transfer is at most race MaxRefuellingRate x carrier operations multiplier x H
• the fuel transfer is at most whole-number part of carrier Fuel - MinimumFuel
• the fuel transfer is at most the positive effective shortfall of the parasite

Unlike automatic tanker refuelling, the rate allowance is applied afresh to each parasite. The donor’s available stock is recalculated each time and is shared. Parasite refuelling checks no tanker designation and no undamaged refuelling system. Parasites are sorted by ship and class refuel priority, then by effective capacity.

Parasite MSP candidates are below their class MaintSupplies. For each parasite the rate is 20 x carrier operations multiplier x H, twice the standard base rate of 10. The limits are whole-number part of carrier CurrentMaintSupplies - MinimumSupplies, and the parasite’s effective MSP shortfall. The allowance resets for each parasite. Exact quirks:

• The carrier qualifies by comparing its Fuel with MinimumSupplies, not by its current MSP. The later transferable MSP check still stops when the donor surplus is zero or less, so the wrong fuel test does not create a negative donor budget.
• Sorting uses ship and class ResupplyPriority, then effective fuel capacity.
• The shortfall test is “not zero” instead of “above zero”. Damage can push effective MSP capacity below the current stock. A negative shortfall then returns MSP from the parasite to the carrier and sets the parasite to its lower effective capacity. The size of that reverse adjustment is not limited by the forward rate allowance.

Ordnance transfers hubs and carryover

Ordnance transfer modes are add, remove and replace. Replace first returns unwanted types and amounts above the desired template, then fills shortfalls. A ship’s own nonempty loadout template overrides its class template. Types are processed largest Size first. Moving n rounds takes n from one side, adds n to the other and spends n x missile Size of transfer capacity. Empty stock entries are removed. These stock-to-stock transfers cost no wealth and no minerals.

For a desired missile type, loading generally computes:

• n = min(floor(remaining transfer capacity / missile Size), template shortfall, matching stock at the supplying side, floor(available destination storage as taken at the start / missile Size))

Removal uses the matching unwanted count and the receiver’s available capacity, except that colony stock has no magazine limit. Types missing at the supplying side are skipped, so a desired type that is missing does not by itself keep the order working. These ordnance transfers do not use MaxItems.

Path	Required support and recipients	New capacity budget
Colony	Nonzero ordnance transfer point capacity at the colony. Ships with total magazine capacity above 0	race MaxOrdnanceTransferRate x H per ship
Stationary ordnance hub	Destination fleet with no orders and an undamaged ordnance transfer hub. Ships of the acting fleet with undamaged magazine capacity above 0	race MaxOrdnanceTransferRate x H per affected ship, shared across hub ships
Automatic collier	Collier designation (Collier) and an ordnance transfer status (OrdnanceTransferStatus) other than none. Recipients that are not colliers and have normal ordnance capacity	class OrdnanceTransferRate x H per recipient, multiplied by UnderwayReplenishmentRate when the fleet’s LastMoveTime equals the current time
Carrier parasites	Carrier has positive undamaged military or commercial hangar capacity. Docked parasite has an undamaged magazine or missile launcher	carrier race MaxOrdnanceTransferRate x carrier operations multiplier x H per parasite

The collier transfer does not itself require an undamaged ordnance transfer system, although the collier capability test used elsewhere requires one. It uses the nominal class rate and skips a zero rate. Colliers act highest class rate first. A fleet-wide status (Load, Replace or Remove Fleet Ordnance) limits recipients to this fleet. A sub-fleet status (Load, Replace or Remove Sub Fleet Ordnance) finds recipients by sub-fleet alone, without checking the fleet. Ships outside any sub-fleet can then match a donor that is also outside any sub-fleet, which widens the selection beyond the donor fleet. Collier transfers exclude decoys in both directions and use normal magazine capacity.

Transfer work carried across pulses

Each affected ship starts with its new capacity budget plus any carried-over transfer capacity. The transfer spends from the remaining capacity and then decides whether to keep the rest for a later pulse:

• Colony. Keep the remainder and hand back zero unused time if the remainder is smaller than the largest size actually transferred, or if the shared blocked marker was set because an existing needed type could not move. Otherwise clear the carry-over and compute unused seconds = full pulse x remaining / new budget.
• Carrier. The same pattern, with the largest transferred size and the blocked marker shared across the whole carrier transfer.
• Hub. Keep only when the remainder is smaller than the shared largest size actually transferred. There is no blocked marker.
• Collier. Keep when the remainder is smaller than the shared threshold. A desired type that is in stock but larger than the remaining budget also writes its size into the threshold, even when nothing moves.

Thresholds and blocked markers are shared across recipients, so an earlier recipient can influence the carry-over decisions of later recipients. In a hub transfer, each affected ship’s transfer budget is shared across donor hubs, and the largest-size threshold is shared across the whole transfer.

Colony, carrier and collier transfers can therefore build up work until a large missile can move. In the hub transfer, if no missile ever fits the starting budget and nothing moves, the threshold stays zero and the remainder is cleared, not carried. That first large missile can then stay stuck. For example, 4 size points per pulse cannot move a size 6 round at first. The colony blocked rule keeps the 4 and allows the transfer after a later pulse, while the hub, with a zero threshold, does not. Unused seconds are capped indirectly by the starting full-pulse comparison, even when earlier carry-over makes remaining / new budget exceed one.

Storage limitations and exceptions

Colony, carrier and hub transfers can use normal plus decoy free capacity for any ordnance, so the two stores are not strictly separate. Several transfers take the free storage once before they go through the missile types and do not reduce it after each type moves. Several types together can overfill that starting space, even though stock counts themselves move equally. Collier transfers keep decoys separate but also take normal free storage once for their whole type list.

No hub ships are available when the destination fleet has any move order. The stationary hub transfer does not handle that case. It fails with error Function #864 and hands back zero unused seconds. Stationary tanker and supply ship transfers handle the same case normally. The hub transfer does not apply the destination LastMoveTime test that ordered fuel and MSP transfers use.

Weapon recharge is separate from ammunition loading. Launchers that reload only in a hangar (HangarReloadOnly) need a mothership, or an ordnance transfer colony or hub of the same race in the same system at exactly the same position. Ordinary launchers recharge without such support. A hub’s availability for this reload check is not the same as drawing ordnance from it.

Persistence and reload

Table	Stored movement values and what they mean
FCT_MoveOrders	Sort position (MoveOrder), destination and item IDs and types, population, new system and jump point links, delay and remaining delay, arrival flag, TimeRequired, remaining survey points, MinDistance, MinQuantity and MaxItems, orbit distance, sub-unit and message values
FCT_Fleet	Current, previous and increment-start position, LastMoveTime and LastTransitTime, Speed, OrbitBodyID, OrbitDistance and OrbitBearing, AssignedPopulationID, CycleMoves, anchor and threat references and formation offsets, AutoLP and the ignore-rule flags
FCT_FleetStandingOrder	Fleet, standing rule, priority
FCT_FleetConditionalOrder	Fleet, condition, chosen standing rule, priority and the create-waypoint flag (CreateFWP)
FCT_LagrangePoint	System, star and body links, coordinates, Distance and Bearing. Numbering is recomputed after loading
FCT_Contacts	Unique and actual IDs, observer, subject and system, current, previous and increment-start coordinates, speed, creation, re-establishment and update times, and continuous contact time

Move orders load in their saved sort order. The game skips orders whose race, fleet or start system is missing, or whose required new system, jump point or population is missing. Arrival and timer progress survive a reload, so partly completed cargo operations can resume. Completion is not saved with the order. MinQuantity is a decimal in play and in the save, but loading rounds it to a whole number, with exact halves going to the even neighbour. MaxItems loads as a decimal. A fractional minimum is therefore not preserved. The active conditional diversion state and the moving and movement-settled flags of each sub-pulse are not saved in FCT_Fleet. An active diversion is therefore separate from the saved rule configuration.

Lagrange point loading skips points whose body, star or system is missing, restores position and bearing, and then renumbers the points of each system. Contact loading skips rows whose system, contact race or detecting race is missing. It links the actual ship, salvo or population when it still exists, and restores the snapshot exactly instead of computing a fresh detection. A contact row is not necessarily discarded when its actual object no longer exists, as long as its race and system references survive.

Body loading restores OrbitalDistance, Bearing, Year and Eccentricity together with their object links. Star loading restores the stellar orbital values too. These saved values drive future updates. They do not promise that the next coordinate step is a physical orbital forecast.

Runtime transfer credit and pass markers

Carried-over and remaining ordnance transfer capacity exist only in the running game and are not saved with ships. Reloading starts them at zero, so unused ordnance work credit is lost while stock already moved stays saved. The markers for having received fuel or maintenance supplies in this pass also return to false. Fuel and MSP transfers reset those markers over their chosen recipients each time they run, so the exclusion of later donors lasts only for one run. Carrier parasite transfers do not use those markers.

Worked examples and interpretation caveats

These examples apply the formulas above with illustrative ship and stock values. They separate the work or time allowance of each step from the resource it moves.

Example	Inputs	Result
Effective propulsion	Undamaged engine power 200, OverhaulFactor 0.8, class 100 HS, no tow	Thrust 160 gives 1,600 km/s. Towing another 100 HS reduces the same calculation to 800 km/s.
Fuel-limited travel	Raw engine power 200, effective maximum 1,600 km/s, requested speed 800, fuel efficiency 0.5, requested duration 7,200 s, fuel 50 L	Requested burn 100 L. This hull limits the fleet to 3,600 s and 2.88 Mkm at 800 km/s.
Dust cap	Armour 2, DustDensity 0.5, stored speed 15,000 km/s	Cap is 10,000 km/s. With armour 0 and positive dust the cap can instead give 0 km/s.
Colony versus tanker budget	Rate 20,000 L/h, one-hour pulse, two recipients each needing 20,000 L	A stocked colony can give 20,000 L to each. A tanker has one 20,000 L allowance shared across both recipients.
Timed cargo boundary	Countdown 120 s, pulse 120 s	The timer reaches 0 and returns 0. The final transfer waits until a later pass with positive time. MaxItems can limit cargo quantity without reducing the original free-capacity timer.
Ordnance work credit	New budget 4 size points per pulse, desired size 6 round, stock present	The colony blocked rule can keep 4 and allow a later transfer. A hub with no earlier transferred threshold clears that credit and can stall. Reloading also loses the credit.
Repeat zero	Two orders forming a loop in one system, requested repeat count 0	The game replaces 0 with 1 and appends one copied set, which gives four queued orders.
Jump shock	Crew performance 1	Standard shock 121 to 180 s. Squadron shock 11 to 30 s. NPR Standard Transit halves its resulting whole-number delay.

For planning and for reading saved state, keep these distinctions explicit:

• Speed and endurance. Actual propulsion, the stored selected speed, the dust cap, the fuel budget during travel and the displayed design range have different inputs. A saved MaxNebulaSpeed is not the cap applied during travel.
• Position and detection. A body or Lagrange point can move while a contact remains stale. Orbital copying and fuel-burning formation movement are different rules. A Contact destination uses UniqueID, while ContactID identifies its target object.
• Rate ownership. Colony allowances apply to each recipient. Automatic tanker and supply allowances belong to each donor and are shared among its recipients. Carrier allowances apply to each parasite. Collier flow applies to each recipient. Shared stock, markers and repeated passes still affect these allowances.
• Timing and completion. A positive unused-time return can finish an operation without moving resources, while an exact zero remainder can defer final work that is ready to run. Ordinary cargo attempts, availability waits, until-full loads and continuing Follow commands have different completion rules.
• Quantity and state. MaxItems can mean a shared cargo quota or a target fuel level for each ship, and several operations ignore it. Whole troop formations, fractional components and installations, and whole people and missiles follow different rounding and fit rules.
• Configuration and live progress. Queued values and saved rules do not keep every diversion flag or every unit of transfer work credit. Fixing the order list at the start of the fleet’s pass also postpones newly appended cycle copies.

The mode mismatch for Squadron Transit by Sub-Fleet, the division after a failed Transit and Divide Fleet, the exact-coordinate test for following an orbit, the shared and cached ordnance capacity and the cargo quota exceptions are described with their individual rules. They should not be replaced by behaviour inferred only from a mode name or from a historical patch description.

Concept map

• Movement cadence, when orbits, orders and rules run.
• Automatic supply phases, the sequence of order-free supply steps.
• Speed and fuel burn, thrust, towing, travel fuel and endurance.
• Dust speed cap, the armour-based nebula speed limit.
• Body and star orbits, periods, ellipses and which bodies move.
• Lagrange points, natural and stabilised points and their motion.
• Anchoring, how fleets, parasites and contacts follow bodies.
• Destinations and interception, destination types, contact freshness and pursuit.
• Lagrange point shortcuts, intra-system jumps inserted at queue time.
• Transit modes, drive coverage, gates, squadrons and failures.
• Jump shock, crew-based delays that block the next transit.
• Order queue rules, delays, timers, repeats and diversions.
• Freight planning, demand bookkeeping for civilian freight.
• Cargo capacity, cargo, MSP and ordnance capacity and shuttles.
• Cargo operation time, how long loading and unloading take.
• Cargo transfers, what each load, unload and transfer moves.
• Colony replenishment, refuelling and resupply at colonies.
• Tankers and supply ships, fleet-to-fleet fuel and MSP.
• Carriers, hangar space, landing and parasite supply.
• Ordnance transfers, colony, hub, collier and carrier ordnance.
• Saved movement state, what a save keeps for orders, fleets and contacts.
• Runtime transfer credit, ordnance credit and pass markers lost on reload.
• Jump-point network, links, gates and route search used by transits.
• Route danger, danger ratings that auto-routing avoids.
• Fleet organisation, sub-fleets and squadrons used by transits.
• Move action catalogue, every move action timed here.
• Standing and conditional orders, the rules the queue runs.
• Movement order templates, saved order lists for the same queue.
• Waypoints, search waypoints for lost contacts.
• Game time, increments and cycles that drive movement.
• Observation and knowledge, how contacts arise and expire.
• Intelligence, what races learn from contacts.
• Production, how fuel, MSP and ordnance are made and used.
• Wealth, revenue and taxes from trade deliveries.
• Civilian economy, shipping lines that use freight planning.
• Logistics interruption, logistics orders cut short.
• Mass Drivers, mineral transport without ships.
• Colony lifecycle, colonist delivery and infrastructure.
• Colony output, the cycle that deliveries feed.
• Planetary installations, refuelling, ordnance and shuttle capacity at colonies.
• Ship design, class capacities, rates and warnings.
• Component design, jump drive ratings and transfer components.
• Technology, technologies that set race transfer rates.
• Commanders, Logistics, Production and Reaction bonuses.
• Naval administration, administrative command bonuses.
• Ship readiness, crew grade, morale and overhaul.
• Fleet recovery, travel and supply that restore fleets.
• NPR fleet readiness, NPR tanker assignments.
• NPR strategic planning, missions that queue NPR movement.
• NPR tactical behaviour, NPR responses in a system.
• NPR race generation, operational groups behind NPR actions.
• Special races, Eldar Aether gates and Swarm exceptions.
• System generation, natural Lagrange points and orbits.
• System disasters, orbital decay and the single-body refresh.
• Planetary terrain, terrain refreshed by eccentric orbits.
• Ground forces, formations carried by troop transports.
• Medals, combat-drop records from troop unloads.
• Object identity and reload, how saved objects return on load.

Resources

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

• Aurora Wiki: Orders
• Steve Walmsley: logistics (C# launch documentation)
• Steve Walmsley: refuelling changes (v2.6.0)