Separate state stores

Section titled “Separate state stores”

This page follows what happens when a logistics job is cancelled, replaced, loses its destination or changes ships, and what survives a reload. It describes what each step does. It does not promise atomic delivery or automatic compensation. Normal transfer formulas, persistent orders, timers and ordnance credit are in movement and logistics. Route selection and shipping income are in civilian economy and autonomous logistics. Object allocation and the rebuilding of links on load are in object identity and reload. Those pages cover ordinary reservation formulas, partial timers and saved fields. This page covers the interruption transitions. These are which removals undo planning demand, which erase cargo, whether ship transfers carry queues, and whether a reload reconciles a surviving request with a discarded order.

State Where the game keeps it What changes it
Installation planning demand The colony’s installation supply and demand requests (FCT_PopInstallationDemand), each with a decimal Amount and an Export flag A successful route assignment subtracts the planned capacity from both requests before pickup.
Trade good planning reservation A calculation over matching queued Load Trade Goods and Unload Trade Goods orders and the current free cargo capacity of their fleets Removing orders or changing a fleet’s current capacity changes the next calculation. These selections use no separately allocated reservation record.
Physical installation stock The colony’s installations and the ship’s installation cargo A ship load is capped by current stock and capacity, creates or increases the cargo, then removes the installations from the colony.
Operation work The order’s remaining operation timer (TimeRequired), Arrived flag, remaining delay (OrderDelayRemaining) and survey points (SurveyPointsRequired) Arrival sets up the work. Later passes of the movement step advance the remaining timer.
Ordnance work credit The ship’s ordnance transfer capacity carried over from earlier pulses and its remaining ordnance transfer capacity for the current pulse Transfer steps calculate these budgets while the game runs. They are separate from missile inventory.

An installation assignment is therefore a request reduction, not a lock on particular physical installations. A later pickup still reads the colony’s stock at that moment and may load less or nothing. The planner subtracts the fleet’s free cargo capacity in tons divided by the installation’s CargoPoints, as a decimal division with no rounding. The same amount comes off the source colony’s export request and off the destination colony’s import request for the same installation. This applies both to a destination in the same system and to one found through other systems. No per-job record links that reduction to a later cancellation. At pickup, each ship loads its free cargo capacity divided by the installation’s CargoPoints, capped by the colony’s current stock of that installation and by any remaining quantity limit of the order.

For ordinary trade goods, a queued order matches when it has the right action, the same colony and the same good (DestinationItemID). The source test counts Load Trade Goods orders (move action 136) at the source colony. The destination test counts Unload Trade Goods orders (move action 137) at the destination colony. The calculation goes through the orders of every fleet in the game, takes the fleet of each matching order, and sums the available free cargo capacity of that fleet’s ships. It divides the sum by 2,500 tons per trade good unit and cuts the result to a whole number. It does not sum the cargo promised when the route was created. Several matching orders can count the same fleet’s capacity more than once. A source passes when its balance minus the queued loads is at least the fleet’s own free cargo capacity in trade good units (free tons divided by 2,500, cut to a whole number). A destination passes when its balance plus the queued unloads is at most minus that capacity. A source colony is a candidate only when its balance is above that capacity, and a destination only when its balance is below minus that capacity.

The installation request lists on the Civilian / Flags tab of the Economics window have a separate calculated Assigned column. It looks only at fleets whose civilian function is Freighter. For a supply request it counts Load Installation orders (move action 176) at the colony for the same installation. For a demand request it counts Unload Installation orders (move action 177). It sums the current free cargo capacity of those fleets’ ships and divides by the installation’s CargoPoints. The Amount column shows the stored request Amount. A disappearing Assigned value therefore does not show that the stored amount was restored.

Cancellation and replacement

Section titled “Cancellation and replacement”
Entry point What it changes Compensation and preserved state
Clearing a fleet’s orders Empties the fleet’s order queue and sets the conditional diversion state to none. For an NPR fleet it also clears the redeployment flag (FCT_Fleet.RedeployOrderGiven) and the redeployment target system No change to stock, cargo, request amounts or ship ordnance credit in this step.
Removing the last order Finds the last order and removes it by its order ID Does not clear the rest of the queue. No request refund and no cargo operation in this step.
Conditional standing action with a usable replacement Sets the existing orders aside, clears the queue and runs the rule. When the rule marks its change as kept, the game keeps the new route, sets the requested conditional diversion state and switches off the Cycle Moves checkbox of the Naval Organization window The old queue is not stored for automatic resumption. Physical cargo already aboard is not unloaded here.
Conditional standing action with no kept change Puts the saved original orders back when the saved queue was not empty and the action ran as a conditional order The same orders keep their timer and arrival progress. The game restores the existing orders. It does not build fresh ones.
Repeat or cycle copy Each copy gets a new order ID and copies the order’s configuration The remaining delay resets to the configured delay (OrderDelay). The copy starts as a new order does, not arrived, not completed and with a TimeRequired of 0.

None of these steps reverses the installation request debit. A job that was assigned and then cleared through one of them can leave its reduced request amounts behind while the route no longer exists. This holds for these paths. It does not mean that a request can never be changed again. Setting a request for an installation removes any existing request for that installation and stores a new one with the given amount, export flag and nonessential flag.

A failed route discovery differs from cancelling an assigned route. The installation planner queues a candidate load first and then searches for a destination, in the same system and then through other systems. When the search fails, it clears that provisional queue before the subtraction that a successful assignment makes. A failed candidate search is therefore no sign of a demand refund, because the demand was never reduced.

A failed pickup comes later. When a ship of a civilian shipping line tries to load installations, the game clears its fleet’s move orders in three cases. These are a free cargo capacity of exactly zero, a cargo shuttle multiplier of zero at the colony (counted without maintenance facility support), and a colony stock of that installation of exactly zero. It also clears them when the calculated quantity is not positive. For ships that do not belong to a shipping line, the same failures load nothing and leave the queue alone. The pickup does not restore the route’s earlier demand reduction.

Fleet installation pickup changes cargo in one more way. For each ship of the fleet with at least one undamaged cargo hold, existing installation cargo is cleared first when the ship’s race is an NPR or the ship belongs to a shipping line. Only then does the ship try the new load. This is part of installation pickup, not a property of generic order cancellation.

The Clear Order List rule (standing order 37, IA: Clear Order List in DIM_StandingOrders) is a quirk. It clears the queue without marking the change as kept. When it runs as a conditional order, the saved orders are put back at the end of the attempt. Its name alone does not show that interrupted work was discarded.

Destination loss and ownership change

Section titled “Destination loss and ownership change”

Population deletion

Section titled “Population deletion”

Removing a colony runs these steps in order, among the other cleanup it does:

  1. Finds the contacts that represent the removed colony, remembers their contact IDs and removes those contacts.
  2. Looks at orders only on fleets of the colony’s own race.
  3. Selects an order when its colony is the removed colony, or when its destination type is Contact (stored DestinationType 6) and its destination ID is one of the removed contact IDs.
  4. For each selected fleet, clears all ship cargo when the fleet’s civilian function is Freighter or Colony Ship, then clears the fleet’s whole queue.
  5. Clears the assigned population of every fleet assigned to the colony. Later it removes the colony’s shipyards and shipyard tasks, commander assignments and ground formations, and finally the colony itself.

The order match is not “any number equal to the population ID”. It uses the colony itself or a contact ID with destination type Contact. It also does not select fleets of other races merely because their orders refer to the colony. What happens to those other routes depends on how each one later runs or loads.

Clearing all ship cargo empties the installation, trade good, component and colonist cargo and the minerals of every ship in the fleet. It does not credit a colony, undo a pickup, clear missile inventory, remove ground formations or refund planning demand. “All cargo” here means exactly those containers.

Population control transfer

Section titled “Population control transfer”

When control of a colony passes to another race, the game uses a similar contact and order cleanup, but it runs while the colony still belongs to the old owner. It first clears this colony’s own installation requests, then removes the colony’s contacts. Its order scan selects fleets of the old owner, with the same colony or typed contact match. Selected freighter and colony ship fleets lose their cargo, and every selected fleet loses its entire move queue. Near the end, the game moves the colony to the new owner’s record of the system, records the old owner as the colony’s original race (OriginalRaceID) and hands the colony to the new race. The full sequence is in colony conquest and control transfer.

This is not symmetric route compensation. Clearing this colony’s request list does not restore another colony’s matching request that was already reduced. The cleanup makes no adjustment to partner requests. A generic queue clear alone also does not destroy cargo. The cargo loss comes from the separate freighter and colony ship step above.

Fleet destination removal

Section titled “Fleet destination removal”

Removing a fleet stops before deletion when a shipyard task refers to the fleet, or when a colony has the fleet as its destination for space station construction or for fighter factory construction. The three guards can show “Cannot delete this fleet as there are related shipyard tasks”, “Cannot delete this fleet as it is the destination for space station construction tasks” and “Cannot delete this fleet as it is the destination for fighter factory construction”. The message appears only when a player deletes the fleet in the Naval Organization window. Removals the game starts show no message. The guards apply either way. When removal is allowed, the game deletes the fleet’s sub-fleets, clears the anchors of fleets and sub-fleets anchored to it and removes its ships before it looks at incoming orders.

Incoming order test Cleanup result
Destination type is Fleet (stored DestinationType 10), the destination ID equals the removed fleet’s ID, and the action is none of Tractor Specified Ship (159), Tractor Any Ship in Fleet (220) and Absorb (121) Selected.
Same destination type and ID and one of those three actions, but the X or Y coordinate of the ordering fleet differs from that of the removed fleet Selected.
Same destination type and ID, one of the exempt actions, and equal X and Y coordinates Left out of this cleanup. The test has no same-system condition.
The selected order belongs to an NPR fleet That fleet’s whole queue is cleared.
The selected order belongs to a fleet that is not an NPR Its orders with a MoveOrderID greater than or equal to the matched order’s MoveOrderID are removed.

Trimming for fleets that are not NPRs compares numeric order IDs, not sort positions (the MoveOrder column). It also removes the matching order itself. This difference matters after orders are reordered or copied. Trimming does not retarget an order to a surviving merged fleet and does not return cargo. Orders with another destination type fall outside this selection even when their numeric destination ID happens to match.

The travel step of fleet movement separately checks that a fleet destination exists and is in the same system. Either failure logs an Orders Not Possible event (event type 42 in DIM_EventType) saying that the destination fleet of the moving fleet cannot be found, or is in a different system, and asking for new orders. The fleet then uses up its remaining movement time for the sub-pulse, its queue is cleared and the current order is marked completed. This is a later guard during execution. It does not mean that every order aimed at a deleted target is removed at once.

Fleet membership changes

Section titled “Fleet membership changes”
Transition Queue and work ownership Cargo and reservation consequence
Moving one ship to another fleet Changes the ship’s fleet. Does not copy the source fleet’s move orders to the target The same ship and cargo containers survive. The next queued capacity scan sees the changed membership.
Moving a group of ships between fleets Moves each requested ship in turn, then sets both fleets’ speeds to their maximum speed No order migration for the group and no installation demand adjustment.
Detaching ships by category Refuses with an Orders Completed event (event type 45) when no ship qualifies or when every ship would leave. Otherwise creates a new fleet and moves the matching ships The source queue stays with the source fleet. The new fleet is not given a copy of the logistics route.
Absorbing a fleet Moves the source ships into the receiving fleet, then removes the source fleet from the game’s fleet list The receiving fleet’s queue is not replaced by the source queue. The source fleet’s orders leave the reservation scans with it.

The organisation side of these moves is in moving ships and sub-fleets, join and absorb actions and category detachment.

Moving a ship also handles parasites, shipyard tasks and tractor links. Whether tasks are cancelled depends on the kind of transfer. Ordinary moves between fleets keep tasks, and an ownership change cancels them. When tasks are kept, the ship’s shipyard task moves to the new fleet, and a ship it tows follows it into that fleet. When tasks are cancelled, the shipyard task is deleted and the tow link is released. When the moved ship tows nothing, a ship towing it from another fleet loses the tow link. This choice governs tasks and some towing behaviour. It does not move order progress. When the source fleet is left empty and the transfer asks for an emptied source to be removed, the game runs the full fleet removal. Its guards and incoming order cleanup from fleet destination removal still apply.

Changing a ship’s owner has one more explicit cargo effect. The ownership change gives the ship its new race, species and class, and removes it from its shipping line. Ground formations of the old race aboard go to an old-race colony at the ship’s location when there is one and are deleted otherwise. The game then clears the ship’s trade good cargo before moving the ship with tasks cancelled. That clear covers trade goods only. It does not extend to installation, mineral, component or colonist cargo. A receiving fleet may be created. The ship move does not carry over the old fleet’s queue. The order of these steps is in shared ship transfer order.

For a cargo operation that has already arrived, the remaining timer belongs to the fleet’s order. The actual pickup goes through the ships that are in the fleet at that moment and have undamaged cargo holds. Moving ships does not recalculate the source order’s TimeRequired. Moving ships during a pending operation therefore changes who takes part in the eventual transfer, without giving each ship a share of the time already spent. This holds for these membership changes and the ordinary cargo handling.

Free capacity reservation arithmetic is not a cargo conservation rule. A loaded ship can add less free capacity than it did at assignment, a detached ship counts toward its new fleet, and each matching order counts its fleet’s ships on its own. Physical stock and cargo and the calculated route reservations have to be looked at separately.

Partial work and reload

Section titled “Partial work and reload”

Ordinary installation and trade good cargo operations first count down their timer. On arrival, a load order sets TimeRequired from the load time and an unload order from the unload or transfer time, and the order is marked arrived. The countdown works like this. If TimeRequired is greater than the elapsed seconds, it drops by the elapsed seconds and no seconds are left over. Otherwise TimeRequired becomes 0 and the seconds left over are the elapsed seconds minus the old TimeRequired. The actual load or unload runs only when the seconds left over are strictly positive. When the budget equals the remaining work, TimeRequired becomes zero but no seconds are left over, so that pass does not move cargo yet. Time already spent is a timer reduction, not installations loaded a little each second. The countdown rule is also described in partial timers and persistent actions.

Load All Minerals Until Full (move action 223) is a different persistent cycle. After each attempt, when free cargo capacity remains, it recalculates the load time and uses up the rest of the pass. It completes only when the fleet’s free cargo capacity is 0. Minerals loaded in earlier attempts stay aboard as physical cargo between attempts. Fuel, MSP and ordnance transfers instead work against time and rate budgets. Their work does not follow the ordinary cargo countdown. See cargo capacity support and operation timing.

Saved state Reload behaviour Interruption consequence
FCT_PopInstallationDemand Restores the decimal Amount and the Export and NonEssential flags when the installation (InstallationID) and the colony (PopulationID) exist A request already reduced is saved as reduced. Reload does not rebuild the amount it had before assignment.
FCT_MoveOrders Restores Arrived, TimeRequired, OrderDelayRemaining, the quantities and the sort position (MoveOrder). Rows load in sort order. A row needs a valid owning race, fleet and start system, and every positive PopulationID, NewSystemID and NewWarpPointID must resolve A missing linked colony discards that order row. It does not refund a partner’s demand.
FCT_ShipCargo Needs the ship (ShipID). Restores physical cargo of each kind and its amounts Cargo and queue can survive independently. A missing starting colony can leave supported cargo loaded with no starting colony recorded.
Ship ordnance transfer credit Not among the ship’s saved values in FCT_Ship. A loaded ship starts with new values Reload loses the work credit built up while the game ran. Missile inventory already transferred is a separate saved store.

For cargo, the starting colony (StartingPop) is attached only when that colony exists, in the colonist, installation, component and trade good cargo types. Other conditions still apply. Colonist cargo needs its species (SpeciesID), component cargo needs its component and trade good cargo needs its trade good. Not every malformed cargo row is guaranteed to load.

Order destination and item IDs (DestinationID, DestinationItemID) are copied after the linked object checks. Not every destination or item gets an existence check at that point. The completed mark is not among the saved order columns. MinQuantity is saved as a number but loads back rounded to a whole number, an exact half going to the even neighbour, so a fractional threshold held in memory does not survive. Reload is therefore not an exact continuation of every flag the game held while running.

Loading installation requests, orders and cargo has no reconciliation pass. Nothing matches an installation request debit to a restored route and reverses the debit when the route was skipped. This describes loading only, not every later strategic or player action.

Worked interruption examples

Section titled “Worked interruption examples”

These scenarios are constructed from the rules on this page. They were not reproduced in a game database. Assume valid supporting objects and no unrelated side effects.

Scenario Ordered observations
Installation job cancelled before pickup Source export request 20, destination import request 12. Fleet capacity 1,000 tons and 100 cargo points per unit. Assignment subtracts 10 from each, giving 10 and 2. Clearing the orders removes the job but leaves those amounts. No physical stock moved through that clear.
Source exhausted before civilian pickup The same job is assigned. Another operation uses up the source stock. Pickup sees exactly zero installations, clears the shipping line fleet’s queue and loads nothing. The pickup does not reverse the request reduction.
Partial timer cancelled An installation order has 90 seconds remaining. A 30-second pass leaves 60 with no pickup. A generic clear discards that order, and existing cargo stays as it was. A replacement order does not inherit those 30 seconds through the clear.
Timer reaches exact zero, then reload A timer of 60 receives 60 seconds. Zero remains, but no ordinary cargo transfer runs. Saving and loading keeps Arrived and a TimeRequired of zero. A later positive budget lets the transfer run, subject to the stock and support at that time.
Ship detached while order remains A matching queued trade load first sees two empty 500-ton holds. One ship moves to a new fleet without a copy of the queue. The next scan of the old order sees only the ships still in its fleet. It does not keep the original 1,000-ton claim.
Colony removed while a civilian route references it The fleet’s race matches the colony’s race and one queued order names the colony. Deletion clears the fleet’s entire queue and the listed cargo containers, including cargo for another stop. It does not deliver that cargo to the deleted colony.
Removed fleet targeted by reordered player queue A matching Fleet-target order with ID 100 has sort position 3. Another order with ID 150 has sort position 1. Trimming every order with an ID of 100 or more removes both, whatever their sort positions. An exempt tractor or absorb order at the same coordinates is not selected in the first place.
Surviving cargo, skipped order on reload A cargo row’s ship survives but its starting colony (StartingPop) does not. The installation cargo can load without that link. A move order row whose positive PopulationID is missing is skipped. These separate load steps do not recreate the missing destination.

Limits

Section titled “Limits”

The rules on this page cover the cancellation, removal, transfer, timer and reload steps described above and the movement and load steps that follow them. They do not list every window button, every destruction or capture variant, the consequences of damaged holds or the lifecycle of alien contacts. In particular, the race filter of colony cleanup leaves routes of other races outside its immediate cleanup. The outcome of each such route depends on its typed destination, its arrival state, later movement processing and the links that survive. Removing an object does not by itself imply any general automatic cleanup.

These operations are separate changes made one after another. Each operation catches its own errors, shows a function error message and stops there. The steps inside one operation share that catch, so an error part way through leaves the earlier changes in place and skips the later ones. Queue creation, demand debit, physical pickup, delivery and ship membership change are not one atomic transaction with each other or with a save. For the transaction and error boundaries of saving, see saving, loading and reconstructing references.

Concept map

Section titled “Concept map”

Resources

Section titled “Resources”

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