State and scope

Section titled “State and scope”

This page follows one star system from the request that creates it, through physical generation, linking and race knowledge, and the ongoing changes that each increment slot applies, to the paths that delete it and what a save keeps afterwards. The lifecycle is a synthesis of separate game systems, not a single system state machine.

The phases have separate owners, and this page links them rather than repeating their formulas. Star system and planetary generation owns stellar, planetary, environmental, mineral and ruin rules. Planetary terrain owns dominant terrain. Jump point network and galaxy topology owns jump point counts, system numbers, connection selection, gates and unlinking. Exploration and discovery and observation and knowledge own race knowledge. Terraforming, system disasters, game time, salvage and archaeology and system danger ratings own the ongoing changes. Spacemaster interventions owns the editing tools, and object identity and reload owns ID counters.

A star system is not one object. The physical model is a system record plus separate game-wide lists of stars, bodies, jump points and Lagrange points that point back at it. Race knowledge lives in further records kept for each race. No phase below rewrites all of them together, so each phase must be read for the objects it actually touches.

Object Holds State carried between phases
System (FCT_System) Physical system record in the game’s list of systems SystemID, SystemNumber, the catalogue entry, the generation origin system, the native race chance, the primary component mass, Age, AbundanceModifier, JumpPointSurveyPoints, SupernovaElapsedTime, SupernovaForce
Star (FCT_Star) One stellar component in the game’s list of stars Component, OrbitingComponent, Luminosity, DisasterStatus,
System body (FCT_SystemBody) Planet, moon, asteroid or comet in the game’s list of bodies Environment columns, mineral deposits by mineral, ruin columns, names by race, the body’s save state
Jump point (FCT_JumpPoint) One point in the game’s list of jump points The linked point and its stored ID WPLink, JumpGateStrength, the race records by race
Race system survey (FCT_RaceSysSurvey) One race’s knowledge of one system Name, the naming theme (NameThemeID), DiscoveredTime, SurveyDone, GeoSurveyDefaultDone, DangerRating, map coordinates
Race jump point survey (FCT_RaceJumpPointSurvey) One race’s knowledge of one point Charted, Explored and display flags
Catalogue entry (DIM_KnownSystems) Catalogue descriptor, real or procedural KnownSystemID, whether the entry is procedural, component types, coordinates

Two further records follow the system. A race and body survey pair (FCT_SystemBodySurveys) sits in a game-wide list, and each gravitational survey location (FCT_SurveyLocation) holds the races that finished it. The game’s list of removed system bodies is the only deletion ledger, and only some removal paths write to it.

A system has no name of its own. Each race gives it a name in its own race system survey, and each race can name bodies (FCT_SystemBodyName). Generated bodies also carry a default name. Asteroids are named “Asteroid #” plus their number, such as “Asteroid #3”, and comets are named “Comet #” plus their body ID.

Phase table

Section titled “Phase table”

Rows are listed in dependency order. One request does not run every row, and later rows repeat at their own clocks.

Phase Entry point Slot State written Boundary to the next phase
1. Request Setup, exploration, NPR start, or Spacemaster The requesting action The generation settings, system number or catalogue entry System generation does all physical work
2. Identity System generation Same generation SystemID, origin, whether it is Sol, number, race chance Star creation reads the catalogue entry
3. Stars and bodies Star creation for each component Same generation Stars, bodies, moons, belts, trojans, comets, Lagrange points Pruning can remove what was just made
4. Native races Native race attempts Same generation New races and their surveys Jump point creation follows the race attempts
5. Jump points and features Jump point and survey location creation, then the special-feature block Same generation Unlinked points, 30 survey locations, , wrecks System not yet in the game’s list of systems. Links exist only after exploration
6. Settle and insert Forced orbital update, insertion into the list of systems Same generation Positions, eccentric climate, list entry The request adds links and knowledge
7. Link and know First exploration of a point, or the setup survey step Same action as the request Point links (WPLink), race surveys, names, map position Knowledge grows through survey work
8. Ongoing change Increment processing Sub-pulse, increment end, construction cycle Positions, climate, atmosphere, radiation, ruins, danger, gates Each slot has its own clock
9. Deletion Bare system removal, full system cleanup, partial removals The deleting action or the disaster update List removals, unlinked peers, the removed body ledger Saving decides what the database keeps
10. Save and reload Saving and loading a game Player save or load Table rows, reconstructed references Reload forces a short orbital update

Creation requests

Section titled “Creation requests”

Every request reaches the same system generator. The requests differ in the generation type, the system number they pass, the minimum jump point count and two switches. The hydrosphere cap limits oceans to 70% (a HydroExt above 70 is set to 70) and also suppresses the special-feature block. The skip-races switch suppresses native race attempts and the feature block. A successful native race sets it during generation, so a system that receives a native race gets no special features. The feature block never runs for Sol either.

There are three generation types, Neutral, NPR and Player. Only NPR and Player assign a native race chance. A Player system takes the NPR Generation Chance (by Player) option (FCT_Game.RaceChance, new game default 30). An NPR system takes the NPR Generation Chance (by NPR) option (FCT_Game.RaceChanceNPR, new game default 10). A Neutral system keeps 0 and never rolls for a native race.

Request Requesting action Type Number passed Switches First race survey
New game Sol New game creation Neutral, Sol 0 skip races Each player race at race creation
NPR home, random NPR generation Neutral A random unused number from 1 to the Maximum Number of Systems setting (FCT_Game.NumberOfSystems), or in known-star mode a random unused catalogue entry within the NPR distance range cap, skip The NPR at race creation
NPR home, template NPR creation from a template Neutral Same as above, with the distance range starting at 0 cap, skip The NPR at race creation
Spacemaster Create System Spacemaster system creation Neutral Random unused, or the catalogue entry selected in the dialogue no cap, races not skipped Selected race, after acceptance
Spacemaster Create Habitable Same Neutral Same cap, skip Selected race, after acceptance
First exploration First exploration of a jump point NPR or Player, by the exploring race A random system number drawn for the jump connection, or 0 in known-star mode whether the request skips native races Explorer, after the link
Spacemaster Explore JP Spacemaster exploration of the selected jump point in the System Generation and Display window NPR or Player, by the selected race Same as exploration no cap, races not skipped Selected race, after the link
NPR starting network NPR start-up exploration, one point at a time NPR Same as exploration skip The NPR, after each link
Neutral skip

The system number comes from the request in procedural mode and from the catalogue in known-star mode (FCT_Game.UseKnownStars 1). Generation stores the passed number first, and a real catalogue entry then replaces it with its KnownSystemID. In known-star mode a request that passes no entry gets a nearby unused entry. In procedural mode generation builds a temporary catalogue entry from the system number and marks it as procedural, so the procedural number stays and the system has no catalogue entry. Sol always gets number 0, and the new game then links it to the catalogue entry with KnownSystemID 0 (Sol) in either mode. The numbering schemes are in system numbers and the known-system catalogue.

Black hole generation runs once at new game creation and creates no system. It adds up to 50 catalogue descriptors, with IDs of the game ID times 10,000 plus 1 to 50, and writes them to DIM_KnownSystems at once. A black hole becomes a system only when a later known-star request draws that descriptor. Star creation then skips planets and comets for the BH spectral class. Black holes and brown dwarfs has the details.

Three requests run a generate-and-reject loop. Spacemaster Create Habitable, NPR home generation and the template path each generate a system, look for a homeworld candidate and discard a failed system with bare system removal before trying again. Each rejected system has consumed its SystemID, star and body IDs, and the next attempt does not reuse them.

The race survey appears at different moments. The Spacemaster setup step creates the race’s jump point records and the system survey after acceptance, and creates no survey when no race is given. Race creation creates the home survey and then uncharted jump records for its home system. Exploration creates the explorer’s survey only after the endpoint link.

NPR start-up exploration is a request generator of its own. It explores every unlinked point of the frontier, depth by depth, with native races skipped and connections to Sol prevented. After each link it runs a full system survey with mineral generation. That survey regenerates the shared deposits of every body whose ground survey was incomplete and marks the ground survey complete. Start-up systems therefore begin play with their ground potential spent. The network shape is in NPR start-up network.

Physical generation order

Section titled “Physical generation order”

Inside system generation the physical order is fixed. Each star creates all of its own bodies before the next star exists, and each body runs its environment, ruin and mineral steps before the next body is created. The table gives the order and the page section that owns each row.

Step Work Owner
1 New system record, SystemID, origin, whether it is Sol, number Creation lifecycle
2 Catalogue entry, or a procedural entry built from the system number Stellar selection
3 One star creation per component in component order Stellar orbits
3a Primary sets mass, age, abundance and jump point survey points Same
3b Planet slots, construct potential, one planet creation per slot Planetary slots
3c Belt slot fills an asteroid belt Small bodies
3d Planet physics and environment Environment order
3e Lagrange point for a superjovian or a gas giant above mass 200, then insertion into the list of bodies Lagrange points
3f Trojans on giants Small bodies
3g Gas giant destabilisation and the distance limit remove bodies Planetary slots
3h Moons for each surviving planet that is not tidally locked Moons
3i Comets for a primary that is not a black hole Small bodies
3j Sol imports fixed bodies instead of 3b to 3i Sol overrides
4 Companion pruning under the Limited Planet Distance option Stellar orbits
5 Native race attempts on planets and moons
6 Asteroid renumbering outside Sol Creation lifecycle
7 Jump points, then 30 survey locations Jump point creation
8 , random wrecks Special features
9 Forced 10,000 second orbital update Body motion
10 Insertion into the game’s list of systems This page

Several steps carry their own numbers. In step 3a the primary sets JumpPointSurveyPoints to 400 x system scale factor, rounded down. The scale factor is the square root of the primary’s mass for a mass up to 1, and the cube root above 1. Step 3g runs two rules. Gas giant destabilisation applies when the Gas Giant Effects option is on (FCT_Game.GasGiantEffects) and acts around planets above mass 50. The distance limit applies when the Limited Planet Distance option is on (FCT_Game.LimitPlanetaryDistance). It removes a planet or asteroid whose periapsis lies at or beyond 80 AU times the system scale factor, and moves a planet or asteroid that only crosses that distance to a new random bearing inside it. Step 4 applies under the same option to companion stars. A companion whose parent star is gone is removed. A companion whose orbit crosses 160 AU is moved to a bearing inside 160 AU. A companion whose periapsis is at or beyond 160 AU is removed, unless the primary star or an earlier companion whose orbit crosses 160 AU has gas giants or superjovians and the companion has a Lagrange point of its own. Only a companion whose orbit crosses 160 AU adds its gas giants and superjovians to that count, once it has been moved inside 160 AU. A companion kept because its orbit stays within 160 AU, or because it has a Lagrange point, adds nothing. Step 6 names the asteroids “Asteroid #1” upward, in order of star component and then orbital distance.

The per-body environment order in step 3d is atmosphere, hydrosphere, the optional cap at 70%, evaporation of liquid water when the body has some, albedo, hydrosphere phase, runaway greenhouse, pressure refresh, ruin or construct for terrestrial planets, minerals, then dominant terrain. Gas giants and superjovians skip all of it, get zero atmospheric pressure and zero hydrosphere, and take the gas giant mineral routine. Moons run the same family of steps in their own environment step, with a surface temperature refresh in place of the phase step. Terrain selection is in generation assignment.

Ruins carry provenance from the request. Ruin assignment looks for a ruin civilisation near the generation origin system, or near the system itself when no origin is set. The origin is the exploring origin system for an exploration request and is unset for every other request. The origin is never saved, so it matters only during generation. Comets skip the terrestrial ruin-or-construct step and roll for a ruin directly on their own gravity test. Comets below 2,000 km radius also use the comet mineral routine.

Generation creates stars and bodies as it goes and does not undo them. The system itself joins the game only at step 10. When system generation itself fails, the game shows the error Function #1562 and generation ends with no system. Such a failure therefore leaves earlier stars and bodies in the game with no system. An error inside the creation of one star shows Function #1564 instead. That star creation ends there and generation carries on. An error inside the planetary system of one star shows Function #1569. The generation of that planetary system ends there and the rest of generation carries on. Steps 4 and 3g delete freshly made objects through star removal and body removal. Star removal renumbers stars by component across every system, as creation and deletion helpers describes, so pruning a companion here also lowers higher component numbers in other systems.

The Lagrange point step renumbers the system’s points before it adds the new point to the game’s list of Lagrange points. The new point therefore keeps the default number 0 until a later renumbering. That happens when another point is created in the system, when the Spacemaster deletes a point there, or on reload.

The feature block of step 8 creates foreign knowledge before any player knows the system. A random wreck gives its owning special race a race system survey, jump records charted at 1 and body survey records. A native race created in step 5 gets its home survey at race creation. An NPR flagged to await explored transits stops the race attempts and is recorded as the race awaiting exploration. The feature conditions are in special race lifecycles.

Linking and knowledge

Section titled “Linking and knowledge”

A generated system has jump points but no links. Exploration supplies the first link. Only first exploration and the link rebuild at game load ever set a point’s link. Setup systems, Spacemaster systems therefore stay isolated until some race explores an unlinked point that resolves to them, or explores out of them.

First exploration applies this order after a successful transit, or when a point is explored directly, as NPR start-up exploration and the Spacemaster Explore JP button do.

  1. A point that already has a link reuses the peer’s system and skips steps 2 to 4.
  2. Otherwise it picks an existing system or generates one, as connection selection on first exploration describes.
  3. If generation recorded a race awaiting exploration, the new race gets its surveys and start-up network and the destination is replaced.
  4. It links one unlinked destination point in both directions, creating one when none exists. With several unlinked points it picks one uniformly.
  5. It reads the naming theme from the origin survey and drops a theme with ID 0.
  6. For an unknown destination it creates uncharted jump records, marks the arrival point charted and explored, creates and names the survey and places it on the galactic map relative to the origin system.
  7. For a known destination it marks the arrival point charted and explored.
  8. It marks the departure point explored and copies the result to the orders of other fleets of the same race aimed at that point.
  9. A fleet that found a new system gets the star systems explored measurement and a history line, then the habitable worlds discovered measurement, which counts each body with an atmosphere whose colony cost is 0 for the race’s primary species.

The order means the physical link exists before the race knows the system. Another race’s earlier link can bring an explorer straight to a system that is physically complete and populated. Exploration and first transit owns the knowledge records, and history records owns the history line.

Creating a race’s jump point record writes the race’s view of one point. An explored value of 0 stores 0. A nonzero value sets explored only when the point is linked and the race already has a record on the peer, and it then marks that peer record explored too. Creating a jump point gives every race that already knows the system an uncharted record for the new point. A point created to receive a link is therefore visible to existing observers as an unknown location.

Creating a race system survey stamps the discovery date (Discovered) and time (DiscoveredTime), stores the naming theme and chooses the name. A system with no bodies starts with GeoSurveyDefaultDone true. An NPR survey also gets its own system-level AI state, described in NPR tactical and system behaviour. The naming order is in system and system body names.

Knowledge then grows by survey work, which never changes the physical system except in one case. Gravitational survey locations chart jump points but do not explore them. Orbital geological completion creates a race and body survey pair and reports existing deposits. Ground survey completion runs the mineral generator again for the surveying race, which changes the shared deposits that every surveyed race reads. Survey knowledge and shared physical changes describes that boundary.

Other races learn the system through their own exploration, through treaties or through intelligence imports. Treaty sharing of geological and gravitational results requires the recipient to know the system already. An import creates a survey with the sharing race’s name for the system and copies that race’s charted flags. It sets a point explored only where the point is linked and the importer already has a record on the peer. Sharing and imported knowledge owns these rules.

Ongoing change by increment slot

Section titled “Ongoing change by increment slot”

After insertion, a system changes only when an increment slot reaches it. Increment processing has three slots that touch systems. Each sub-pulse runs movement, logistics and combat. Increment end runs once per time click. The construction cycle runs when the current game time minus the last growth time (FCT_Game.LastGrowthTime) strictly exceeds the construction cycle time (FCT_Game.MinConstructionPeriod), and it receives the whole elapsed interval. New games default the cycle time to 430,000 seconds. Game time owns the full timeline.

Change Slot Writes Owner
Jump gate completion Sub-pulse, fleet orders JumpGateStrength, JumpGateRaceID Build time and completion
Lagrange stabilisation Sub-pulse, fleet orders New Lagrange point at the body bearing +150 (the normal +60 plus 90 degrees for a stabilised point) Lagrange points
Tomb emergence
Supernova front, stellar disasters, death spiral Construction cycle, first step Radiation, luminosity, ship damage, deletion System disasters
Rift growth and rift radiation Construction cycle Rift diameter, body radiation Rift radiation
Radiation and dust decay Construction cycle RadiationLevel, DustLevel, surface temperature Contamination
Orbital motion Construction cycle Bearings, coordinates, eccentric climate, Lagrange positions Which bodies move
Water vapour condensation and evaporation Construction cycle Vapour gas, HydroExt Hydrosphere
Terraforming Construction cycle, population production tick Gas pressure, climate, terrain Terraforming
Ruin installation recovery Construction cycle, after production AbandonedFactories, RuinID, RuinRaceID Ruin recovery
Danger decay Construction cycle, second-to-last step FCT_RaceSysSurvey.DangerRating Danger rating decay

Orbital motion and climate

Section titled “Orbital motion and climate”

Orbital motion runs once per construction cycle with the whole elapsed seconds. No sub-pulse or increment-end step moves bodies, so planets hold their positions between cycles while fleets move every sub-pulse. With Orbital Motion for Planets off (FCT_Game.OrbitalMotion 0) and no forced update, nothing moves.

Stars move first in component order, then planets, comets and free asteroids, then moons, then trojans, then Lagrange points, then fixed bodies. Free asteroids move only when Orbital Motion for Asteroids is on (FCT_Game.OrbitalMotionAst 1) or the update is forced. An eccentric body also recomputes its ellipse, its BaseTemp and its climate from its new distance. Its BaseTemp = 255 / sqrt(distance / sqrt(star luminosity)), with the distance to its star in AU and a minimum of 4. The hydrosphere phase, pressure and terrain are then refreshed. A circular body keeps its climate. A moon of an eccentric planet copies its parent’s BaseTemp and refreshes the same climate values. Body star and moon motion owns the geometry.

Every Lagrange point is reset to its body’s bearing plus 60 degrees on each orbital update. A stabilised point created at plus 150 therefore moves to plus 60 at the next orbital update that covers it. That update can be a construction cycle with orbital motion enabled, a forced editor update or the forced update at reload.

Forced orbital updates outside the cycle happen at generation (10,000 s), at new game Sol setup (10,000 s), on reload (60 s), in the death spiral (10 s, for the decaying body), in the Spacemaster star editor (60 s) and in the Spacemaster body editor (1 s).

Recomputing a star’s body climates sets BaseTemp for every body of the star that is not a moon, from its current distance and the star’s luminosity by the same formula with the same minimum of 4. It copies parent temperatures to moons and refreshes surface temperature, pressure and terrain. Two events run it. New game Sol setup runs it once. The stellar disaster step runs it after every status step other than radiation, including a death spiral status that the Game Information window can copy to the star.

Surface temperature always comes from the atmosphere-based surface temperature update, which receives the summed unfrozen greenhouse and anti-greenhouse gas pressures. The hydrosphere transition step changes the hydrosphere phase and can trigger evaporation for that body alone. The terrain climate refresh keeps terrain inside its family. Climate refresh lists the events that refresh terrain.

The game has steps that would convert a body’s hydrosphere to water vapour and condense excess vapour back into hydrosphere, but no part of play described here runs them. Water moves between HydroExt and vapour through the construction cycle’s water vapour condensation and evaporation steps. Evaporation also runs for a single body from a hydrosphere phase transition.

Terraforming

Section titled “Terraforming”

Terraforming runs inside each population’s production tick, and only when the population’s Earth-equivalent annual terraforming capacity is positive. It does nothing when no gas is selected or when the body’s gravity is below 0.1. It adds or removes an amount of the selected gas scaled by capacity, elapsed years and body surface area.

Gas change = Earth-equivalent annual capacity x elapsed years x 511,187,128 / (4 x 3.1416 x body radius²) atm, with the capacity in atm and the body radius in km. The figure 511,187,128 is the Earth surface area in square km.

The step then refreshes the shared body’s total pressure, hydrosphere phase, pressure display, terrain and colony cost. Several populations on one body therefore change the same atmosphere in turn within one cycle. Terraforming owns gas selection, targets and capacity, and total and body-size normalisation owns the formula.

Radiation, rifts and disasters

Section titled “Radiation, rifts and disasters”

The system disaster update runs three parts in order. Active supernova fronts advance at one light year per 31,536,000 seconds. Each star with a disaster status then runs its stellar disaster step. A warming or cooling status raises or lowers luminosity by 1%, 2% or 3% of the current luminosity per year, by level. A radiation status hands over to the radiation step. The game-wide Sol death spiral runs last.

Only the Sol primary ever has a stellar disaster status. New game setup and the Game Information window write it on the Sol star, and loading a game restores it from FCT_Star.DisasterStatus. Warming, cooling and radiation deletion therefore apply to Sol alone.

Radiation and dust decay runs right after the disaster and rift steps, so radiation added in a cycle starts to decay in that same cycle. Each cycle a body loses radiation x (decontamination rating + 0.1) x elapsed years, and at least 100 x elapsed years, where the decontamination rating is that of the ground formations on it. It loses 250 x elapsed years of dust. Neither value drops below 0. Rift radiation runs inside the rift step only when it passes a system-count gate and a rift exists.

Ruins, tombs and danger

Section titled “Ruins, tombs and danger”

Ruin installation recovery consumes a ruin site one abandoned installation per successful element roll. Each construction element in a formation that is not set to do-not-recover rolls a d10,000 against morale x xenoarchaeology bonus x 500 x elapsed years x effective construction rating. Once the count reaches zero the step clears AbandonedFactories, RuinID and RuinRaceID. It is the only part of the regular simulation that writes a body’s ruin state. The Spacemaster Create Ruin and Regen Min controls also edit it. Construction recovery owns the roll.

Each group holds a reference to the body chosen when the ruin defenders were scheduled at generation. Tomb scheduling owns the clock.

Danger decay lowers each race’s positive rating on its own survey. Each cycle the rating falls by max(rating x elapsed days / 365, elapsed days), rounded down, and it stops at 0. A system’s danger therefore lives and dies with the survey record, not with the physical system.

Deletion and what survives

Section titled “Deletion and what survives”

Triggers

Section titled “Triggers”
Trigger Entry point Removal Survey records
Generate-and-reject retry Setup, NPR home and template loops Bare system removal None existed yet
Spacemaster Delete System The System Generation and Display window Full system cleanup, system record removed Removed
Spacemaster Trigger Supernova Galactic map, a supernova with force 1.0 Full system cleanup, system record kept Kept
Radiation disaster System disaster update on a destroyed system Full system cleanup, system record removed Removed
Spacemaster partial deletes Delete star, body, asteroids, jump point, Regen JP Star removal, body removal, jump point removal with peer unlinking Kept
Death spiral Earth decays below 1,000,000 km Earth and its first moon taken straight out of the list of bodies Kept
Fixed body population removed Removal of a population on a fixed body Body removal Kept

No other path described here deletes a whole system. Supernova fronts irradiate and damage reached systems without deleting them.

Bare system removal

Section titled “Bare system removal”

Bare system removal takes bodies, stars, jump points, Lagrange points and the system entry out of their lists. It does not unlink peers, write the removed body ledger or touch races, fleets, populations, waypoints or wrecks. It is used only to discard a system before anything links to it, and the habitable and NPR home loops run with races and features suppressed. The Create System button runs with the habitable requirement off, so it never reaches the retry. System removal and unlinking describes the network side.

Full system cleanup

Section titled “Full system cleanup”

Full system cleanup queues every body in the removed body ledger and removes stars, except component 1 when the system record is preserved. It then unlinks jump points and removes Lagrange points and waypoints. It removes fleets, missile salvos, mass driver packets, , contacts, wrecks and lifepods. It removes race surveys unless the record is preserved, removes populations, and finally removes the system unless the record is preserved. System deletion and surviving bookkeeping owns the stage table and the fleet guards.

Removing a jump point finds its peer, clears the peer’s link and WPLink, sets Explored to 0 in every race record on the peer and keeps Charted. The neighbour system keeps a charted, unexplored point that a later transit explores again, and that exploration picks a new destination through the normal rules.

The two partial removals differ in bookkeeping. Body removal queues the body and its direct children in the removed body ledger and removes the body’s own Lagrange points, and the populations of the body and its children. Star removal removes the star’s bodies, Lagrange points, and populations without queueing the bodies.

What survives a deletion

Section titled “What survives a deletion”
Record After a full deletion After a supernova (system record kept)
System record, primary star Removed Kept, with SupernovaElapsedTime 1 and SupernovaForce 1.0
Race surveys, names, danger ratings Removed Kept
Neighbour jump records Charted kept, explored reset Same
Race and body survey pairs Kept in memory, nothing removes them Same
Kept in memory, nothing removes them Same
Kept, nothing removes them Kept
Catalogue entry Free for reuse Still used
Fleets that cannot be removed Kept with a removed survey Kept
Wrecks inside the system Removed Removed

The game can delete one race and body survey pair, but only the Spacemaster No Geo Survey button does so. No deletion path does it, so survey pairs for deleted bodies stay in memory.

The game also has a step that removes every population pointing at one race system survey, but no part of play described here runs it. Deletion removes populations through the population stage of full system cleanup instead.

A full deletion frees the catalogue entry. A catalogue entry counts as used only while some system references it. In known-star mode a later exploration can therefore regenerate the same catalogue star with new random planets and a new SystemID. A supernova keeps the system record, so its entry stays used.

Tomb groups keep references to removed bodies until a save and reload drops them.

A radiation deletion logs one System Destroyed event for each race survey of the system before the cleanup, with the text “Any jump point connections have been severed”.

Worked examples

Section titled “Worked examples”

All three walk-throughs are synthetic. They assume default settings, 5-day increments of 432,000 seconds and the option values stated in each row. Each construction cycle therefore has elapsed years = 432,000 / 31,536,000 = 0.0136986.

Example A. A known-star system found by exploration that later suffers a supernova

Section titled “Example A. A known-star system found by exploration that later suffers a supernova”
Event Result
T0. Transit A player fleet transits unlinked point JP2 in system X, catalogue entry k1, in known-star mode. The d15 is not 10, so no existing system is tried.
T1. Generate The nearby unused catalogue draw walks unused entries by distance from k1 and returns k2 on the first d5 that shows 1. The die is a d20 instead when a d10 shows 1. Generation runs as Player with origin X and system number set to k2’s ID.
T2. Physical Stars, bodies, a native race attempt, jump points and features run in table order. The forced 10,000 s update settles eccentric climates. The system enters the game’s list of systems.
T3. Link The new system has three unlinked points. One is picked uniformly and linked to JP2 in both directions.
T4. Know The explorer gets uncharted records on all three points, and the arrival point is charted and explored. With FCT_Game.UseThemeInKnownStars 0 the survey takes k2’s display name. JP2 is explored. The fleet gets the star systems explored measurement.
T5. Supernova A Spacemaster triggers a supernova on the new system. Bodies are queued for deletion, companions removed, the primary kept, all three points removed and JP2 in X unlinked with Explored 0 and Charted 1. Surveys stay. SupernovaElapsedTime is 1.
T6. Front X is 4 light years away, measured between catalogue coordinates. The front radius after n cycles is (1 + 432,000 x n) / 31,536,000 light years. Cycle 291 ends at 3.98630 ly, cycle 292 at 4.0000000317 ly, so X is reached in cycle 292.
T7. Exposure The distance in cm is 946,073,047,258,000,000 x 4, so intensity = 10^47 x force 1 / (4 x 3.1416 x distance²) = 5.5567 x 10^8, with the distance in cm. A body in X with pressure 1 atm gains intensity / (pressure x 100) = 5,556,736 radiation. If no body in X has zero pressure, each ship there takes floor(intensity / 100,000) = 5,556 one-point hits. A zero-pressure body makes the disaster update fail with the error Function #1552 before the ship damage, as the supernova front describes. The disaster update ends there for that cycle.
T8. Save The queued bodies are deleted from FCT_SystemBody. The system row keeps its supernova columns. A later transit through JP2 explores it again and generates or links a fresh destination.

The front geometry reads the catalogue coordinates of the exploding system without checking that it has a catalogue entry. In procedural mode before a reload, Sol still holds the catalogue entry with KnownSystemID 0. A supernova triggered in a procedural system therefore meets Sol as a candidate, and building the front fails with the error Function #1552. The failure comes before the elapsed time advances, so it recurs every construction cycle. Each time the disaster update ends there, so the stellar disaster and death spiral parts stay skipped until a reload clears Sol’s procedural-mode catalogue link.

Example B. Sol created at setup and terraformed

Section titled “Example B. Sol created at setup and terraformed”
Event Result
T0. Setup New game creation generates Sol with number 0. Sol imports fixed bodies, gets jump points with the 30 AU limit and settles with a forced 10,000 s update. The star’s body climates are recomputed, and Sol links to the catalogue entry with KnownSystemID 0.
T1. Knowledge Race creation gives each player race a home survey named “Sol” and uncharted jump records. Each Sol body gets a name record per player race.
T2. Terraform A Mars-like body of radius 3,190 km and gravity above 0.1 hosts a population with Earth-equivalent capacity 0.1 atm per year adding nitrogen. One cycle adds 0.1 x 0.0136986 x 511,187,128 / (4 x 3.1416 x 3,190²) = 0.0054760 atm.
T3. Refresh The same tick recomputes total pressure, hydrosphere phase, pressure display, terrain and colony cost. The next cycle’s orbital update leaves the climate alone if the body is circular.
T4. Save The body is in the clean save state, so the save updates AtmosPress, SurfaceTemp, HydroExt, HydroID, the greenhouse factors GHFactor and AGHFactor, and DominantTerrain in its existing row. FCT_AtmosphericGas is rewritten from memory, with entries whose AtmosGasAmount is 0 omitted.
T5. Reload In procedural mode loading does not restore Sol’s link to catalogue entry 0. The reload forces a 60 s orbital update.

Example C. Sol deleted by a radiation disaster

Section titled “Example C. Sol deleted by a radiation disaster”
Event Result
T0. Status Setup gave the Sol star the first radiation status. The Sol Disaster list in the Game Information window shows it as “Solar Radiation 0.05 x Year^3”, stored as 10 in FCT_Game.SolDisaster and FCT_Star.DisasterStatus. The coefficient applied in play is 0.005, one tenth of the label. The other two radiation options show 0.075 and 0.1 and apply 0.0075 and 0.01.
T1. Before 50 years No deletion roll. Each cycle at game year 30 (game time in years) adds 0.005 x 30³ x 0.0136986 / a² radiation, where a is the body’s orbital distance in AU and a moon uses its parent’s distance. That is 1.849 for a body at 1 AU.
T2. Year 60 The deletion threshold is (60 - 50) x 200 x 0.0136986 = 27.397. A d10,000 strictly below it, rolls 1 to 27, deletes the system, a 0.27% chance per cycle. A surviving cycle adds 14.79 radiation at 1 AU.
T3. Deletion Every race with a Sol survey gets a System Destroyed event. Full system cleanup with the record removed takes everything, including the surveys and populations, and unlinks every neighbour point.
T4. Afterwards The game-wide Sol disaster setting FCT_Game.SolDisaster stays set, but no star has a disaster status, so the stellar disaster step finds nothing. The catalogue entry with KnownSystemID 0 becomes unused.

Persistence and reload

Section titled “Persistence and reload”

Saving runs every save step in one transaction. Most system tables are deleted and rewritten from memory, so a removed object vanishes at the next save. FCT_SystemBody and FCT_SystemBodySurveys are the exceptions, and they are where deletions can leave rows behind.

Table Holds Save Reload
FCT_System System record and supernova state Deleted and rewritten The catalogue link is restored from SystemNumber in known-star mode only
FCT_Star Stars, luminosity, disaster status Deleted and rewritten Stars of missing systems are skipped, and the primary component mass is reset from the component 1 star
FCT_SystemBody Body physics, environment, ruin columns Delete queued, insert new, update clean and dirty Bodies of missing systems and stars are skipped
FCT_JumpPoint, FCT_RaceJumpPointSurvey Points, links, gates, race flags Deleted and rewritten Links are rebuilt from WPLink
FCT_LagrangePoint Points without their number Deleted and rewritten Points with missing references are skipped, and the rest are renumbered
FCT_SurveyLocation Locations and race membership Deleted and rewritten Restored
FCT_RaceSysSurvey Names, discovery, map, danger Deleted and rewritten Restored
FCT_SystemBodySurveys Race and body pairs New rows only unless forced Pairs of missing bodies are skipped
FCT_SystemBodyName, FCT_MineralDeposit, FCT_AtmosphericGas Per-body child rows Rewritten from live bodies Restored with their bodies
Rifts and tombs Deleted and rewritten Rifts and tomb groups of missing systems and bodies are skipped
DIM_KnownSystems Black-hole descriptors Written at creation Loaded where GameID is 0 or the current game

Column lists belong to the owners. Topology persistence covers systems, jump points and surveys. Spacemaster persistence covers the body save state rules. Special race persistence covers rifts, gates and tombs. Terrain persistence covers terrain IDs.

Removed bodies and body saving

Section titled “Removed bodies and body saving”

On every save the game issues one delete of the FCT_SystemBody row for each entry in the removed body ledger. The ledger is never cleared, so later saves repeat harmless deletes. It is not saved, so a reload empties it. The save then inserts bodies in the new save state and updates the rest.

Bodies removed without the ledger keep their rows. Star removal, bare system removal and the death spiral take bodies out of the list of bodies only. For bare system removal the rows never existed. For star removal on a saved star, the star row disappears at the next save, and loading skips the orphaned body rows because their star is missing. For the death spiral, Earth’s system and star still exist, so a save and reload should restore Earth and its first moon from their last written rows.

The clean update writes terrain, ruin columns, bearing, surface temperature, pressure, albedo, greenhouse factors, coordinates, radiation, dust, ground survey, name, hydrosphere, distances and orbital speeds. It does not write BaseTemp, Radius, Mass, Gravity, Year, OrbitalDistance or Eccentricity. Only a full recalculation of a body’s environment and orbit, asteroid renumbering, the death spiral and a few editors mark a body dirty. Stellar warming or cooling recomputes BaseTemp without marking bodies dirty. A reload therefore should restore the inserted or last dirty-written BaseTemp of circular bodies until the next disaster step recomputes it from the saved luminosity.

What reload reconstructs

Section titled “What reload reconstructs”

Loading a game restores systems, stars, bodies, jump points, Lagrange points, rifts and gates, and survey locations. It then restores race surveys, body names and body surveys, then waypoints, and restores tomb groups late. It ends by recomputing periapsis, apoapsis and semi-minor axis for every star and body and forcing a 60 second orbital update. A reload therefore moves bodies by 60 seconds and refreshes eccentric climates.

Runtime state that reload does not restore includes the generation origin system, the native race chance, the running number that names trojan asteroids, the race awaiting exploration and whether one is waiting, the removed body ledger, the supernova blast radius and forecasts, and Lagrange point numbers, which loading recomputes. The primary component mass comes back from the component 1 star.

Loading sets the system, body, star and jump point ID counters from the highest FCT_System.SystemID, FCT_SystemBody.SystemBodyID, FCT_Star.StarID and FCT_JumpPoint.WarpPointID across the whole database, every game included. Orphaned body rows still count toward the body maximum. When a deleted system held the highest SystemID in the database, that ID can recur after a save and reload, as deletion reload and restored-branch reuse describes for other subjects.

Concept map

Section titled “Concept map”

Resources

Section titled “Resources”

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