Objects and capture

Section titled “Objects and capture”

A movement order template is a saved copy of a fleet’s queued movement orders that another fleet can take over. Movement and logistics covers queue execution, repeats and cycling, standing orders and the cargo formulas. Logistics interruption and reservations covers what cancelling work leaves behind. Object identity and reload explains how IDs are handed out and how links between objects are rebuilt, and game time and state refresh owns the pulse schedule.

The game keeps every template in one list, keyed by template ID. Each template holds its owning race, a starting system, a name and a list of order rows. Each row holds the settings of one order and a link back to its template. A template is not a saved fleet and not a ship list.

The starting system is stored as the race’s own record of that system, called the system record on this page. Every race keeps a separate record for each system it knows.

Create Template, on the Movement Orders tab of the Naval Organization window, needs a selected race and a selected node in the fleet tree. It opens a name prompt, “Enter New Order Template Name”, with “New Order Template” as the default text, and goes on only when the prompt is not cancelled. It then takes the next order template ID, records the race of the fleet and the system record of the fleet’s current system, adds the template to the game’s list, and copies the fleet’s current queue into it.

Capture detail Behaviour
Starting system The system the fleet is in now, not the system where its queued route ends.
Owner The race of the selected fleet, not the race selected at the top of the window.
Name The text from the name prompt. Names need not be unique.
Empty queue Not rejected. A named template with no rows can be created.
Which orders The orders in the fleet’s queue now. Orders already completed or removed are not recovered.
Row order Each order’s queue position (MoveOrder in FCT_MoveOrders) is stored as the row’s MoveIndex. Capture does not renumber.
Capturing twice Capture adds rows to whatever the template holds and does not clear it first. Create Template always captures into a new, empty template.

Capture creates new rows. Links to other game objects (the population, the move action, the new system and the new jump point) point at those same objects. A later change to a number in the original order does not reach the captured row. A change to a referenced population still concerns that same population. Applying the template creates new orders aimed at the same targets.

UI eligibility and starting systems

Section titled “UI eligibility and starting systems”

On the Movement Orders tab, choosing the Order Templates option (next to System Locations and Autoroute by System) fills the destination list from the selected fleet’s current system record. The list clears its old entries, shows the templates whose starting system record is that same record, and sorts them by name. It does not use the system the fleet will reach after its existing orders.

The list has no separate test of the template’s race. Ownership works through the system record, which belongs to one race. Another race’s template for the same star system holds that race’s record and does not match. This is not a match on the system ID that all races share. The stored owner is also used to find the system record again when a game is loaded.

Window action or condition Result
Create Template with no race or no tree node selected A message asks for the missing selection (“Please select a race” or “Please select a fleet”).
Create Template with a tree node that is not a fleet Message “Current selection is not a Fleet”.
Create Template from a fleet with no movement orders Allowed.
Create Template from a queue with actions that are otherwise restricted Allowed. Capture excludes no action family.
Apply with no race, no tree node or no template selected The general movement order check refuses (“Please select a race”, “Please select a fleet” or “Please select a destination for the move order”).
Apply to a tree node that is not a fleet Nothing happens.
Apply to a fleet with a ship in a shipyard Refused with “Orders cannot be assigned to a fleet which contains ships in a shipyard”, before the template is used.
Apply to a fleet with an active mobile shipyard task Refused with “Orders cannot be assigned to a fleet that contains an active mobile shipyard”, before the template is used.
Apply to a fleet with a civilian function Refused with “Orders cannot be assigned to a civilian or computer-controlled fleet”.
Apply when an order to transit an unexplored jump point is already queued Refused with “Fleet cannot receive further orders if already ordered to transit an unexplored jump point”, even though applying the template would replace the queue.
Apply to a fleet with an ordinary queue Allowed. The existing queue is replaced. The fleet does not need an empty queue.

Selecting a template clears the list of available actions and hides the order parameter boxes. Add Move, or a double click on the template, then replaces the fleet’s queue with the template, refreshes the queue display and switches back to System Locations. The window does not build each row from a selected action and quantity, as it does for an ordinary order.

The fleet checks above therefore do not prove that every saved action still suits the receiving ships or the destination. Replacement does not check ship capability, ownership, target existence or the recorded starting system. The starting system rule is applied when the template list is filled, not by the replacement itself.

Delete Template needs a selected race, a selected fleet, the Order Templates option and a selected template. The messages are “Please select a race”, “Please select a fleet (to set the starting system for templates)”, “Please select a an Order Template” (the game’s own wording) and “Please select a template”. A confirmation box titled “Confirmation Required” asks “Are you sure you want to delete” followed by the template name. On Yes, and while the template is still in the game’s list, the game removes it and refills the list for the fleet’s current system. Orders already applied to fleets stay, because they are separate orders.

Replacement and copied state

Section titled “Replacement and copied state”

Applying a template first empties the fleet’s order queue, so a whole template replaces the queue. It then sorts the template’s own rows by MoveIndex and appends each row to the emptied queue as a new order with its stored position. A row is not renumbered to follow the end of the queue.

State From source order to template row to applied order
Order identity The source order ID is not captured. Every applied row takes a fresh move order ID.
Queue position Source position (MoveOrder) to row MoveIndex to applied position, with gaps kept.
Fleet The applied order belongs to the receiving fleet.
Race The applied order takes the race of the row’s start system record, not the race of the receiving fleet.
Start system The source order’s start system record (StartSystemID) is copied to the row and used again on application.
Destination DestinationType, DestinationItemType, DestinationID and DestinationItemID are copied unchanged.
Linked objects Population (PopulationID), move action (MoveActionID), new system (NewSystemID) and new jump point (NewJumpPointID) are copied as links to the same objects.
Quantities and distances MaxItems, MinQuantity, MinDistance and OrbDistance are copied unchanged.
Configured delay OrderDelay is copied.
Remaining delay The source remainder is not copied. The applied order sets OrderDelayRemaining equal to OrderDelay.
Survey work SurveyPointsRequired is copied as it stands now, including a partly used value.
Troop option LoadSubUnits is copied.
Text MessageText and Description are copied.
Arrival and completion Not captured. A new order starts with Arrived off and not completed.
Operation timer TimeRequired is not captured. A new order starts at 0.

Applied rows enter the queue under their fresh order IDs. Each sub-pulse the movement step takes the fleet’s orders sorted by queue position (MoveOrder), lowest first, not by ID.

Emptying the queue this way differs from the full clear that other order actions use, which also resets the fleet’s conditional diversion state to none and, for an NPR fleet, clears its redeployment flag and redeployment target system. Template application does not use the full clear. Fleet-level values are not reset by the template.

Destinations progress and fleet settings

Section titled “Destinations progress and fleet settings”

Templates keep the recorded destinations. Capture and replacement do not translate them to the receiving fleet’s location, pick an equivalent colony, move jump points to new ones or rebuild an auto-route. A queue that crosses systems keeps the start system and new system of each order and its jump point links. Moving the source fleet later does not rewrite the saved template or its rows.

State outside a single order Template effect
Receiver’s current system and coordinates Not changed by application.
The fleet the receiver is anchored to, and its anchor position Not set by application.
Ships, cargo, fuel and stocks Not captured or transferred.
Cycle Moves (CycleMoves) Not captured from the source and not set on the receiver. The receiver keeps its own setting.
Standing and conditional rules Not captured or replaced.
Conditional diversion state Not cleared by application.
Auto-route and Lagrange preference The fleet’s Auto-include Lagrange Points setting is not used to rebuild template rows.
Repeated queue entries Repeated entries are copied as separate rows. The repeat request that made them is not saved.

A partly done timed operation must reach its destination again through the normal arrival path, where it can receive a newly calculated timer. A load order, for example, sets TimeRequired from the fleet’s load time when it arrives (see fixed-duration loading and unloading). It does not inherit the old TimeRequired. Survey work is the exception to a blanket “all work resets” rule. Survey work subtracts the points done in each step from SurveyPointsRequired, and capture copies that column as it stands. For a geological survey, the points done in a step are the fleet’s geological survey sensor capacity, times the survey bonus of its admin command for that system, times Survey Speed (SurveySpeed in FCT_Game) divided by 100, times the seconds worked divided by 3600. The survey rate has its own section.

Standing order templates are a separate feature. Their Create Template button stores standing and conditional rule lists on a race. A movement order template holds none of those rules.

Persistence and missing references

Section titled “Persistence and missing references”

Saving deletes the current game’s rows from FCT_OrderTemplate and FCT_MoveOrderTemplate, then writes the templates the game holds now. The header columns are GameID, OrderTemplateID, RaceID, StartSystemID and TemplateName. StartSystemID holds the system ID of the starting system record. Each row stores the ID of its template (OrderTemplateID) and its MoveIndex. Rows have no ID of their own.

A row stores MoveActionID, StartSystemID, DestinationType, DestinationID, DestinationItemType and DestinationItemID. It also stores the optional PopulationID, NewSystemID and NewJumpPointID, the quantities and distances (MaxItems, MinQuantity, MinDistance, OrbDistance), OrderDelay, SurveyPointsRequired, Description, MessageText and LoadSubUnits. Each optional link ID is set to 0 for every row and replaced only when that row has the link. No source order ID, arrival flag, remaining delay or operation timer is written to the template tables.

Condition when a game is loaded Template result
Header race not present Template not added.
Header StartSystemID not among the owner race’s system records Template not added.
Row’s template not present Row skipped.
Row StartSystemID not among the owner race’s system records Row not added.
Row NewSystemID not found Row can load with no new system.
Row NewJumpPointID not found Row can load with no new jump point.
Row PopulationID not found Row can load with no population.
Row MoveActionID has no move action The game shows error Function #1169 and the template row load ends there, so rows after the failing row are not loaded. There is no fallback for the single row.
DestinationID and DestinationItemID Kept as stored. Template loading does not check that the destination exists.

When a game is loaded, templates are read before their rows. Rows are read in no particular order, but application sorts them by MoveIndex. MinQuantity holds a decimal during play, but loads back rounded to a whole number, an exact half going to the even neighbour. MaxItems and SurveyPointsRequired keep their decimals. A fractional minimum quantity, which the window does not offer, is therefore not guaranteed to survive a reload.

Reloading an active queue differs from applying a reloaded template. Active orders are read from FCT_MoveOrders in queue position order and keep their order ID, remaining delay (OrderDelayRemaining), TimeRequired and Arrived. An active order is skipped when its NewSystemID, NewWarpPointID or PopulationID is above 0 and does not resolve. A template row with the same missing links can still load without them. Neither process repairs stale targets in general.

Template IDs use their own counter. When a game is loaded, the counter starts at the highest OrderTemplateID in FCT_OrderTemplate, and each new template takes the next number. Fresh applied order IDs come from the separate move order counter. These IDs identify objects in the running game. They are not guaranteed unique across deleted database rows or restored saves, as identity namespaces and counter scope explains.

Cargo and interruption consequences

Section titled “Cargo and interruption consequences”

Replacing a queue drops the old orders from the receiving fleet at once. Template application does not reverse installation request reductions, unload cargo, copy the source fleet’s cargo or reconcile the old job with the new rows. Cargo already in the holds stays in the ships until another mechanic changes it. When a freighter is assigned an installation job, the supplying colony’s request and the receiving colony’s import request each drop by the fleet’s free cargo capacity divided by the installation’s CargoPoints. Installations are physically picked up later, when the load order runs at the colony.

Trade good planning counts queued orders and current free fleet capacity. Load capacity already queued for a colony and good is the free cargo capacity of the ships of every fleet with a matching Load Trade Goods order for that colony and good, divided by 2,500 tons per trade good and rounded down. Queued unload capacity at a receiving colony is counted the same way from Unload Trade Goods orders. Replacing a queue changes what the next count sees. Applying a template does not create a reservation of its own. An installation request already reduced when the route was assigned lasts differently. Removing that route does not itself add the amount back. Cancellation and replacement gives the details for every way of cancelling.

Worked examples

Section titled “Worked examples”

Normal reuse. Fleet A in system record S has two orders with queue positions 3 and 7, a load at colony P and an unload at colony Q. Capture records S as the starting system and keeps positions 3 and 7. Fleet B in the same system record can select the template. Applying it replaces B’s ordinary queue with two orders under new IDs, keeps positions 3 and 7, targets P and Q, and leaves B’s ships and cargo as they were. B keeps its own Cycle Moves setting.

Partial work. A source order has delay 600, remaining delay 90, Arrived on and TimeRequired 240. Capture and application give an order with configured and remaining delay 600, Arrived off and TimeRequired 0. The 240-second timer does not resume. If a survey row’s requirement has already fallen from 100 to 35, capture keeps 35. These columns are copied by different rules.

Reload with a lost population. A saved row refers to population P, but P is gone when the game is loaded. As long as its template, start system and move action resolve, the row loads with no population and keeps its numeric destination columns. Applying it does not find a substitute colony. An active order in the same state is skipped instead, because its PopulationID is above 0 and does not resolve. This is a difference in how the two are rebuilt. It does not mean the stale template order would run successfully.

Wrong system and empty capture. A template captured in system record S does not appear in the list for a fleet in another system T, even when that fleet’s queued route ends in S. The starting system rule is applied when the list is filled, not by the replacement. Replacement itself keeps the recorded anchors wherever it is applied. An empty template captured in S can be selected there, and applying it empties the receiving fleet’s queue. A fleet already ordered through an unexplored jump point is refused by the window before either replacement.

Limits

Section titled “Limits”

Errors during replacement are reported, not undone. Replacement empties the queue before it builds any row. An error during replacement shows error Function #2080 and ends the replacement step. The old queue is not restored. Each row is added on its own, and an error while adding one row shows error Function #2082 and skips that row, after which the next row is tried. An error during capture shows error Function #2081 and ends the capture step. Rows already copied stay in the template. Replacement is therefore neither all-or-nothing nor rolled back. Later execution still depends on the receiving fleet’s capabilities and on the state of the targets.

Concept map

Section titled “Concept map”

Resources

Section titled “Resources”

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