Design capability and independent live state

Section titled “Design capability and independent live state”

A ship design describes what a ship could do. Live readiness decides what it can do now. Readiness is a collection of independent conditions. They are crew and officers, deployment and morale, maintenance age and state, damaged components, repair queues, fuel, maintenance supplies (MSP), ammunition and weapon recharge debt. The game does not combine these into a single readiness score anywhere in the rules described here. Formulas on this page keep the game’s exact arithmetic, including whole-number truncation, the order of steps and unusual edge cases. Examples use synthetic inputs.

Commander recruitment, promotion and retirement as a whole belong to the commander lifecycle page, which also owns the commander side of crew training and academy grade in crew grade and academy crew. Combat attack and penetration rules belong to space combat resolution. Ship and station design owns class assembly, quarters allocation and design maintenance-life estimates. Production owns resource manufacture and consumption accounting. Movement and logistics owns travel and physical transfers. Power and detection owns recharge and sensor equations. The sections below connect those systems to live readiness and recovery.

Axis Design or definition Live ship state and consequence
Installed capability Installed class components (FCT_ClassComponent), decimal installed quantities and component values Damaged-component records (FCT_DamagedComponent) subtract whole instances. Many capacities are worked out on demand from the undamaged count.
Crew Class Crew, ConscriptOnly, quarters, PlannedDeployment CurrentCrew, GradePoints, CrewMorale, assigned commanders and LastShoreLeave affect different consumers.
Maintenance Engineering, maintenance storage, commercial classification LastOverhaul sets maintenance age. MaintenanceState gates activities. OverhaulFactor multiplies selected capabilities.
Repair Engineering and damage-control modules and component cost Damaged-component records, armour damage, AutomatedDamageControl and the ordered damage-control queue decide recovery attempts.
Stores Fuel, MSP and magazine capacities Fuel, CurrentMaintSupplies and magazine ordnance are stocks. An intact empty tank or launcher is still empty.
Combat timing Reactor, weapon recharge rate, launcher rate of fire Weapon recharge debts, FireDelay, SensorDelay and current shields stay separate from component condition.

A ship’s undamaged count for a component is whole-number(installed quantity) - Number, with Number taken from the matching FCT_DamagedComponent record. The game does not clamp that result. Live capacity for a component type is sum(undamaged count x ComponentValue) over its components. Four types use a race rate per undamaged module instead. Terraforming Modules use the race terraforming rate, Sorium Harvesters the race fuel production rate, Maintenance Modules the race MaintenanceCapacity and Orbital Mining Modules the race mining rate. Design totals and current capacities can therefore disagree while the ship’s class stays the same.

Commander bonuses apply to capacity only for selected modules, and only in the checks that include commander bonuses. When the ship has a commander and the capacity is above 0, Transfer - Cargo / MSP capacity is multiplied by the commander’s Logistics bonus. Gravitational and geological survey sensors are multiplied by the ship’s effective Survey bonus. Salvage Modules use the Production bonus. Sorium Harvesters and Orbital Mining Modules use the Mining bonus. Terraforming Modules use the Terraforming bonus. Geological and gravitational survey capacity is then multiplied by CrewMorale. When CurrentCrew is below the required class Crew, survey, harvesting, terraforming, mining, salvage and maintenance module capacity is multiplied by the decimal fraction CurrentCrew / Crew. In the checks that leave bonuses out, none of these adjustments apply. Engines, reactor generation and ordinary sensors are not multiplied by crew fraction or crew performance. A maintenance location cluster counts undamaged Maintenance Modules directly, so the bonus-adjusted module capacity is not the cluster’s formula.

A new ship starts with full nominal crew, morale 1, LastOverhaul and LastShoreLeave set to the current time, automated damage control on, zero current shields and shields inactive. A class with ConscriptOnly = 1 starts at GradePoints 0. Other ships use the initial grade the construction supplies. When the fuel fill option is set or the race is an NPR, the ship starts with full FuelCapacity. Otherwise it draws fuel from the building population’s stockpile, only up to MinimumFuel for a fuel tanker and up to FuelCapacity for any other class. MSP works the same way, with a full MaintSupplies load when the fill option is set or the race is an NPR, and otherwise whatever the building population’s stockpile can supply up to MaintSupplies. A newly created intact ship is therefore not necessarily fully provisioned.

Crew grade officers and training

Section titled “Crew grade officers and training”

Performance and distinct officer consumers

Section titled “Performance and distinct officer consumers”

For grade points G, morale M and overhaul factor O:

grade bonus percent = round((square root of G) - 10)

crew performance = (1 + grade bonus percent / 100) x M x O

The square root and rounding use floating-point arithmetic. The grade multiplier is converted to a decimal before the morale and factor multiplication. G=0 gives -10%, G=100 gives 0%, and G=400 gives +10%. Crew performance feeds maintenance failure exposure, fleet training and jump shock, among other uses.

Tactical effectiveness has its own formula:

tactical effectiveness = (1 + grade bonus percent / 100) x M x O x ship commander half Tactical bonus x tactical officer Tactical bonus x M

A half bonus is 1 + (bonus - 1) / 2. An absent officer’s multiplier is left out. Morale therefore appears twice. Tactical effectiveness uses the assigned officers directly. It does not use the general effective commander bonus described below, so that bonus cannot be used to reproduce combat values.

The tactical effectiveness value is calculated in floating point. Combat does not calculate it on the spot. Each ship keeps a tactical effectiveness value that is updated together with its effective maximum speed. It starts at 1.0. The combat pass refreshes every ship in a system that has a ship ready to fire, a ship ready for point defence or a ready surface-to-orbit (STO) element. Point-defence allocation refreshes the salvo target ships and the eligible point-defence ships again. The NPR estimate of local point-defence shot capacity also refreshes the NPR’s own ships at the target position. NPR combat targeting uses the kept value without updating it. The kept value multiplies beam and CIWS hit chance, is passed into missile salvo creation and missile hit chance, and scales a ship’s ground attack hit chance.

The general effective commander bonus counts undamaged Command and Control capacity as a whole number. A ship of 20 HS or less counts one command capability when this is zero. The Engineering bonus uses a chief engineer only when the ship has an undamaged Main Engineering component, then multiplies by the ship commander’s half Engineering bonus when command capability exists. Survey, carrier operations and tactical bonuses have their own department gates in the same pattern. Survey needs an undamaged Science Department for the science officer. Carrier operations needs an undamaged Primary Flight Control for the CAG. Tactical needs an undamaged Combat Information Centre for the tactical officer. Ground support follows the tactical pattern, using the tactical officer behind the Combat Information Centre gate, and it also needs command capability. Crew Training uses the executive officer when command capability exists, plus the ship commander’s half bonus. An intact officer assignment alone does not establish every effective departmental bonus.

Grade growth and fleet training

Section titled “Grade growth and fleet training”

Commander training in each construction cycle checks assigned ship commanders and executive officers separately. Each needs a personal Crew Training bonus above 1, a ship grade below 1000, and either positive undamaged Command and Control capacity or a ship of 20 HS or less. The personal bonus B is multiplied by the local naval administration Crew Training multiplier A, then:

Trainer Grade gain over elapsed years Y
Ship commander (B x A - 1) x 500 / 2 x Y
Executive officer (B x A - 1) x 500 x Y

Each pass caps the resulting grade at 1000. There is no matching lower clamp. This direct training is separate from the effective Crew Training bonus above. The commander-side view of this training and of academy grade on new ships is in crew grade and academy crew.

Commander training has no morale, fuel, commercial, conscript or maintenance-state gate. An administration bonus needs an effective assigned commander whose command range covers the fleet’s system. Its value is 1 + (commander bonus - 1) x command type weight for that bonus. The fleet training weight reads that commander’s Crew Training bonus. Combat also awards grade when a hit is not fully absorbed by shields. The gain is the remaining decimal damage x 100 / class size, divided by ten for commercial ships. This gain has no training-style 1000 cap.

Fleet training points, TFPoints, are a separate quantity displayed as round(TFPoints / 5)%. Active fleet training selects noncommercial ships in fleets under a Training admin command and not under maintenance. It skips a ship with Fuel below 1 when its class MaxSpeed is above 1, and ships referenced by any shipyard task, including paused tasks. Gain is (admin fleet training multiplier x crew performance - 1) x 1000 x Y, with an upper cap of 500. Negative active gain is possible and no floor is applied. A separate passive pass then adds 30 x Y x crew performance to every player noncommercial ship below 500, including ships excluded from active training. Qualifying active trainees can therefore also receive passive gain in the same cycle.

Active training also burns fuel in every movement and combat subpulse. For the training selection outside maintenance, the game sets current engine power to 10% of undamaged engine power and subtracts power x class fuel efficiency x seconds / 3600, stopping fuel at zero. The fuel burn does not repeat the shipyard-task exclusion from the point gain. Training also speeds up deployment and maintenance clocks and doubles maintenance failure exposure, as described below.

Grade bonus and crew performance

Section titled “Grade bonus and crew performance”

The grade bonus percent is round((square root of GradePoints) - 10). No clamp applies. Rounding sends an exact midpoint to the even whole number. G=110.25 has a root of 10.5 and gives 0 rather than +1. G=342.25 has a root of 18.5 and gives +8 rather than +9. The training cap of 1000 gives a root of 31.62 and a bonus of +22%. Combat grade gain has no cap, so a ship can exceed +22%. The Naval Organization window ship list, the ship detail text and the commander assignment list display this percentage.

Crew performance repeats the same rounded expression. Its value is (1 + bonus / 100) x CrewMorale x OverhaulFactor. Each consumer applies the result P in its own way.

Consumer Use of P
Maintenance failure exposure Multiplies interval exposure by 2 - P.
Fleet training, active pass (admin fleet training multiplier x P - 1) x 1000 x Y.
Fleet training, passive pass 30 x Y x P.
Jump shock Multiplies the jump shock fire delay by 2 - P.
Ship ground attack Multiplies the ground attack hit chance out of 10000 by P.

Because P includes OverhaulFactor, a ship that has just left overhaul manually has P near .01 until its factor recovers. Its maintenance exposure and jump shock are then close to doubled, and its active training gain is negative.

Fleet training pass order

Section titled “Fleet training pass order”

Fleet training runs once per construction cycle, directly after commander crew training, with the cycle’s elapsed years. It collects every fleet whose parent admin command type is Training, for all races. The active trainee filter has no NPR test, so NPR ships under a Training command gain active points, while the passive pass excludes NPR ships. Automated race creation gives NPRs only General commands, so an NPR trainee needs a Training command created or retyped in the Naval Organization window.

For each active trainee the pass applies these steps in order. It skips the ship silently when Fuel is below 1 and class MaxSpeed is above 1. It skips the ship with a Training not Possible event (event type 318 in DIM_EventType) when any shipyard task references it. The event says the ship is in a shipyard and will not benefit from fleet training. Otherwise it adds the gain. A result above 500 logs a Maximum Fleet Training event (event type 290) and sets TFPoints to 500. The passive pass then selects ships with TFPoints below 500. A trainee capped at exactly 500 therefore gets no passive gain that cycle. The passive cap logs no event.

The admin multiplier starts at 1. It changes only when the fleet’s system is within command range and the command has an effective commander. For fleet training it is 1 + (commander Crew Training bonus - 1) x FleetTraining weight, with the weight read from the command type’s FleetTraining value in DIM_NavalAdminCommandType (1 for Training, 0.1 for General and 0 for every other command type in the game database as shipped). When the command applies its own bonus, a parent command multiplies in its own multiplier, evaluated at the child command’s headquarters system. With a multiplier of 1 the active gain is (P - 1) x 1000 x Y. That gain is zero at P=1 and negative below it. A Training command without an effective commander therefore adds active points only to a ship whose P exceeds 1, which needs a positive grade bonus with morale and factor near 1.

Training fuel

Section titled “Training fuel”

The training fuel burn is the first step of each movement, logistics and combat subpulse, before tanker refuelling and movement. It uses the same Training fleet and trainee filters as the point pass, without the fuel or shipyard tests. A ship whose undamaged engine power, counted without commander bonuses, is zero is skipped. For any other ship the game sets current engine power to 10% of that power. It then subtracts current engine power x class FuelEfficiency x subpulse length / 3600 and stops Fuel at 0.

The burn ignores the ship’s RefuelStatus, its class MinimumFuel and move orders. Movement later in the same subpulse resets current engine power from fleet speed and charges movement fuel, so a training fleet that also moves pays both charges in the same subpulse. A trainee that burns its tank below 1 stops gaining active points at the next construction cycle when its class MaxSpeed exceeds 1. It still receives passive points.

TFPoints reduce reaction delay rather than directly increasing weapon damage. A ship’s fire delay is round((1 - TFPoints / 500) x reaction delay multiplier x d10 x d10 x .5 x mode multiplier). The reaction delay multiplier is 1 - (ship commander Reaction bonus x admin Reaction multiplier - 1). The mode multiplier is .5 for the two fire-at-will modes (all fire controls and selected fire control) and 1 otherwise. When the existing FireDelay is larger and the mode is not fire at will with all fire controls, the existing delay stays. Fleet reaction delay instead uses average TFPoints and the fleet reaction multiplier. It is whole-number((1 - average TFPoints / 500) x (1 - fleet reaction bonus) x 60) seconds. The fleet reaction bonus is the average Reaction bonus of the fleet’s ship commanders (a ship without one counts 1) times the admin Reaction multiplier, minus 1, and .99 when that average product reaches 2. Both delays are zero when no hostile contact detected by the race in that system was updated at the current time.

Replacing crew

Section titled “Replacing crew”

Fleet crew replacement fills every missing berth and recomputes grade as (surviving crew x old grade + replacement grade total) / required crew. Academy crew are drawn when ConscriptOnly = 0. With enough academy stock, the replacement grade total is 100 x race TrainingLevel x missing crew. With a shortage it is 100 x TrainingLevel x available academy count, which uses up the academy stock. All missing berths are still filled, leaving the rest effectively untrained. The replacement grade total carries over from ship to ship within one fleet replacement and is not reset for a conscript ship. A later conscript hull can reuse the previous ship’s value. This is the game’s literal behaviour, not a general rule that replacement crew preserve grade.

Yard repair and refit use a different replacement grade calculation. With no academy stock the new grade is whole-number(CurrentCrew / required crew) x old grade. For an ordinary undercrewed ship that quotient is 0, so the grade becomes 0. With some academy stock but not enough, the grade is (CurrentCrew x old grade + 100 x TrainingLevel x academy stock) / required crew, and the academy stock falls to 0. With enough stock, the grade is (CurrentCrew x old grade + 100 x TrainingLevel x missing crew) / required crew, and that many academy crew are used. A negative result is raised to zero. A class’s NoOfficers flag filters automatic officer assignment and the candidate list. It is not a direct crew-grade penalty. When officers disembark from a ship, the game clears their assignments and transport. When academy credit applies and grade exceeds 100, it adds whole-number(CurrentCrew x GradePoints / (100 x TrainingLevel)) to academy crew. Disembarking does not set CurrentCrew or GradePoints to zero.

Deployment morale and shore leave

Section titled “Deployment morale and shore leave”

Time is stored in seconds. One game month is 2,592,000 seconds (30 days), one year 31,536,000 seconds (365 days). Deployment age in months is (now - LastShoreLeave) / 2,592,000. Moving LastShoreLeave forwards reduces age, and moving it backwards increases age. A class’s planned deployment is the threshold, not a consumable store.

For a Standard race and a class with nonzero planned deployment P, the morale update sets morale to 1 unless deployment D exceeds both P and .1 months. Any other race, or a class with zero planned deployment, also gets morale 1. In overrun, initial morale is P/D. If CurrentCrew is below half the required crew, the game multiplies by whole-number(CurrentCrew / required crew) x 2. The division drops the fraction before the decimal multiplication, so an ordinary positive crew below half produces zero and then the minimum morale of .25. Otherwise the overrun result is clamped only to a minimum of .25. An ordinary crew shortage within planned deployment does not enter this morale penalty. When morale was exactly 1 before an overrun update, the game logs a Deployment Time Exceeded event (event type 321).

Shore-leave processing in each construction cycle first resets every NPR ship’s LastShoreLeave to now. It then runs the ship update only for player Standard-race ships whose class planned deployment is above 0. A shore-leave location is a fleet with any undamaged Recreational Module, or a population with a total population of at least .05. The ship must match the location’s race and system and lie strictly less than 1 unit away on both axes. Ships under a Training command never match shore-leave locations. No location capacity, crew allocation or Recreational Module tonnage limit is applied.

The order of the ship update matters:

Condition, in order Timestamp and morale action Later life-support and overcrowding checks?
Class MoraleCheckRequired is false Set LastShoreLeave to now, then continue to the location test Depends on the following row.
Matching shore-leave location If morale checks apply, advance the timestamp by 10 x elapsed seconds x min(1, crew / required crew), cap it at now and recalculate morale No, the update ends. Without morale checks it ends immediately.
Mothership present If morale checks apply, ratio R = carrier deployment months / parasite planned deployment. Advance by elapsed seconds x (1 + 10 x (1 - R)) when R is below 1, otherwise by elapsed seconds. Cap at now and recalculate No, the update ends.
Training command, not under maintenance Subtract elapsed seconds from the timestamp Yes.
Independent ship thereafter Check remaining quarters, survivors and crowding Yes, details below.

The mothership ratio uses the parasite’s planned deployment as denominator. A separate step at the end of every increment advances LastShoreLeave by the elapsed seconds for every player ship that has a mothership, capped at now. That step and the construction-cycle mothership row add together when both run. They are not competing versions of one update. The shore-leave update also renames a ship called Erebus to Erebus Tested.

Fully crewed shore leave moves the timestamp ten seconds per elapsed second, so deployment age falls at a net nine seconds per second as current time also advances. An independent active trainee gets ordinary passage of time plus the backwards timestamp adjustment, doubling age accumulation before any crowding penalty.

Survivors overcrowding and life support

Section titled “Survivors overcrowding and life support”

Survivor groups, people of other races carried aboard and stored in FCT_Survivors, are separate from CurrentCrew. The excess survivor count is zero if free colonist capacity covers all survivors. Otherwise it is total survivors minus free capacity. Free capacity is the undamaged capacity of both Transport - Colonist and Transport - Passenger components, minus loaded colonists, not only cryogenic equipment. Free capacity itself is not clamped, so overloaded colonist space can make the excess greater than total survivors. The hangar allowance in this live check is 20 people per undamaged Transport - Military Hangar or Transport - Commercial Hangar component, not the design calculation of flight crew berths. Personnel needing quarters = CurrentCrew + hangar allowance + excess survivors. Required quarters = personnel x cube root of class planned deployment months x class CrewDesignEfficiency, compared with undamaged Crew Quarters capacity.

If there is no component damage and no survivor group, the update simply refreshes morale when morale checks apply, and ends. Otherwise it resets the overcrowding multiplier to 1. If the required quarters fit the available quarters, it ends without a morale refresh at that point. If quarters are insufficient, multiplier Q = (required quarters / available quarters)². The game logs a Ship Overcrowded event (event type 283) that gives the multiplier. When morale checks apply it subtracts (Q - 1) x elapsed seconds from LastShoreLeave, and it then updates morale. For Q above 1.5 it tests d10000 strictly below Q x 10000 x elapsed years. Success causes a crew quarters strain failure. These calculations apply only to ships that reach this point, not as a continuous tick for all ship types.

A strain failure picks the first undamaged quarters component, ordered by descending ComponentValue. If the ship has enough MSP it spends that one component’s Cost in MSP. Otherwise the component is damaged. Then the strain failure ends. It reads only the ship’s own CurrentMaintSupplies, not a cluster, carrier or population stock. A paid strain logs a Maintenance Problem event (event type 146). An unpaid one logs a Maintenance Failure event (event type 361) before the damage. This is a separate failure source from ordinary age-driven maintenance, and it still runs when the No Maintenance Required game rule option switches ordinary maintenance off.

Complete life-support failure is checked before crowding. The undamaged quarters count starts at 1 and is only recomputed if any damaged-component record exists. A resulting count of zero causes the following.

  • When morale checks apply, the game subtracts 12 x elapsed seconds from LastShoreLeave and sets morale to .1. The update ends after the casualties, keeping this .1 rather than immediately applying the ordinary .25 overrun floor.
  • Four d20 are rolled and summed into a casualty percentage C (4 to 80). The ship loses whole-number(CurrentCrew x C / 100), capped at CurrentCrew - 1, which keeps one crew member alive for ordinary positive crew counts. A Life Support Failure event (event type 254) reports the deaths.
  • Survivors outside available colonist space lose whole-number(group size x excess / total survivors x C / 100), capped at each group’s size. Empty groups are removed.
  • Each assigned commander has a separate death test, d100 strictly below C / 2.0. It is not the same casualty percentage as the crew’s.

These losses happen every time the check runs, without scaling the casualty percentage by elapsed years. Shore-leave and mothership early endings bypass this independent-ship check. A design without quarters does not automatically lose crew every increment, and not every biological ship follows this update.

Rescue of own-race lifepods credits academy-equivalent crew and returns surviving officers, rather than loading a survivor group into quarters. Rescue of another race’s lifepod creates or merges a survivor group on the fleet’s ship with the most free colonist capacity, without a hard capacity rejection. Landing on a carrier transfers those groups to the carrier, and an explicit survivor transfer also merges or moves them without a capacity check. Unloading prisoners merges the groups into the population’s prisoner groups and clears the ship’s groups. Landing can therefore move the crowding burden to the independent carrier, even though embarked ships skip the crowding check. Lifepods expire only in a construction-cycle expiry pass when now is strictly later than creation time + 1,209,600 seconds (14 days), so a pod at exactly that age survives until a later pass. Destruction and evacuation details are in space combat resolution. Commander deaths on ship loss and in life-support failure are tabulated in health, retirement and casualties.

Maintenance state clocks and support

Section titled “Maintenance state clocks and support”

State transitions and capability factor

Section titled “State transitions and capability factor”

MaintenanceState holds 0 for operational and 2 for under maintenance (overhaul). Maintenance age, maintenance state and OverhaulFactor are separate values. Age in years is (now - LastOverhaul) / 31,536,000. A recent LastOverhaul does not clear damaged components, and an operational state does not imply a factor of 1.

Trigger State and other changes
Begin overhaul for a fleet’s independent ships Independent noncommercial ships become under maintenance and their current shield points become zero. Commercial ships log a No Freighter Overhaul event (event type 145) saying they cannot be overhauled as commercial vessels. Embarked ships are skipped. This step does not check facilities or change factor or clock.
Supported overhaul reaches LastOverhaul = now The ship becomes operational, logs an Overhaul Complete event (event type 122) and the fleet is set to maximum speed. The factor is not reset to .01.
Leaving overhaul, including the manual Naval Organization window exit The ship becomes operational. A noncommercial ship’s factor becomes .01. The clock stays as it was. Leaving overhaul has no state prerequisite.
Subpulse with factor below 1 Add subpulse seconds / 2,592,000, capped at 1. No maintenance-state or support requirement.
No Maintenance Required game option set (FCT_Game.NoOverhauls) The construction cycle sets every ship’s LastOverhaul to now and its state to operational. Damage and factor stay separate.

Support and net age recovery

Section titled “Support and net age recovery”

Maintenance support is location capacity plus accessible MSP, not simply an onboard engineering value. Clusters are rebuilt from populations with maintenance facilities and ships with undamaged Maintenance Modules. Assignment matches race, system and coordinates within one unit. Colony and mobile-module capacity, proportional tonnage coverage, supply ordering and the precise MSP debit are documented in production’s maintenance section. How a cluster forms and which ships join it is in maintenance location clusters.

A cluster’s coverage ratio is capacity / assigned ship tonnage x race EconomicProdModifier, capped at 1, with the tonnage counted at class size x 50 tons per HS. Each assigned ship needs .25 x class Cost x elapsed years in MSP when operational, and 1 x class Cost x elapsed years when under maintenance. It asks for that requirement times the coverage ratio, and the cluster pays what its supplies allow. Let f be the actual MSP consumed divided by the full interval MSP requirement, after capacity and supply limits. Operational timestamp progress is elapsed seconds x f. Under-maintenance progress is elapsed seconds x f x 5, capped at now. Since now also advances, operational age increases by (1 - f) x elapsed seconds, and overhaul age changes by (1 - 5f) x elapsed seconds. Full support holds operational age steady and reduces overhaul age by four times the elapsed time. At only 20% coverage an overhaul clock’s age holds steady. Weaker support still lets age grow despite a forward-moving timestamp. Allocation order within a cluster is class MaintPriority ascending, then state descending (ships under maintenance first), then LastOverhaul ascending.

Special cases matter:

  • Ships in active, unpaused shipyard tasks advance LastOverhaul by the elapsed time and are excluded from ordinary maintenance. Paused tasks do not get that treatment.
  • NPR ships outside those tasks reset clock and state.
  • SupplyShip = 1 is tested before the commercial, embarked or training checks. Such a ship tries to join a cluster and is then finished. An unassigned supply ship does not take the ordinary uncovered-risk path.
  • Other commercial ships reset their timestamp. A parasite whose carrier class has CommercialHangar = false advances its timestamp by 5 x elapsed time, capped at now, bypassing clusters and ordinary failure risk.
  • Other ships under a Training command skip cluster assignment unless under maintenance. If unassigned, their risk is evaluated before their timestamp is moved backwards by the elapsed time.

These are specific maintenance rules, not a blanket exemption for every commercial, biological or parasite ship.

Maintenance location clusters

Section titled “Maintenance location clusters”

A maintenance location cluster is a temporary grouping that the maintenance pass builds, reads and replaces on its next run. The game keeps one current list of clusters. Each cluster carries the parts below.

Part Content
Race and system Copied from the contributor that created the cluster.
Anchor coordinates That first contributor’s coordinates. Every later match compares against this anchor.
Effective capacity Whole tons, the sum of each contributor’s truncated capacity.
Supporting populations Facility populations, plus the assigned population of each module ship’s fleet.
Maintenance module ships Ships whose undamaged Maintenance Modules contributed capacity.
Assigned ships Ships whose tonnage the capacity must cover.
Supply ships SupplyShip = 1 ships whose MSP the cluster may draw.
Assigned tonnage and coverage ratio Written by the maintenance pass for a cluster with assigned ships.

A cluster has one action of its own, drawing maintenance supplies for a ship. Its draw order and the supply-ship shuttle bay condition belong to production’s maintenance section.

Building clusters

Section titled “Building clusters”

A rebuild, for one race or for all races, clears the list and adds contributors in two passes. The first pass takes every population whose maintenance facility production capacity is above 0. The second takes every ship with at least one undamaged Maintenance Module. The ship pass does not exclude ships by maintenance state, shipyard task, commercial status or NPR status, so a module ship under overhaul or in a yard still contributes. Populations go first, so a module ship near a facility colony joins the colony’s cluster instead of anchoring its own.

A population looks for the first cluster of the same race whose anchor is within one unit of the population’s coordinates. That test is strict, the difference on x below 1 and the difference on y below 1. It does not compare systems. With no match the population creates a cluster anchored on itself. It then adds whole-number(facility capacity x race MaintenanceCapacity x population Efficiency x radiation production modifier x stability x political status ProductionMod) to the capacity, and joins the supporting populations. The political status modifier is described on its own page.

A module ship applies the same race and anchor test to its fleet’s coordinates, again without comparing systems. With no match it creates a cluster anchored on the fleet. It adds whole-number(undamaged module count x race MaintenanceCapacity) and joins the maintenance module ships. If the fleet has an assigned population that is not yet among the supporting populations, that population is added. No distance, system or stock test applies to it.

Four consequences follow.

  • Anchor matching. A contributor is compared with the anchor only. One that lies 1.4 units from the anchor forms a second cluster, even when it lies .5 units from a member at .9.
  • Per-contributor truncation. Each contributor’s capacity is cut to a whole number before it is added, so fractional tons are lost per contributor.
  • Shared populations. One population can support several clusters, as a facility colony and again through module fleets at other positions that name it as their assigned population. The pass visits clusters in list order, population-anchored clusters first, so an earlier cluster drains the shared MaintenanceStockpile first.
  • System identity. Populations and module ships join clusters without a system comparison, so contributors from different systems at coordinates within one unit of the same anchor share one cluster, which carries the first contributor’s system. Ship assignment does compare systems. Ships in the second system cannot join, while ships in the first receive the combined capacity. First-system ships can also draw MSP from second-system populations, and the galactic map marks only the first contributor’s system.

Assigning ships

Section titled “Assigning ships”

Ship assignment takes the first cluster whose race and system equal the ship’s and whose anchor is within one unit of the ship’s fleet. With none, the ship is unassigned. A supply ship joins the cluster’s supply ships and, unless its class is commercial, its assigned ships. Any other ship joins the assigned ships only. A ship counts as assigned whenever a cluster matched.

The maintenance pass rebuilds the clusters for all races after its shipyard-task, NPR filters. It then follows the rules in support and net age recovery. A matched commercial supply ship only supplies MSP, and neither it nor an unmatched supply ship has LastOverhaul written. An unmatched Training ship under maintenance also has LastOverhaul moved back.

Module ships receive no automatic assignment. A noncommercial module ship goes through the ordinary assignment like any other ship, and its own tonnage then counts against the capacity it supplied. A cluster with no assigned ships is skipped, so its capacity goes unused and it draws no MSP. Capacity never moves between clusters.

What uses the cluster list

Section titled “What uses the cluster list”

Two parts of the game use the cluster list.

Use Effect
Ship maintenance pass Coverage ratio, clock progress, overhaul completion and residual failure risk, as in support and net age recovery.
Galactic map system refresh Rebuilds the list for the race shown on the galactic map and marks each cluster’s system as a maintenance location. The map draws a deep sky blue dashed ring around such a system when the maintenance locations checkbox is checked.

The galactic map refresh replaces the shared list with one race’s clusters, none of which has assigned ships. The maintenance pass always rebuilds before it reads, so the map’s list does not carry into maintenance.

Other readiness decisions test maintenance support directly and never read a cluster.

Decision Test applied
Move action availability for MoveRequirementID 21 (has maintenance capacity) A population destination qualifies with facility capacity of at least 1, or when any fleet whose assigned population is that population has an undamaged Maintenance Module. A fleet destination qualifies when its assigned population has facility capacity of at least 1. Any other destination looks its ID up among fleets and needs module capacity above 0. In practice only Begin Overhaul (rewind clock) on a system body without a population reaches this case, so a system body ID is matched against fleet IDs and passes only on a coincidental ID match. Deep space populations are offered neither action.
Join Fleet and Begin Overhaul order when carried out The target fleet’s assigned population needs facility capacity of at least 1, else an Illegal Order event (event type 140). A target fleet with no assigned population begins no overhaul and logs nothing.
Begin Overhaul (rewind clock) order when carried out No support test. It sets the assigned population and orbit, then begins overhaul for the fleet’s independent ships.
Nearest overhaul colony search, used when a fleet’s orders look for the nearest colony to overhaul at Same system, fuel stockpile above 0, AutoRefuel when required, and facility capacity x race MaintenanceCapacity above the fleet’s military hull tonnage. The nearest by travel distance wins.

In the move action catalogue of DIM_MoveAction, Join Fleet and Begin Overhaul (ID 10) and Begin Overhaul (rewind clock) (ID 118) both carry MoveRequirementID 21. The tests above and the cluster rules differ in two ways. A population whose only support is a module fleet assigned to it passes the order filter wherever that fleet is. The overhauling ship then finds a cluster only if the module fleet lies within one unit of it. Without one, the ship is under maintenance yet takes the unassigned path, so its clock does not advance and it carries full failure exposure. In the other direction, a population with facility capacity above 0 but below 1 anchors a cluster yet fails the order filter.

Failure exposure and immediate prevention

Section titled “Failure exposure and immediate prevention”

The base maintenance failure chance uses size S in HS, undamaged Engineering capacity E counted without commander bonuses, and maintenance age A in years:

base failure percent = S x 10 x A when E = 0

base failure percent = S / 2 x (S x .04 / E) x A otherwise

The interval exposure update then sets the exposure for elapsed years Y and uncovered fraction U:

maintenance failure chance = Y x base failure percent x training factor x U x (2 - crew performance) x (2 - ship Engineering bonus x admin Engineering bonus)

The training factor is 2 under a Training command, otherwise 1. This replaces the stored interval value. It is not an accumulated probability balance, and no clamp applies. A zero base leaves the ship off the risk list. Fully supported ships are not evaluated for risk.

The coefficient .04 is the engineering coverage coefficient. The update applies its factors in a fixed order. It doubles the base for a Training command, multiplies by Y and U, multiplies by 2 - crew performance, and finally multiplies by 2 - (ship Engineering bonus x admin Engineering bonus). The ship bonus is the effective commander Engineering bonus. The admin bonus is read for the fleet’s current system. The base is zero when maintenance age is zero, which happens after any rule sets LastOverhaul to now. The previous failure chance then stays stored, but that stale value is never rolled because the ship is not on the risk list. Neither factor is clamped. A bonus product above 2 would make the exposure negative, and the strict d10000 test could then never succeed.

Each ship on the risk list makes one test, d10000 strictly below maintenance failure chance x 100. Every die roll returns a whole number from 1 to the number of sides, so strict boundaries and fractional thresholds matter. A success causes a maintenance failure, which is resolved like a hit that carries no damage of its own. It picks a component from the ship’s hit-chance table, rolling again while the pick has its NoMaintFailure flag set, and can spread secondary damage. Supported ships calculate risk after their timestamp progress, using uncovered fraction 1 - f.

Immediate prevention is different from queued recovery. An age failure can spend a single component Cost in MSP and avoid actual component damage. Combat damage control can prevent a component loss with its own success roll and one Cost in MSP. A firing failure, which strikes a Standard-race ship on a d50 roll of exactly 5 while the No Maintenance Required option is off, and a crew quarters strain failure likewise try an immediate MSP rescue. Production records those debits. Space combat resolution explains damage selection and consequences. None of these rescues draws a finished component from cargo or a population stockpile.

Damage control queues and repair chances

Section titled “Damage control queues and repair chances”

Ratings and eligibility

Section titled “Ratings and eligibility”

let D be undamaged Damage Control - Military + Damage Control - Commercial + Engineering capacity, and B the effective ship Engineering bonus:

effective damage-control rating = max(1, D x ((B - 1) x 5 + 1))

This is the rating for queued recovery. The immediate damage-control success percent is a different value. It is zero if D is below 1, otherwise min(50, floor(D x 200 / class size)) x B. The base is capped before the officer multiplier. Neither the DCR text of a class design nor the immediate percentage is the queued repair rating.

Mothership repair support needs an actual mothership and either a commercial parasite or positive undamaged military hangar capacity (Transport - Military Hangar) on the carrier. Eligible support adds both ratings, and the carrier’s MSP above its class MinimumSupplies, to affordability. A colony maintenance cluster or a nearby Maintenance Module adds nothing to this damage-control rating. Support is refused without a mothership, granted for a commercial parasite, and otherwise granted only when the carrier’s military hangar capacity, counted without commander bonuses, is above 0. The component repair pass and the carrier armour pass apply this test. The repair chance shown in the interface does not.

Queue construction and traversal

Section titled “Queue construction and traversal”

Automated damage control clears and rebuilds the queue at each repair pass when damage exists. It makes one item per damaged instance, in ascending component-type RepairPriority from DIM_ComponentType, numbered 1 to N. A manual append in the interface limits queued instances to the damaged count. Remove, move to top, move up and move down renumber the queue. The queue display sorts the actual list by RepairOrder. Manual priorities are therefore overwritten at the next pass if automated control stays on.

The repair pass rebuilds the queue for every ship with AutomatedDamageControl on and at least one damaged record. The rebuild keeps the existing order of damaged records that share a RepairPriority. Renumbering sorts the actual list by RepairOrder, again keeping ties in place, and numbers it 1 to N. The Naval Organization window remove, move up and move down buttons renumber after their change. The move to top button first sets the item’s RepairOrder to 0. The manual append gives the new item current highest RepairOrder + 1 and does not renumber.

Repair goes through the current list order, without sorting by RepairOrder on its own. For each item, the required MSP is R = 2 x component Cost. If R exceeds available stock, the pass moves to the next item. For the first affordable item:

chance per thousand = elapsed seconds / R x combined damage-control rating

Above 1000 the repair succeeds without a roll. Otherwise success needs d1000 at or below the chance per thousand. A failed affordable attempt ends that ship’s pass. A successful attempt repairs one component, debits MSP, logs a Successful Repair event (event type 59) and ends the pass. No ship receives more than one component repair per increment, however high the chance. No partial repair progress is saved. Removing a completed item does not renumber the remaining items.

The repair chance shown in the interface adds a mothership’s rating whenever one exists, without the support eligibility test, and the probability is not capped. The displayed value can exceed the actual eligible chance. Neither the queue operations nor the repair pass described here checks ShipyardRepairOnly. The displayed chance is seconds / (2 x Cost) x rating / 1000 as a fraction of one. The queue list multiplies it by 100 for the percentage column, with two decimal places below 1% and one decimal place below 10%. It shows a dash when the repair chance time box holds 0 or less.

Carrier MSP above its minimum is normally used first, then the parasite’s own supplies. When a carrier is already below its minimum, the debit raises carrier stock to the minimum and adds that deficit to the parasite’s debit. This and the separate armour debit anomaly are described in production accounting. They are not a general replenishment feature.

Armour yards and other recovery paths

Section titled “Armour yards and other recovery paths”
Recovery route What it supplies or changes Material limits
Colony or mobile maintenance cluster Clock support and overhaul progress Location match, shared tonnage capacity and accessible MSP. Not automatic restoration of damaged counts.
Own damage control One probabilistic component repair per increment Queue, rating and 2 x component cost in MSP. No colony needed.
Eligible carrier Adds damage-control rating and MSP, a separate armour pass, and parasite clock relief Actual embarkation and the military or commercial gates above.
Repair yard, including a ship-mounted yard A scheduled repair task clears component and armour damage and the queue Yard and task admission, BP and mineral accounting. Not a damage-control probability roll.
Refit Changes class, clears specified damage and assignments, replenishes crew and selected stocks New class, task completion and available stocks. A broader operation than a repair.
Colony logistics Refuels, resupplies, rearms and replaces crew through distinct operations Their own support, order and rate gates. Intact capacity does not create stock.

Yard admission, rates, resources and mobile-yard integration are covered by production’s shipyard section and shipyard development and ship work. Physical support transfers are in movement and logistics.

A Mobile Repair Bay works through the shipyard rules. A class design adds up a whole-number RepairYardCapacity. When the ship is created, the game registers a repair yard tied to that parent ship, with one slipway and that capacity in tons. At the end of each increment the yard follows the parent fleet’s assigned population, and task processing needs that link to still match the yard’s population. Repair target lists need damaged hulls of the yard’s own race, at the same coordinates, with no existing task from that race, and class size at most yard capacity / 50. Normal yard work in the interface also limits slipways. The target lists do not compare systems explicitly. This is population-backed yard work. Population output, minerals and wealth pay for it, not carrier MSP or onboard cargo.

For a given target class, yard work rate uses adjusted size = class size x (.25 if commercial, otherwise 1) and rate = (1 + (adjusted size / 100 - 1) / 2) x population shipbuilding output modifier. Mobile-yard tonnage is an admission limit, not a damage-control bonus or a direct speed multiplier. In the paths described here, the mobile yard is not resized after component damage or repair. Removing the parent ship removes its yard and assigned tasks. These limits separate mobile yards from maintenance modules and from carrier damage-control support.

Carrier armour repair is a separate pass and can succeed alongside a component repair. It needs eligible mothership support and at least 2 x armour Cost in pooled MSP. Short of that, the game logs a No Spare Parts event (event type 58). Chance per thousand is elapsed seconds / armour Cost x combined damage-control rating, without the factor 2 of the component repair denominator. A successful pass visits damaged columns deepest first and repairs one cell in each, at 2 x Cost per cell. It stops when pooled supplies cannot pay another 2 x Cost or when the whole number of repaired cells equals the armour ComponentValue. It does not refill the deepest column repeatedly within one pass. The debit comes from carrier stock down to zero, then from parasite stock, even though the affordability pool protected the carrier minimum.

Regeneration repeatedly heals the current deepest column, can clear all damage, uses no MSP and discards fractional cells each time.

Yard repair completion clears the damaged-component records, armour damage and the damage-control queue, clears the Destroyed flag, recomputes a replacement crew grade, and advances LastOverhaul by (now - LastOverhaul) x task total BP / class Cost. Repair completion does not reset CurrentCrew, current shield strength, OverhaulFactor or maintenance state. The grade recalculation does not by itself mean that every missing berth is filled. The repair cost is component cost times damaged quantity plus armour cost times the damaged-cell fraction. The per-record quantity anomaly in the mineral cost is documented in production.

The repair task BP is sum(component Cost x Number) + armour Cost x (sum(armour damage cells) / armour ComponentValue), with the first sum over damaged records. The mineral requirement adds component material cost x repair material fraction once per damaged record, without multiplying by Number. It adds armour material cost x repair material fraction x damaged-cell fraction. The repair material fraction is .5, so minerals are half the material cost while BP carries no such factor. The shipyard task preview and the population AI repair queue use both figures. The repair and crew report uses only the BP figure.

Refit changes class and clears armour and component damage and fire-control, weapon and missile assignments. it sets current crew to the new class requirement, sets shields to zero and inactive, and adjusts fuel and MSP toward the new design capacity, drawing population stock or returning the excess. Refit completion separately clears weapon recharge entries and reduces maintenance age proportionally. These are refit side effects, not properties of every successful queued repair.

Biological exceptions are narrow. For a race with BioShips set, each class design summary sets crew to 0 late in recalculation and reports no crew, maintenance or fuel. It does not remove quarters already allocated or zero design capacities. Commercial classification, BioShips and a captured class’s OtherRaceClassID are different conditions, so one exemption does not extend to the others.

Capability losses restoration and eligibility

Section titled “Capability losses restoration and eligibility”

A successful component repair only decrements one matching damaged count, or removes the record. It does not update fleet speed, sensor data or the kept tactical effectiveness value. It does not refill shields, fuel or ammunition, replace crew, restore removed fire-control assignments or reset clocks and factor. Capacities worked out on demand see the repaired instance immediately. Kept values and orders wait for their own update, such as the combat update of tactical effectiveness and maximum speed.

Capability or activity Live condition or effect
Maximum speed A ship towed by a tractor, a ship under maintenance, a player ship with Fuel = 0, or a ship with no positive thrust each get speed 1. Otherwise speed is whole-number(undamaged engine power x factor / effective mass x 1000), clamped to 1 to 270000 km/s. Effective mass is class size, plus the towed ship’s size or towed shipyard capacity / 25 x slipways. Repairing an engine does not reset the fleet to maximum speed.
Movement order scheduling The fleet scheduler excludes fleets with any ship under maintenance. The minimum-speed value alone is not permission to carry out orders. Standing and conditional orders separately exclude maintenance and yard ships.
Shields Effective maximum is undamaged shield capacity x factor. Active recharge needs the operational state. A repaired generator does not immediately restore current shield points.
Weapon recharge Generation is undamaged reactor capacity, with no general morale or crew multiplier. Since recharge follows component repair at increment end, repaired reactors can affect that recharge pass.
Weapons and controls Damage removes assignments and recharge entries above the remaining undamaged instance count. Repair does not recreate them. Ready weapon, assigned control, targets, delays and ammunition stay distinct gates.
Sensors The sensor rebuild reads undamaged components. Component repair does not itself start a sensor rebuild.
Logistics and work Some bonus-adjusted module capacities use crew fraction and morale. Physical transfers also need their own handling, support and stock conditions.

See power and detection for shields, recharge and sensors, movement for travel calculations, and space combat resolution for firing and damage consequences. The list of components destroyed in combat is per-combat tracking, cleared whenever combat tracking resets. It is not a second, permanent bucket of irreparable components beside the damaged-component records.

Damage consequences also have timing limits. Fuel, shield, colonist, troop and cargo capacity losses are processed in the combat aftermath for surviving ships that lost components in that combat. Magazine loss removes ordnance counts rounded up, even without an explosion. Fire-control losses can reset or remove attached missile salvos in flight. A component repair does not reverse stocks, people or salvo guidance already lost. Surrender and boarding capture directly set the factor to .01, set LastShoreLeave two planned deployments back, and set CurrentCrew to 1 in the relevant capture rules. Ordinary morale recalculation is not the only thing that changes readiness.

Processing cadence and persistence

Section titled “Processing cadence and persistence”

When changes take effect

Section titled “When changes take effect”
Phase Readiness-related work
Each movement, logistics and combat subpulse Training fuel, movement and combat, factor recovery below 1, sensor checks, and fire and sensor delay countdown.
Actual increment completion Shield recharge, parasite shore-leave clock, queued component and armour repairs, weapon timers, final combat fire. The one-repair limit applies per actual increment, not per subpulse.
Construction cycle Maintenance, overhaul and failures, commander grade training, fleet training, population production, then deployment and shore leave.

The construction cycle runs when now - LastGrowthTime is strictly greater than the construction cycle time. It uses the actual elapsed cycle time rather than assuming a fixed five-day interval. Shield recharge comes before queued repairs, so a restored shield generator waits for a later recharge pass. Weapon recharge comes after repair. Game-time increments can be shortened or interrupted, so probability and clock formulas use the actual elapsed spans. See game time and state refresh for the increment timeline.

Within the construction cycle, maintenance comes before commander grade growth, fleet training, population production and the later deployment and shore-leave pass. Maintenance therefore sees the earlier grade and morale. Fleet training can see newly trained grade with the earlier morale. Shore leave then changes morale for later consumers. A new game defaults the construction cycle time to 430000 seconds, and the setting is editable.

Saved state and reconstruction

Section titled “Saved state and reconstruction”

FCT_Ship stores and restores CurrentCrew, CrewMorale, GradePoints, TFPoints, CurrentMaintSupplies, Fuel, CurrentShieldStrength, ShieldsActive, LastOverhaul, LastShoreLeave, OverhaulFactor, MaintenanceState, AutomatedDamageControl, FireDelay, SensorDelay, the mothership IDs (MothershipID, AssignedMSID) and other timestamps. Loading therefore does not grant fresh shore leave, a full overhaul, full supplies or a factor of 1. How numeric relationships are restored is covered by object identity and reload.

The shared construction cycle clock also survives reload. FCT_Game stores LastGrowthTime and the construction cycle time (in MinConstructionPeriod), and loading a game restores both. The elapsed cycle span is current game time minus that stored timestamp. After the construction cycle runs, LastGrowthTime is set to now. Reload does not restart the interval at zero.

The damage-control queue is stored in FCT_DamageControlQueue as ComponentID, ShipID and RepairOrder. When a game loads, entries are read in no set order and appended without sorting, keeping those whose ship and component exist. Interface display, renumbering or automatic queue building sort the list later, but the first repair pass uses the current list order. RepairOrder alone does not guarantee the traversal order after a load. Damage records and armour records are stored separately from the queue. No per-item work progress is stored, so a stochastic repair starts again with a fresh interval chance. The maintenance failure chance is not stored either. It is a recalculated interval exposure, not a saved probability bank.

Damaged counts are stored in FCT_DamagedComponent (ShipID, ComponentID, Number), and armour holes in FCT_ArmourDamage (ShipID, ArmourColumn, Damage). Loading rebuilds the two separately. Survivor groups use FCT_Survivors, while lifepod crew, grade and creation time use FCT_Lifepods. Current deployment months, the deployment overrun ratio and the overcrowding deployment multiplier are not saved. Morale itself is restored without an immediate morale update, so it can persist until a rule actually refreshes it.

Weapon recharge debts are stored in FCT_WeaponRecharge (ShipID, WeaponID, WeaponNumber, RechargeRemaining), independently of component condition. Restoring reactor capacity changes future recharge throughput, while the saved debt still needs processing. Saved overhaul and shore-leave timestamps likewise resume their existing age calculations against the saved current game time.

Maintenance location clusters have no table. Clusters are not saved. Each maintenance pass and each galactic map refresh rebuilds it from saved populations, installations, ships, fleets and damage, so a reload loses nothing the next rebuild needs. The kept tactical effectiveness value is not saved either. After a load it holds the default 1.0 until the next refresh of tactical effectiveness and speed. The combat pass refreshes before combat reads the value. NPR combat targeting makes no refresh, so after a load NPR targeting uses 1.0 for a ship until a combat pass or the NPR point-defence estimate refreshes it.

Worked scenarios

Section titled “Worked scenarios”

Deployment overrun, casualties and effective performance

Section titled “Deployment overrun, casualties and effective performance”

Take a Standard player ship with planned deployment 3 months, actual deployment 6 months, 100 required crew, 60 aboard, GradePoints = 400 and factor = 1. The overrun morale is 3/6 = .5. The below-half crew rule does not apply. The grade bonus is +10%, so crew performance is 1.1 x .5 = .55. Without tactical officers, tactical effectiveness is 1.1 x .5 x .5 = .275. Losing another 20 crew crosses the below-half boundary. The quotient whole-number(40/100) is zero, so the morale update floors the result to .25, rather than producing .5 x .4 x 2 = .4.

At an eligible shore location with 60% crew, one elapsed day advances LastShoreLeave by 6 days. Current time advances one day, so deployment age falls by 5 days, until it reaches zero. This does not fill the missing 40 crew or repair any component. Replacing those crew later uses the separate grade-weighted replacement.

Partial support and manual departure

Section titled “Partial support and manual departure”

Take a ship under maintenance with a 20-day age at the start of a one-day interval. With f = .5, the timestamp advances 2.5 days while now advances one, so age falls to 18.5 days. With f = .2 it stays at 20 days. Full support makes age 16 days. These values concern age, not a percent repair of damaged equipment.

If the ship manually leaves overhaul, its state becomes operational and a noncommercial factor becomes .01, while age stays whatever it was. For intact engine power 1000 EP and size 100 HS, speed becomes whole-number(1000 x .01 / 100 x 1000) = 100 km/s, against 10000 at factor 1. Each elapsed 30-day game month adds 1.0 to the factor, capped at 1. Starting from .01 it reaches 1 after .99 month (29.7 days), with or without support. Automatic overhaul completion does not apply this manual-exit .01 penalty.

Queue affordability versus priority

Section titled “Queue affordability versus priority”

Suppose the list order holds a Cost 100 engine, then a Cost 10 Engineering component, with available MSP 30, combined rating 4 and 1000 elapsed seconds. The engine needs 200 MSP and is skipped. The second entry needs 20. Its chance is 1000/20 x 4 = 200 per thousand, succeeding on rolls 1 to 200. Success removes one damaged Engineering instance and 20 MSP, ending the pass. No 20% work is saved if the roll fails. If 250 MSP were available instead, the engine would get the first affordable attempt, and a failure would stop the Engineering entry from trying that pass.

When Engineering is restored, the next capacity calculation can raise MSP capacity and reduce future base failure exposure. MSP capacity with Engineering present is round(floor(Engineering capacity / (class size x .04) x class Cost / 2 + maintenance storage)), and maintenance storage alone without Engineering. The repair does not fill the newly restored MSP storage. A restored reactor can recharge weapons later in the same increment. A restored shield generator waits until a later recharge phase because shield processing already ran.

Carrier armour and stores

Section titled “Carrier armour and stores”

Take an eligible parasite with damaged armour columns of depths 4, 2 and 1, armour Cost 5 and ComponentValue 2, pooled affordable MSP 25, combined rating 5 and 1000 elapsed seconds. The chance is 1000/5 x 5 = 1000 per thousand, so every d1000 result succeeds. The pass repairs one cell in the depth-4 column and one in the depth-2 column, leaving depths 3, 1 and 1. The ComponentValue limit stops the pass at two cells, costing 20 MSP. It does not put both cells into the first column. The carrier debit can use protected minimum stock despite the affordability calculation, so the debit has to be worked out separately from the pooled eligibility budget.

Crowding escalates into independent life-support loss

Section titled “Crowding escalates into independent life-support loss”

For an independent ship reaching the crowding check with required quarters twice its undamaged capacity, Q = 4. If morale checks apply, one elapsed day subtracts three extra days from LastShoreLeave, giving four days of deployment age growth including the normal passage of time. The strain threshold is 4 x 10000 x elapsed years. Success either spends one selected quarters component’s Cost in MSP or damages it. On a later check with no surviving quarters, a four-d20 total of 40 kills whole-number(CurrentCrew x .4) ordinary crew and sets morale to .1, keeping one crew member at the cap. A matching shore-leave location or a mothership would have ended the update before these checks.

Cluster coverage and an unmatched ship

Section titled “Cluster coverage and an unmatched ship”

The numbers are synthetic. A player population at (0, 0) has facility capacity 4, and its race has MaintenanceCapacity 1000 with every population factor at 1. It anchors a cluster with whole-number(4 x 1000) = 4000 tons. A commercial tender fleet at (.6, 0) carries two undamaged Maintenance Modules. Both axis differences are below 1, so it joins the same cluster and adds 2000 tons. As a commercial ship it is not assigned, and the pass resets its own clock.

Two noncommercial operational 80 HS ships at the population are assigned, 4000 tons each. Coverage is 6000 / 8000 x 1 = .75, with EconomicProdModifier 1. For a 430,000-second cycle Y = .0136352. With class Cost 400 each ship needs .25 x 400 x Y = 1.36352 MSP and requests 1.02264, which the population pays in full, so f = .75. LastOverhaul advances 322,500 seconds against 430,000 elapsed, and age grows by 107,500 seconds, about 1.24 days.

Take Engineering capacity 2 and an age of one year when risk is evaluated. The base is 80/2 x (80 x .04 / 2) x 1 = 64. With P = 1 and no Engineering bonus the exposure is Y x 64 x .25 = .21816. The threshold is 21.816, so the strict d10000 test succeeds on rolls 1 to 21, a .21% chance.

A third identical ship sits at (1.2, 0). It lies .6 units from the tender but 1.2 from the anchor, so no cluster matches it. The ship takes the unassigned path with U = 1. Its exposure is .87265, a threshold of 87.265 and an .87% chance. Its clock does not move, so age grows by the full 430,000 seconds, about 4.98 days.

Training without an effective commander

Section titled “Training without an effective commander”

The numbers are synthetic. Two player ships sit in a fleet under a Training command whose commander is absent, so the fleet training multiplier is 1. Both have morale 1, factor 1, fuel and no shipyard task. Y = .0136352 per 430,000-second cycle.

The last two rows show the same ships under an effective commander whose multiplier is 1.2.

Ship GradePoints P Active gain Passive gain Net per cycle
A 0 .9 (.9 - 1) x 1000 x Y = -1.36352 30 x Y x .9 = .36815 -.99537
B 400 1.1 (1.1 - 1) x 1000 x Y = 1.36352 30 x Y x 1.1 = .44996 1.81348
A, multiplier 1.2 0 .9 (1.08 - 1) x 1000 x Y = 1.09082 .36815 1.45897
B, multiplier 1.2 400 1.1 (1.32 - 1) x 1000 x Y = 4.36327 .44996 4.81323

Ship A loses fleet training under the commanderless Training command, and no floor stops TFPoints going below zero. Both ships still burn fuel every subpulse. With 1000 undamaged engine power and a synthetic FuelEfficiency of .5, each 3,600-second subpulse burns 100 x .5 x 1 = 50 fuel.

Concept map

Section titled “Concept map”

Resources

Section titled “Resources”

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