This page covers how a class’s reactor output and weapon demand are calculated, how weapons and shields recharge in play, how a class is classed as commercial, military, small craft or station, which signatures a ship emits, and how active and passive sensors detect it. It keeps design totals, saved state, live values adjusted for damage, and sensor tracks apart. Propulsion, fuel use, transit and supply transfers belong to Movement and logistics and Production mechanics. Remembered capabilities and ELINT catalogue knowledge belong to Intelligence mechanics. The formulas are the game’s own rules, not a physics model. The worked examples use stated inputs, not the technology catalogue of any particular saved game.

Quantity Meaning and unit How it is calculated
Size (Size in FCT_ShipClass) Hull spaces (HS), 50 tons per HS The class sums each component’s size times its installed quantity (NumComponent in FCT_ClassComponent, which can be fractional), including armour and crew quarters.
Reactor power (ReactorPower in FCT_ShipClass) Design power generated per five-second recharge interval Sum of each reactor’s value times its installed quantity.
Required power (RequiredPower in FCT_ShipClass) Design weapon recharge demand per five-second interval Sum of RechargeRate times quantity for the listed direct-fire weapon types. It is not energy per salvo.
Power requirement (PowerRequirement in FCT_ShipDesignComponents) One weapon’s stored recharge debt after firing Distinct from its per-interval RechargeRate.
Engine power (EnginePower in FCT_ShipClass) Propulsive output (EP) of the engines Comes from separate engine components. It does not supply the reactor recharge budget.
Current shield strength (CurrentShieldStrength in FCT_Ship) Stored current shield points Separate from reactor output and from full generator capacity.
Maintenance supplies and fuel (CurrentMaintSupplies and Fuel in FCT_Ship) MSP and litres Separate stocks. Neither supplies reactor recharge in the paths described here.
Sensor resolution and cross section Active target size in HS equivalents One HS is 50 tons, so a size in tons divided by 50 gives HS. A missile’s size in MSP converts to HS by dividing by 20 for active detection.
Sensor distance Kilometres Straight-line distance between system coordinates. A target exactly at the range limit is detected.

Recalculating a class summary changes the class. It resets the totals and classification flags, removes the components a no-armour design cannot carry, recalculates aggregate mass and crew, and allocates crew quarters. It adds one Bridge (component ID 18 in FCT_ShipDesignComponents) when the size exceeds 22 HS and the class has none. It then repeats the armour allocation and the mass and crew totals several times. The number of repeats is three times the armour thickness minus one, and at least 9. Only then does it compute class capabilities and the main function. The small craft size test is applied after those additions and repeats. The recalculation is not a read-only summary. Selecting a class in the Class Design window runs it.

Live capacity generally sums the undamaged count times the component value. The undamaged count is the installed quantity, truncated to a whole number, minus the number of damaged copies of that component. Nothing keeps it from falling below zero. In the paths described here, reactors, engines, shields and ordinary sensor sources take capacity without commander bonuses, or read component values directly. The optional commander bonus applies only to a listed set of logistics, survey and production modules. Cargo shuttle bays take the ship commander’s Logistics bonus. Gravitational and geological survey sensors take the effective Survey bonus. Salvage modules take the Production bonus. Sorium harvesters and orbital mining modules take the Mining bonus. Terraforming modules take the Terraforming bonus. In that bonus path, survey sensor capacity is also multiplied by crew morale, and survey sensors, harvesters, terraforming, mining, salvage and maintenance modules are multiplied by current crew divided by class crew when the ship is understaffed. It is not a general multiplier for all ship systems.

Crew performance = (1 + round((square root of GradePoints) - 10) / 100) x CrewMorale x OverhaulFactor, all three from FCT_Ship. Tactical effectiveness separately applies the commander tactical bonuses and crew morale again. These factors affect combat and other systems. They do not multiply the raw reactor recharge budget, ordinary ship sensor ranges or the shield recharge rate described below. Effective engine output and maximum shield strength do use the overhaul factor. When the NPR system AI estimates the speed of a group of alien ships, each ship’s effective engine power = undamaged engine capacity x OverhaulFactor, and a result of 0 is replaced by 1.

Designing a reactor creates one component with these values:

  • output = reactor technology AdditionalInfo x size x sqrt(size) x boost technology AdditionalInfo, rounded to 2 decimal places, with the reactor technology AdditionalInfo in FCT_TechSystem
  • cost = output x 3, rounded to 1 decimal place, paid in Boronide
  • crew = size x 2, rounded
  • HTK = size / 2, rounded down, with a minimum of 1 when size is at least 1
  • stored explosion chance = boost technology AdditionalInfo2, truncated to a whole number
  • maximum explosion size = output / 2, rounded

Wherever this page says rounded, an exact half goes to the even neighbour.

The component is flagged as a military system (MilitarySystem in FCT_ShipDesignComponents) and saves its output as ComponentValue. The boost changes this component definition. It is not reapplied each time a ship recharges.

A class’s reactor power is the sum of its installed reactor values. Its required power sums RechargeRate x quantity for these component types in DIM_ComponentType: Laser (15), Particle Beam (30), Meson Cannon (34), Railgun (35), Plasma Carronade (36), High Power Microwave (44) and Gauss Cannon (45). Designed Gauss cannons have a PowerRequirement and RechargeRate of 0, and so does a designed CIWS. Shields, engines, search sensors and missile reload timers add nothing to the class weapon power requirement. When required power exceeds reactor power, the design gets the warning “Reactors are generating insufficient power for the weapons”, followed by reactor power and required power in brackets. This calculation does not reject the class or stop a weapon that is already ready from firing its first shot.

A turret multiplies its underlying weapon’s PowerRequirement and RechargeRate by the number of weapons in it. A beam weapon’s nominal rate of fire is 5 x ceiling(power requirement / recharge rate) seconds. A beam weapon with a power requirement of 0 gives 5 seconds. A component that is not a beam weapon gives 0. This nominal rate assumes enough generation. It is distinct from the ship’s shared allocation schedule.

Live power and demand displays also differ from class totals. The live beam weapon demand sums the recharge rates of undamaged beam weapons. The required power percentage sums the recharge rates of undamaged weapons with a positive recharge rate, then shows undamaged reactor output / demand x 100%. Zero demand shows a dash. This percentage is the share of demand that supply covers, not the share of reactor output currently in use. Neither figure picks out only the weapons that currently need recharge.

Weapon recharge scheduling and persistence

Section titled “Weapon recharge scheduling and persistence”

Firing a direct-fire weapon creates a recharge entry for that component and weapon number, with the recharge remaining equal to the weapon’s PowerRequirement. Missile and decoy launchers instead store their RateOfFire in seconds. A recharge entry therefore has different units for different weapon types. A weapon is ready when it has no outstanding recharge entry of its own. Firing adds a new debt. It does not check a treasury, fuel or stored reactor energy.

The weapon recharge step sorts all entries by ascending PowerRequirement. For t elapsed seconds it creates a fresh shared budget:

available power = undamaged reactor capacity x t / 5

Each weapon that is not a missile or decoy launcher is then served in that order while budget remains above 0. Allowed recharge = min(weapon RechargeRate x t / 5, remaining shared budget). Actual consumption = min(allowed recharge, outstanding debt). The consumption is subtracted from both the debt and the shared budget. Once the budget is used up, later weapons make no progress. Completed entries are removed after the pass. The budget and the debts keep fractional values.

This is ordered allocation, not proportional sharing. Entries with small power requirements get first access. Equal requirements keep their existing order. Budget left unused after a pass is discarded. The ship has no reactor energy store that accumulates surplus between passes. The only persistent state is each weapon’s recharge debt. Reactor damage reduces the budget at once, through the undamaged count. When a weapon component is damaged, the recharge entries for weapon numbers above the remaining undamaged count are removed.

Missile and decoy reloads do not draw on this budget. A normal launcher’s remaining time falls by t. On a craft docked in a mothership, the remaining time falls by t x Carrier Operations bonus multiplier, using the mothership’s effective Carrier Operations commander bonus multiplier. Launchers flagged hangar reload only (HangarReloadOnly in FCT_ShipDesignComponents) reload only while docked in a mothership, or while at the same position in the same system as an ordnance transfer population or ordnance transfer hub fleet of their own race. That ordnance transfer support uses a reload divisor of 10, so these launchers reload at t / 10 outside a hangar. This timer adds no ammunition. Physical rearming is a separate stock transfer.

When the game picks the length of the next combat sub-pulse, it considers ships that are not docked, have a fire delay (FireDelay in FCT_Ship) of 0, have fire control assignments set to open fire (point defence modes do not count), and have a target within effective range. A ready weapon sets a five-second sub-pulse. For a recharging weapon other than a Gauss cannon, the estimated completion time is debt / min(weapon recharge rate, reactor output) x 5 seconds. With zero reactor output that estimate is skipped. A missile launcher uses its outstanding reload seconds. A Gauss cannon sets 5 seconds. An estimate of 5 seconds or less sets 5 seconds, and a longer estimate shortens the sub-pulse to that many whole seconds when it is shorter than the current length. The estimate uses one weapon’s rate. It ignores the earlier weapons that share the actual budget, so it is a scheduling estimate, not a guarantee that weapons finish together.

Each sub-pulse of the main increment runs movement, logistics and combat, then the sensor checks. When the increment completes, the game recharges shields, runs damage control repairs, advances weapon timers for the actual elapsed increment length, then resolves another combat fire phase. Open fire scheduling can shorten the selected time step. The equations use actual elapsed game time, not a fixed cadence.

The game stores each outstanding recharge in FCT_WeaponRecharge with GameID, ShipID, WeaponID, WeaponNumber and RechargeRemaining. Loading a game restores the entries whose ship and component still exist. No accumulated reactor energy is stored. Component definitions keep their PowerRequirement and RechargeRate in FCT_ShipDesignComponents.

A designed shield component has strength = shield technology AdditionalInfo x size x sqrt(size / 10), rounded. Its preliminary recharge amount = regeneration technology AdditionalInfo x size. The saved RechargeRate is strength x 300 / preliminary recharge amount, rounded down. It is read as the seconds needed to recharge one component’s full strength. Cost = strength + preliminary recharge amount, paid in Corbomite. The component is a military system and its FuelUse is 0.

Live raw shield capacity = sum of undamaged generators x component strength. Effective maximum = raw capacity x OverhaulFactor. Recharge points for t seconds = undamaged generator count x first shield component strength x t / that component's RechargeRate, capped at the strength missing from the effective maximum. The Class Design window allows only one shield generator design per class, with the message “Only one type of shield generator can be added to a class”, which supports that first-component calculation. Recharge itself is not multiplied by the overhaul factor, crew grade, morale, commander skill or reactor output.

The shield recharge step selects ships whose shields are active (ShieldsActive in FCT_Ship), whose maintenance state is operational, and whose current strength is below raw undamaged capacity. The recharge caps against the smaller overhaul-adjusted maximum, so a ship already at its effective maximum can still be selected by the raw-capacity test. Turning a fleet’s shields off clears each ship’s current shield points. Newly built ships have shields off and zero strength. Shield damage marks the ship’s shields as damaged for loss handling, and the shield capacity loss step trims current points down to effective capacity.

Shield recharge consumes neither the weapon reactor budget nor fuel or MSP in these steps. FuelUse is a stored component field, but designed shields set it to 0 and the recharge step does not debit it. Active shield points give an EM signature regardless of reactor load.

Commercial military fighter and station classification

Section titled “Commercial military fighter and station classification”

The classification flags are separate from the hull description the player chooses and from the inferred main function (MainFunction in FCT_ShipClass). They serve different rules, so a class can be a small craft with a survey or logistics function, or be commercial while carrying a CIWS that is not a military system.

Flag in FCT_ShipClass Recalculation rule Boundary and qualification
Commercial Starts true. Becomes false if PlannedDeployment is below 3 months, if any remaining installed component has MilitarySystem set, if any thermal, EM or active search component is larger than 1 HS, or if the total engineering component value is below 1 No blanket test for armour thickness, hull description, mass or the Weapon flag. The engineering failure adds the warning “Commercial designs require at least one HS (50 tons) of Engineering”.
Military vessel The class summary says “This design is classed as a Military Vessel for maintenance purposes” when the class is neither commercial nor a fighter Uses the class flag, not the ship’s damage state.
FighterClass Starts false. Set true when the final class size is 10 HS or less 500 tons or less, including allocated armour and quarters. Independent of weapons.
MilitaryEngines Taken from the engine component’s MilitarySystem flag A designed engine is commercial only when its size is at least 25 HS and its thrust modifier is 0.5 or less.
CommercialHangar True when a commercial hangar deck (Transport - Commercial Hangar, component type 58) is installed The Class Design window refuses to mix the two hangar types with “Hangars and Commercial Hangars cannot both be added to the same ship”.
NoArmour Whole-number flag set by the player NoArmour = 1 strips engines, armour and every military-system component, resets the armour thickness to 1, then allocates the structural shell.
Space station for construction The class summary says “This design is classed as a Space Station for construction purposes” when the class is commercial and NoArmour = 1 Industrial station selection tests NoArmour = 1 directly, not the Space Station main function.
FuelTanker, SupplyShip, Collier Player flags kept across recalculation Set with the Class Design window check boxes. They select replenishment and ordnance roles, not the inferred function.

A component’s MilitarySystem flag is part of its saved definition. It is not an automatic synonym for military technology. Designed reactors and shields are military. Designed active search sensors, missile fire controls, thermal sensors and EM sensors are military only when larger than 1 HS. A designed CIWS is not military, although its Weapon and BeamWeapon flags are set. Designed Gauss cannons and turrets are military. Imported, baseline and alien component definitions keep their stored flag.

When a game is loaded, a class keeps its stored Commercial, FighterClass, MilitaryEngines, CommercialHangar, NoArmour, MainFunction and calculated totals from FCT_ShipClass, rather than deriving each from its components. ReactorPower and RequiredPower can hold fractions in play, but loading rounds them to whole numbers, so fractional design totals change on reload. Live reactor and recharge calculations read the component values instead. A later recalculation restores the values from the class definition. Damage does not reclassify the whole class.

Prototype status is also part of the definition. Any component whose Prototype value in FCT_ShipDesignComponents is not 0 (not a prototype) marks the class as containing prototypes. That affects build and retool availability. Such classes are left out of shipyard retool lists, and a space station that contains prototype components is refused with “A space station cannot be built if it contains prototype components”. It adds no reactor or sensor output multiplier in the live calculations. Alien components keep their own performance values, and no general power or range penalty for alien parts applies in these calculations. A captured ship can have a reduced overhaul factor, which affects the live systems listed above that use it. A ship that surrenders, or is captured by boarding, has its OverhaulFactor set to 0.01.

Main function precedence and downstream consequences

Section titled “Main function precedence and downstream consequences”

The main function assignment resets the class to None (MainFunction 0) and uses the class’s current capabilities. The class protection value (ProtectionValue in FCT_ShipClass) is the HS of the listed direct-fire weapon types plus missile launchers and fighter pod bays. CIWS and decoy launchers add nothing to it. The main function is separate from the commercial and fighter flags and from automated design templates. The class summary shows it as “This design is classed as a (main function) for auto-assignment purposes”. Gravitational and geological survey ships both show as Survey Ship.

When the protection value is above 0, the first matching outcome wins:

  1. Gravitational survey ship (MainFunction 6) if gravitational survey sensor HS is greater than protection HS and at least geological survey sensor HS.
  2. Geological survey ship (7) if geological survey sensor HS is greater than protection HS.
  3. Carrier (1) if military hangar HS is greater than protection HS.
  4. Warship (2) if size is above 20 HS (over 1,000 tons).
  5. FAC (3) if size is above 10 HS (over 500 and at most 1,000 tons).
  6. At a size of 10 HS or less, Ground Support Fighter (25) if fighter pod bay HS is strictly greater than both missile launcher HS and beam weapon HS. Otherwise Fighter (4).

Without protection, the first capability present wins, in this order:

Order Capability present (FCT_ShipClass column) Main function MainFunction
1 Parasite capacity above 20 HS (ParasiteCapacity) Carrier 1
2 Gravitational survey (GravSurvey) Survey Ship (gravitational) 6
3 Geological survey (GeoSurvey) Survey Ship (geological) 7
4 Troop capacity (TroopCapacity) Troop Transport 10
5 Jump point stabilisation time (JGConstructionTime) Stabilisation Ship 11
6 Harvesters (Harvesters) Fuel Harvester 12
7 Terraformers (Terraformers) Terraformer 13
8 Mining modules (MiningModules) Orbital Miner 14
9 Salvage (SalvageRate) Salvager 15
10 Diplomacy (DiplomacyRating) Diplomatic Ship 26
11 ELINT (ELINTRating) Intelligence Ship 24
12 Colonists (ColonistCapacity) Colony Ship 9
13 Cargo (CargoCapacity) Freighter 8
14 Passengers Liner 16
15 Recreation (RecreationalModule) Recreational Ship 22
16 Maintenance modules (MaintModules) Maintenance Ship 18
17 Worker capacity (WorkerCapacity) Orbital Habitat 20
18 NoArmour = 1 Space Station 23
19 Total sensor size above 5 Scout 5
20 Tractor (STSTractor) Tug 27
21 None of these None 0

Total sensor size adds the size, truncated to a whole number, of each installed thermal, EM and active search component design once, without multiplying by its installed quantity. Supply Ship (17) and Tanker (19) exist as main function values, but this assignment does not give them from the supply ship or tanker flags.

These consequences use the separate flags:

  • Commercial ships skip routine overhaul and failure processing for player races, and their last overhaul date is set to the current time instead. Ships that are not commercial enter the fleet training paths. A commercial ship’s live protection rating is 0.
  • Commercial shipyards list only commercial classes for retooling. The industrial small craft list uses a size of 10 HS or less, not an inferred Fighter function. The station list uses NoArmour = 1. Classes with prototype components are left out of those lists.
  • MilitaryEngines sets jump and transit grouping and delays, independently of the vessel’s commercial status.
  • CommercialHangar decides whether docked parasites get the military hangar maintenance clock treatment. A parasite docked in a mothership without a commercial hangar has its last overhaul date moved forward by 5 times the elapsed time, never past the current date.
  • The main function selects automatic roles and local searches for ships with a given role. It does not set reactor demand or active cross section.

The class header shows the design TCS (cross section), the class thermal value (ClassThermal in FCT_ShipClass) and shield strength x 30 as EM. These are not the full current detectable emissions.

Live target quantity Ship calculation State and modifiers that matter
Active cross section Class size x SensorReduction, with a class floor of 0.3 HS. A cloak rated for at least the class size sets SensorReduction to its CloakRating If the class cross section equals its size, the size is used. Any damaged record for the first cloak component restores full size. Unrelated damage leaves the cloaked cross section.
Idle thermal Size / 20 Used whenever the fleet has no move orders.
Thermal with orders max(size / 20, nominal engine output x engine StealthRating x fleet speed / truncate(nominal engine output / effective mass x 1,000)) Uses the first engine design’s installed count, not the undamaged count or current engine power. Effective mass includes a tractored ship or yard. A ship with orders and no engine returns 0.
Shield EM CurrentShieldStrength x 30 Only when shields are active and the result is above 0. Uses current points, not full class strength.
Active search EM max(1, source strength x source resolution), for each active source The source uses the component value and resolution truncated to whole numbers. Each emitting sensor profile makes its own contact. They are not summed.
Transponder Contact strength 0 Makes its own contact through the transponder mode and relationship test, not an EM distance equation.

A cloak must cover the class size to reduce the cross section. An undersized cloak gives the warning “Cloaking Device Ship Size is too small for this design”. When the live cross section is worked out, the game checks whether any damaged record matches the cloak, so a remaining duplicate cloak does not keep the reduction. The target’s mass and cross section do not shrink when weapons or engines are damaged. The Class Design window allows only one engine design per class (“Only one type of engine can be added to a class”), though saved or custom definitions can bypass that.

Thermal effective mass = class size + tractored ship size, or class size + Capacity / 25 x Slipways for a towed mobile yard (both fields in FCT_Shipyard). Actual fleet speed can fall because of damaged engines, overhaul effects, towing or nebula speed caps, which changes thermal emission indirectly. The thermal signature does not recalculate engine damage itself. Only the presence of move orders matters, so a stationary fleet with orders can differ from one with none. The sensor equations on this page apply no nebula range multiplier, no thermal term for reactor load, weapon recharge or shields, and no cloak multiplier on thermal, shield or search EM.

Weapon hits and explosions have a separate environmental contact path. The game creates or merges impact and explosion contacts for every race with a presence in the system, without any passive strength or range test. Energy weapon impacts mark the impact position. They are not an extra continuous emitter signature. These contacts are cleared at the start of the next main increment.

Sensor component definitions and live source selection

Section titled “Sensor component definitions and live source selection”

For a designed active sensor, let A be the active strength technology AdditionalInfo, H the sensor size in HS, E the EM sensitivity technology AdditionalInfo, and R the resolution in HS. The saved maximum range (MaxSensorRange in FCT_ShipDesignComponents) is:

maximum range = 1,000,000 x sqrt(A x H x E x R^(2/3) / 3.1416) km

Missile fire control design mode doubles that range (x 2) and saves the component as a missile fire control. It never becomes a ship search sensor source, because ship sources are built only from active search sensors. Saved strength = A x H. Saved ECCM = ECCM technology AdditionalInfo, truncated to a whole number. Electronics hardening changes cost and destruction chance, not this range equation.

A passive thermal or EM component has sensitivity = H x sensitivity technology AdditionalInfo. Its detecting strength is that ComponentValue. In ordinary ship sources the installed quantity does not add strength. Hardening changes its cost and destruction definition.

When sensor sources are rebuilt, a ship first clears its current active sources. With active sensors on (ActiveSensorsOn in FCT_Ship), it adds one source for each active sensor design when the ship has no damage records or the component’s undamaged count is not 0, and when the sensor’s resolution is no larger than the ship’s maximum active resolution. In ordinary valid classes this admits surviving sensors. With no damage records, a sensor with an installed quantity of 0 is also admitted. A negative undamaged count is also admitted, because only a count of exactly 0 excludes a sensor. Range is the component’s saved MaxSensorRange, strength and resolution are truncated to whole numbers, and ECCM is copied. The default maximum active resolution is 1,000. The Max Active Resolution field in the Naval Organization window sets it (MaxActiveResolution in FCT_Ship) and raises any value below 1 to 1. It filters which sensors emit. It is not a lower bound on target size.

If active sensors are off on an NPR ship, its resolution 1 active sensors are added anyway. That path ignores the maximum active resolution and does not copy ECCM, which leaves ECCM at 0. Passive sources work regardless of the active toggle and use one raw component sensitivity under the same condition (no damage records, or an undamaged count that is not 0). Ordinary sources get no crew, commander, overhaul or reactor power multiplier.

ELINT differs. Its strength sums the values of undamaged ELINT modules, and it provides both an EM passive source and an ELINT source. The ship commander’s Intelligence bonus changes intelligence accumulation, not range strength. ELINT reach and sensor intelligence covers catalogue discovery and knowledge. Detection reach follows the passive equation below.

The game-wide source list holds ship systems, missile sensors, Deep Space Tracking Stations and ground active sensors. Deep Space Tracking Stations give count x best researched improved planetary sensor strength technology AdditionalInfo as both their thermal and EM strength. Missile sources take their values from the missile type (SensorRange, SensorResolution, SensorStrength and ECCM in FCT_MissileType), including ECCM. Ground sources use the ground unit class range, strength and ECCM, with resolution 1. Building these ground sources does not check whether the formation’s active sensors are on.

Source selection is not sensor stacking:

  • Active sources with the same observer race, system, resolution, range and position collapse to the first one. ECCM, strength and component are not compared, so of two sources with equal range and resolution and different ECCM, the better ECCM can be lost depending on the order they were added.
  • Thermal and EM sources first collapse equal strengths at one position, then only the strongest source at each observer, system and position is kept. ELINT gets the same strongest-at-location reduction.
  • For each observing race and system, active sources are tried by maximum range, largest first, and passive sources by strength, largest first. Different locations are checked independently, and the first source actually in range wins that contact channel.

For an observer source with range M, resolution R and ECCM K, and a target with active cross section C and sensor jammer strength J:

active range = M x (C / R)^2 km when C is below R, otherwise M

When J is greater than K, the active range is multiplied by 0.75^(J - K).

Detection succeeds when the straight-line distance is no more than the resulting range. Targets larger than the resolution do not raise the range above M. The jammer strength comes from the first sensor jammer component of the class, and its ComponentValue counts only if at least one copy is undamaged. Quantities do not stack jammer strength. The ship detection equations above add no die roll, commander sensor bonus, crew multiplier or nebula factor.

For passive sensitivity S and a positive target thermal or EM signature T:

passive range = 250,000 x sqrt(S x T) km

The same inclusive boundary applies. Thermal sensors use the live thermal signature. EM sensors separately test active shield points and each emitting search sensor. The target ship’s jammer or cloak does not scale passive range. ELINT uses this equation with ELINT strength to intercept search sensor emissions, but observing that emission for catalogue knowledge is separate from getting an active cross-section track.

The passive range circles on the tactical map use the same equation for chosen signatures of 10, 100, 1,000 and 10,000. Ship sensor summaries can report the best undamaged active sensor, or its range at a target resolution, without checking whether active sensors are on or the emission resolution filter. Such capability figures do not prove that the sensor is currently active.

Range and distance comparisons are not rounded. The source strength and resolution, truncated to whole numbers, are separate from the component’s full values. A rounded signature or range on screen need not equal the exact value compared. Source dimensions and flags come from the saved component definitions. Current race sensor technology is not reapplied to existing ship components at each check.

Sensor checks use the same range equations with different target inputs. Populations do not get a generic ship-like active cross section.

Target Detection signature and conditions
Missile salvo, active max(0.3, missile size / 20), compared against resolution with the squared ratio. The contact strength records the missile size in MSP instead. The number of missiles does not multiply the detection size.
Missile salvo, thermal Engine ComponentValue x NumEngines, or size / 400 for a missile without an engine. No salvo-count multiplier.
Missile salvo, EM SensorStrength x SensorResolution from FCT_MissileType, only if the active strength is positive. No ship-style minimum of 1.
Ground active sensor emission Ground unit class sensor strength at the population’s position. Emitters are not summed by this check.
Population thermal (population + 20 x shipyard workers + sum of installation ThermalSignature x amount) x 5. For an NPR the population term is max(0, total population - 0.01).
Population EM (10 x population + 20 x shipyard workers + sum of installation EMsignature x amount) x 5, with the same NPR subtraction.
Population shipyard complex, active (sum of yard Capacity x Slipways) / 25. Squared resolution penalty if smaller than the resolution.
Ground forces, active A fixed comparison size of 5 HS against resolution, when the total ground force signature is positive. The recorded contact strength carries the calculated force information.
Stabilised jump point, active A fixed 500 HS signature, for points the observer has not charted. Coming within range charts the point and logs the event “New jump point detected in” with the system name (event type Jump Point Detected, ID 138 in DIM_EventType).
Mobile towed yard, active Capacity x Slipways / 25, at the towing fleet’s coordinates.

Installation signatures come from ThermalSignature and EMsignature in DIM_PlanetaryInstallation, listed in the Planetary installation catalogue.

When the game observes a population’s EM signature, it checks that the population’s thermal signature is not 0, rather than its EM signature, and it stores that EM track with the shield contact method (ContactMethod 4 in FCT_Contacts). A zero thermal signature therefore prevents ordinary EM detection of the population even when its EM signature is positive. The separate population ELINT check tests the EM signature itself. Missile active detection does not apply the ship sensor jammer term.

Normal sensor checks run at the current game time after each movement, logistics and combat sub-pulse. Before them, the game refreshes each race’s system presence, leaves out systems flagged for no sensor checks (NoSensorChecks in FCT_System), and selects the systems where more than one race is present. The ordinary ship list leaves out docked parasites, both as sources and as normal targets. Targets of the observer’s own race are skipped. Sensors in another star system are never used.

Transit checks restrict the targets to the transiting fleet, largest ships first, and stop for an observer once that transit is detected. The same check also handles jump point discovery. Checks for new missile launches restrict salvo targets to those launched at the current game time and skip ships and populations. Sensor sources are rebuilt for these checks too. The sensor delay (SensorDelay in FCT_Ship) is saved state that counts down by each sub-pulse length and stops at 0. Some fire control and jump rules use it, but neither the ordinary ship source refresh nor the range checks leave out a source whose sensor delay is above 0.

Transponder modes (TransponderActive in FCT_Ship) are Off (0), Friendly (1) and All (2). Off creates no transponder track. Friendly requires the observer’s relation to the ship’s race to be Friendly or Allied. All treats every processed observer as Allied and creates a track for each, with no distance or strength check. An observer with no active, thermal, EM or ELINT sources is skipped earlier, so transponder processing is still gated by that source check. The docked-parasite exclusion applies here too. Civilian shipping line ships start with Friendly transponders.

Detection writes or renews contact records in FCT_Contacts, not the class definition. Tracks carry the contact method (ContactMethod 1 active, 2 thermal, 3 search sensor emission, 4 shield or population EM, 5 transponder, 6 impact or explosion), the signature, coordinates, speed and the current game time. Tracks from different channels can coexist. Search emission tracks can identify strength and resolution separately from a size track. Sensor tracks and remembered hull histories covers how prior and stale tracks are kept and what each observer remembers about classes and hulls. A track still shown on the map does not prove a current in-range detection. A ship marked as a designated target (DesignateAsTarget = 1 in FCT_Ship) also gets an active track for its own race, outside the ordinary hostile source range checks.

These are arithmetic consequences of the formulas above, not results of automated simulation tests.

  1. Ordered recharge. Reactor generation 6, weapon A with requirement 4 and rate 4, weapon B with requirement 8 and rate 4, both empty. After 5 seconds the budget of 6 recharges A by 4, then B by 2. B keeps a debt of 6. Proportional sharing would give a different state, but it is not the allocation rule.
  2. Separate shields. Two undamaged strength 50 shield generators with RechargeRate 300 regenerate 40 points in 120 seconds, capped at the effective maximum. A ship with no reactor output follows the same shield calculation.
  3. Passive scaling. Sensitivity 4 against signature 100 gives 250,000 x square root of 400 = 5,000,000 km. Doubling only the sensitivity raises the range by the square root of 2, not by 2.
  4. Resolution and jammer. A 40-million-km sensor with resolution 20 against cross section 10 gets 10 million km before jamming. Jammer 2 against ECCM 0 multiplies this by 0.75², giving 5.625 million km.
  5. Cloak affects active size. A 100 HS class with cloak rating 0.5 has a cross section of 50 HS. Against resolution 100 its active range is one quarter of nominal. Against resolution 20 it still gets full nominal range, because 50 is at least 20. Any matching cloak damage restores 100 HS in the live cross section.
  6. Different class axes. An armed 20 HS class with no survey or hangar dominance is a FAC. An armed 20.01 HS class is a Warship. An unarmed 10 HS survey craft has FighterClass set but the gravitational survey ship main function, not an inferred Fighter role.

The main limits on reading these rules are these:

  • Design warnings are not general live firing gates.
  • Reactor output is neither engine EP nor stored fuel or MSP.
  • Shields have their own recharge process.
  • Sensor component quantity usually gives redundancy rather than more reach.
  • Ship thermal uses the nominal engine count with the actual fleet speed.
  • Ordinary active source merging can discard different ECCM values.
  • Capability displays can ignore activation state.
  • Flags and totals loaded from the database can differ from a later recalculation.

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