Pipeline and companion references

Section titled “Pipeline and companion references”

This page connects physical generation, race discovery and surveys, sensor observations, retained intelligence, display freshness and reload. Each fact has one owner and one step that writes it. A physical object can exist without a race knowing it. A race can keep knowledge of a ship without a current sensor track. A historical observation can still link to the actual object. None of those relationships alone makes the observation current.

The pipeline has several branches that change independently, rather than one universal “known” flag:

Stage Result What does not follow automatically
Physical generation or connection Stars, bodies, deposits, jump points and their links exist. Every race gets knowledge of the system, its bodies and its jump points.
System discovery or import One race gains its own system record (FCT_RaceSysSurvey) and the jump point rows that go with it (FCT_RaceJumpPointSurvey). The bodies are geologically surveyed, or every connection is explored.
Geological and gravitational work Survey membership, charting and completion flags change. A sensor observation of foreign units exists.
Successful sensor check The observer’s track for that detection method is created or updated, and its knowledge of the ship can refresh. Translation is established, or every capability of the class is revealed.
Intelligence gain or reward Stored observations, thresholds or imported knowledge change. The target is visible now, or the stored observations match every actual value.
Building a view The window shows stored values and some live or calculated values. Time advances, or every stored calculation is refreshed.
Save and load Database rows rebuild the physical records and the observer records, linked by ID. Sensors run again, history becomes current, or IDs gain a permanent identity across database copies.

Generation and first discovery, survey work, the sensor checks, the update of hull knowledge and the loading of a game are separate steps. The sections below follow each one.

The detailed formulas belong to the companion pages:

State ownership and provenance

Section titled “State ownership and provenance”
State Owner and storage What writes it and how to read it
Body profile, atmosphere, deposits The shared body and deposit records (FCT_SystemBody, FCT_MineralDeposit) Physical generation. Later mining, environmental change and ground surveys can change the same world data.
Physical jump connection WPLink in FCT_JumpPoint, the ID of the linked point Exploration can set the link on both ends, separately from any one race’s explored flags.
System name, discovery and map placement The race’s system record (FCT_RaceSysSurvey) Creating the record stamps that race’s acquisition time and chooses its name.
Geological access A race and body pair in FCT_SystemBodySurveys Adding the pair grants membership. The pair holds no copy of the mineral inventory.
Gravitational completion FCT_RaceSurveyLocation rows The location geometry is shared (FCT_SurveyLocation), and the races that completed each location are recorded separately.
Charted and explored connection FCT_RaceJumpPointSurvey Position knowledge (Charted) and connection knowledge (Explored) are separate integers.
Track for one detection method FCT_Contacts, one game-wide list in which each track names its detecting race (DetectRaceID) Stored position, detection method, strength, speed and observation times. A track can also link to the actual ship, population or missile salvo.
Remembered hull The observing race’s hull records (FCT_AlienShip) The last system (LastSysID), LastX, LastY, LastContactTime and Speed are copied at each observation. The link to the actual ship is separate and live.
Observed class FCT_AlienClass Updated from qualifying tracks, weapon observations and full revelation. The link to the actual class (ActualClassID) is internal bookkeeping, not permission to display that class’s data.
Colony intelligence FCT_AlienPopulation A link to the actual population sits beside remembered amounts and facilities, current and maximum intelligence points and the time of the last intelligence update.
Diplomatic and translation relation FCT_AlienRace, one record for each viewing race (ViewRaceID) and subject race (AlienRaceID) Policy, communication and intelligence state in one direction. The reciprocal record is independent.

Joining an observer record to its actual ship, class or population can expose the hidden present-day truth. Treating every value on an observer record as a fixed historical copy is also wrong. A track keeps a live link to its subject. A hull record keeps a live link to its ship beside the copied position, time and speed. Colony intelligence copies fresh values from the actual population each time it gains points, for every tier its points exceed. The origin of each value has to be judged at the display or step that uses it.

Physical existence and race discovery

Section titled “Physical existence and race discovery”

Generating a system and creating a race’s knowledge of it are separate steps at setup. When a habitable system is requested, the game removes each generated system that fails the habitable test of setup overrides and generates another. Once a system is accepted, the game creates the race’s jump point rows for it, all with Charted 0 and Explored 0, and then the race’s system record. A setup without a race still generates the physical system but creates no system record.

During first transit, exploration first reuses an existing physical link, or selects or generates a destination. It then sets up the endpoints and the race’s knowledge. An earlier visit by another race can therefore supply a physical destination that already exists, without making it known to the current explorer.

Discovery condition Knowledge change
Destination unknown to this race Create the jump point rows of the destination and the race’s system record. Mark the arrival point Charted 1 and Explored 1, and the departure point Explored 1. A fleet transit into a new system earns the Star Systems Discovered measurement and a ship history entry. It also earns the Habitable World Discovered measurement and a ship history entry when at least one body of the system has an atmosphere and a current colony cost of 0 for the race’s main species.
Destination already known to this race Reveal the new connection using the existing system knowledge. Skip the new-system awards.
Chart a local jump point by gravitational work Set Charted. This does not set Explored or discover the destination.
Detect a ship transiting an uncharted jump point The transit detection sets Charted to 1 directly and logs a Jump Point Detected event (event names are rows of DIM_EventType) (“New jump point detected in” the system “due to ship transit”). This is another route to position knowledge.

Physical movement and information gain keep separate records. A jump transit runs the departure checks, the exploration when the order has no destination yet, the move and the arrival state, and then the arrival checks. The time recorded when the transit explores a point does not date every later arrival or observation in that system.

Survey knowledge and shared physical changes

Section titled “Survey knowledge and shared physical changes”

Orbital geological completion creates the race and body pair and reports the deposits that already exist. It does not generate those deposits. Membership of a body without minerals is still valid knowledge. Ordinary system discovery does not run a full geological survey.

Because the pair grants access rather than holding a copy of the inventory, a race that surveyed a body sees later depleted or improved deposits. Ground survey completion runs mineral generation for the surveying race and marks the shared body’s ground survey status Completed (GroundMineralSurvey 0 in FCT_SystemBody). An existing deposit takes the generated amount and the generated accessibility only when each is higher. This can improve the current deposits without a new orbital membership or a treaty event for each observer that already surveyed the body. It is a shared physical change, not continuous sensor observation. The mineral report of a surveyed race reads the current deposits each time it is shown, and a race without membership sees “No Survey”.

Completion summary Actual meaning and limit
GeoSurveyDefaultDone Working flag of the automatic geological target search. SV: Body, SV: Five System Bodies and SV: Thirty System Bodies set it when no eligible body remains or the nearest one lies at or beyond the distance limit (10,000,000,000 km by default). The remaining bodies can be queued, banned, fixed or beyond the limit. A system with no bodies starts with it set.
Geological membership complete The race has a body survey row for every physical body in the system. A system with no bodies counts as complete.
Displayed surveyed percentage The race’s surveyed body count divided by the body count, times 100, rounded, and an exact half goes to the even neighbour. A system with no bodies shows 100%.
SurveyDone Gravitational completion. It is set when exactly 30 survey locations record the race, and also set directly when a whole-system gravitational survey is granted, for example by a random intelligence reward or at game setup. It does not prove that every jump connection has been explored.
Charted and explored jump point lists of the galactic map Display lists rebuilt from the race’s own jump point rows when the map is prepared.

These states can legitimately disagree. A finished target search flag does not prove an exhaustive geological survey, and a count on the map is not the authoritative set of jump point rows. Exploration surveys and discovery owns the survey rules.

Detection and observation updates

Section titled “Detection and observation updates”

Sensor resolution comes later in the pipeline. Each sensor check clears and rebuilds the sensor source lists and chooses the targets for the eligible systems of that pass. A system is eligible when it is not flagged for no sensor checks (NoSensorChecks 0 in FCT_System) and more than one race has a presence there. Ordinary sources come from current undamaged equipment and the state of each source. Docked parasites are left out. The transit pass checks only the transiting fleet, largest ships first, in the system being left or entered when another race has a fleet, colony or missile salvo there. The pass for new missile launches checks only the salvos launched at the current time. Knowing a system does not make every foreign unit in it detectable. Detection cadence, gates and transponders gives the full rules.

For a ship, the game looks for an existing track by observer, actual ship and detection method. A search sensor emission track also has to match the emitting sensor’s strength x resolution and its resolution, so one hull can have several emission tracks. The detection methods are ContactMethod 1 active, 2 thermal, 3 search sensor emission, 4 shield or population EM, 5 transponder and 6 impact or explosion. UniqueID is the ID of the track and ContactID is the ID of its subject. A thermal track and an active track of the same ship can have different ages and strengths.

A successful update copies the ship’s fleet position, current speed and system into the track and sets LastUpdate to the current time. Continuity grows only when the old LastUpdate equals the current time minus the sub-pulse length (SubPulseLength in FCT_Game). ContinualContactTime then grows by the sub-pulse length. Otherwise it resets to 0 and Reestablished is set to the current time. The track keeps what the update wrote. It does not follow later movement on its own.

The same update also refreshes the observer’s knowledge of the ship. It makes sure the alien race, class and hull records exist and refreshes the hull observation. The hull record copies the last system, LastX, LastY, the fleet speed and LastContactTime. Its link to the actual ship does not make these copied values follow later fleet movement. Linking a track to class and hull knowledge covers the records it creates.

One ordering detail matters when reading observed capabilities. On an existing track, the observer’s hull and class knowledge is updated before the track’s new strength is stored. The class update can therefore use the previous strength of that track in this update. The hull location copy reads the actual ship directly, so its origin differs from the class input.

Movement processing runs the sensor checks after each sub-pulse of work. End-of-increment repairs, recharge and strategic processing have their own later order. A physical change or a redraw does not rewrite earlier observations. Snapshots caches and UI actions covers those boundaries.

Times identities and freshness

Section titled “Times identities and freshness”
Value Unit and meaning
Game time (GameTime in FCT_Game) Simulation seconds with decimals. Not UTC and not the computer clock.
DiscoveredTime in FCT_RaceSysSurvey When this race’s system record was created, including by import.
Discovered in FCT_RaceSysSurvey Calendar date text captured when the record was created. Separate from the numeric time.
CreationTime in FCT_Contacts The first creation of this track, not the construction of the ship.
Reestablished in FCT_Contacts The latest update of this track that broke continuity. When it is 0, the track’s established time is its CreationTime.
LastUpdate in FCT_Contacts The latest observation update of this track.
ContinualContactTime in FCT_Contacts Seconds accumulated under the exact preceding sub-pulse rule. Not the current time minus CreationTime.
FirstDetected and LastContactTime in FCT_AlienShip Hull discovery time and the latest hull observation copy, independent of when any one track was created.
FirstDetected and CommEstablished in FCT_AlienRace Creation of the relationship and the time the language was established. A first contact created with full intelligence sets Communication Established without writing CommEstablished, unlike natural translation.
Last colony intelligence update The time the colony intelligence last gained points. Held only while the game runs. FCT_AlienPopulation has no column for it.
System age (Age in FCT_System) Stellar age on the generation scale, in billions of years. Do not subtract it from contact times in simulation seconds.
Ship construction date (Constructed in FCT_Ship) The game time at which the physical ship was created. It does not identify a track or guarantee a fixed identity across a restore.

A fixed game year is 31,536,000 seconds. The calendar date is 1 January of the start year (StartYear in FCT_Game) plus the game time in seconds, held at no more than 1000 years. A date shown without the time of day hides it, so two equal displayed dates need not mean equal observation times.

“Last seen” should therefore name the value and the display that uses it. No single timestamp in the lifecycle means discovery, last sensor update, hull observation, language establishment and physical creation at once.

Sharing imports translation and intelligence

Section titled “Sharing imports translation and intelligence”
Route What moves or changes Conditions and exclusions
Geological treaty completion sharing The recipient’s body survey membership, not copies of the deposits The recipient already knows the system and has no row for the body. The grantor’s own record of the recipient has GeoTreaty set.
Gravitational treaty completion sharing The recipient’s location membership, charting from that location and a check for full survey completion The recipient already knows the system and has not surveyed the location. The newly charted connection is not explored.
System import from another race A new system record with the source race’s name for the system, plus conditional jump point knowledge An existing system record of the recipient comes back unchanged. No blanket import of geological or location knowledge.
Jump point rows created by an import The source race’s Charted value, or 0 when the source has no row. Explored 1 only when the source row is explored and the linked far point already has a row for the importing race, and that far row is then marked explored too. The physical link and the importing race’s rows for the far endpoints decide the result.
Natural successful translation Both communication records become Communication Established. Both CommEstablished times are set to the current time, the race names and portraits are revealed, and each record that is not fixed gains 10 diplomatic points. Translation is not a sensor scan and not a full class revelation.
ELINT and colony analysis Points, and intelligence controlled by thresholds Eligible sources, time, communication modifiers and revelation gates stay separate.
Random intelligence reward Selected knowledge such as technology, survey or class data Each reward has its own eligibility. There is no universal “reveal the empire” operation.

The Share Geological Data and Share Gravitational Data checkboxes of the Intelligence and Foreign Relations window set the grant on the selected record (GeoTreaty or GravTreaty in FCT_AlienRace). They do not backfill earlier discoveries. Direction matters. Race A’s record about race B decides A’s outgoing survey grants to B. The reciprocal policy is another record. The ordinary orbital fleet completion makes the geological sharing call. Ground survey completion and geological probe completion make no such call in play. Treaties policy and shared information covers how the grants are earned and revoked, and communication attempts and translation covers the translation rolls.

Importing a system at time 5000 gives the recipient a DiscoveredTime of 5000, even when the source race discovered it at 1000. The recipient’s record takes the source race’s name for the system and the time of the import. It does not copy the source’s acquisition time. This records when the knowledge was received. It does not claim that the physical system was generated then.

Displayed locations and retained evidence

Section titled “Displayed locations and retained evidence”

A track is current when its LastUpdate equals the current game time. Lookups filtered by age instead accept a LastUpdate at or after the current time minus the allowed age. A record found this way can be stale and still shown on purpose. The purge removes only tracks whose LastUpdate is earlier than the current time minus one game year (31,536,000 seconds), so a track exactly one year old survives. The Lost Contacts age settings of the contact tree are listed under contacts and remembered intelligence.

A ship’s contact label combines its qualifying tracks within the age limit. When all are current the state is Current, a mix of current and stale tracks gives Partial, and stale tracks alone give Lost. With no counted track the state defaults to Current, and that default does not prove a detection. The speed at the end of the label is the ship’s actual current speed, not the speed stored on a historical track.

A contact’s location text starts from the stored track coordinates. It compares them with the current positions of the observer’s populations, its charted jump points, the survey locations and the bodies, and uses the names the observer knows. A match needs a difference of less than 1 km in X and in Y. It gives “Orbiting” and the population or body name, “Stationed at” and the jump point, or “Stationed at Survey Location #” and the location number. Otherwise the text gives a position relative to the system. A label built later need not be the text or the orbital arrangement at the time of the observation. The survey lists of the map are likewise rebuilt display lists.

The hull list on the Known Class tab of the Intelligence and Foreign Relations window checks Destroyed and Salvaged first. It then shows Current Contact when LastContactTime equals the current time, or else the date of the last contact. It is a view of remembered hulls, not a census of every actual enemy ship. Displayed state gives the wider display matrix.

Current colony intelligence can decay while the historical maximum and the remembered facility counts stay. The decay picks only records with positive current points (AlienPopulationIntelligencePoints) whose last intelligence update is earlier than the current time. Once per increment it sets the current points to the old points x (1 - 0.25 x elapsed seconds / 31,536,000). It does not refresh the stored facilities from the actual installations. A refresh from the actual population copies the population and the count of installations costing more than 6 while the current points exceed 100, factories, mines, spaceport and cargo shuttle station above 200, refineries, maintenance facilities, refuelling station and ordnance transfer station above 300, and research facilities, ground force construction complexes, naval headquarters and sector command above 500. A high historical tier and low current points are compatible. Colony and race intelligence owns those tiers.

Removal persistence and reload

Section titled “Removal persistence and reload”
Transition Consequence
A track ages beyond one year The purge removes the track only. It does not remove known hulls or known classes.
Ship removal Removing a ship deletes its tracking contacts and adjusts related orders and targets. Losing sensor contact alone does not.
Ship transfer to another race The transfer deletes the ship’s tracking contacts and every race’s known-hull record of that ship before it completes. Retention is not unconditional.
Saving contacts The game deletes and rewrites this game’s rows in FCT_Contacts, with the copied times and coordinates, the IDs and the notification flag (Msg).
Loading contacts Needs the system (SystemID) and both races (ContactRaceID, DetectRaceID). Links the live subject by ContactType and ContactID when it exists, then restores the copied values.
Loading hull intelligence Needs the viewing race (ViewRaceID), its class record (AlienClassID) and the alien race (AlienRaceID). Restores the copied history and links the ship by ShipID when it exists.
Loading a game Rebuilds the data and the links between records. It does not run the time increment or the sensor checks.

Loading does not reject a track only because its target ship, population or salvo is missing. The track is added with no link to a subject. A missing system or race instead skips the row. A saved game can therefore keep the numbers of an observation without a live subject. A display or step that needs one has to be judged on its own. This is a property of loading, not evidence that ordinary saves contain orphaned tracks.

Hull loading likewise keeps a hull record when no ship with its ShipID exists, and leaves it without a ship link. The class record and the races have different checks. Surviving in a saved game and leading to a live object are separate questions.

ID namespaces also matter. UniqueID in FCT_Contacts is the key of the track. ContactID is the subject’s ID and means a ship, population or salvo according to ContactType. ShipID identifies a physical hull. The observing race (DetectRaceID or ViewRaceID) qualifies each intelligence record, and known hulls are kept by ShipID within each viewing race. An export by ID alone, without the type, the game or snapshot and the observing race, can join these records wrongly.

Object identity and reload explains why ship IDs can recur after the highest rows are deleted and the game is loaded again, or after an older database is restored. Each new ID is the highest ID so far plus 1. When a game is loaded, each counter starts from the highest ID in the surviving rows of its table, such as ShipID in FCT_Ship or UniqueID in FCT_Contacts. That maximum is read over the whole table, across every game in the database, not from a permanent record of every ID ever issued. Observation times do not tell which restored copy a record came from.

Worked lifecycle

Section titled “Worked lifecycle”

The following timeline is a constructed example, not recorded play. A and B are observers, C owns the foreign hull H, and every local eligibility and range check named here passes. Times are simulation seconds, and the rows are changes of state, not measured gameplay.

Time Action Result and remaining uncertainty
1000 A transits into physical system S, which another race generated and linked earlier. A gains its own record of S and explored knowledge of the arrival and departure points. This does not date the physical creation of S or survey its bodies.
1100 A completes orbital geological work on body P. B already knows S, and A grants geological sharing to B. A and B gain access membership to the same deposits. B does not receive a separate frozen mineral inventory.
1200 A completes a gravitational location that charts jump point J. A gains the location membership and Charted J. Explored J stays unchanged. B receives the location and the charting only when the separate gravitational sharing conditions pass.
1300 A detects H by active and thermal sensors. Two tracks can be current, with different UniqueID values. The hull’s LastContactTime and location refresh to 1300. A need not understand the language of C.
1360 The next ordinary check, with a 60-second sub-pulse, detects H by thermal only. The thermal LastUpdate becomes 1360 and its continuity can grow. The active track stays at 1300. An age window that admits both shows mixed freshness. The hull observation of H is current at 1360.
1420 H moves out of A’s detection, and neither track updates. The copies keep their earlier positions and times while the actual H, and the live link to it, can move. Knowledge of its class and race stays.
1500 Translation succeeds under its own mission and roll rules. The communication state and names change. Translation does not rewrite either historical track as a sensor detection at 1500.
1600 In an alternative continuation where B did not yet know S, B imports S into a new record. B’s acquisition time is 1600. The source naming and conditional jump point knowledge are imported. Geological and gravitational membership is not copied wholesale.
2000 A saves and reloads with the stale H observations while H still exists. New links to the live objects are made and the copied times survive. Loading alone does not set LastUpdate or LastContactTime to 2000.
1360 + 31,536,000 The purge runs with the thermal track exactly one year old. The thermal track survives the strict “older than” test. The older active track can already have expired.
Later than that boundary The purge runs again with no detection. The thermal track can expire too. This purge does not remove the separate hull and class knowledge.

For a shared-deposit continuation, suppose P starts with 1000 mineral units, and A and B have both surveyed it. Mining lowers the physical amount to 900, so both races that hold membership see 900 without a new geological completion. A later ground survey result can replace the current amount with a higher generated amount. It does not add that amount, and it does not refresh the original depletion baseline (HalfOriginalAmount in FCT_MineralDeposit). Ground surveys gives the formula, and mining and mineral availability covers the depletion.

For a reload edge, suppose a database copy built by hand holds a track whose ship ContactID matches no ship row, while its system and races exist. Loading restores its position and times with no ship link. If the copy instead holds a ship with that same numeric ID, loading binds the track to that ship without checking any outside identity of the continuation. Ordinary ship removal deletes the ship’s tracking contacts. The example shows how loading resolves links and where externally combined or restored state reaches its limits. It does not describe a normal way to get a dangling track.

Separately, restore a consistent older snapshot from before H was created, then create a different hull that receives the ID H had in the discarded continuation. An outside history kept only by ID can now seem to match the new hull, although the restored game never contained the discarded H. Keep the provenance of each snapshot outside the game when comparing continuations. The object counters and the observation dates do not establish a permanent identity.

Limits

Section titled “Limits”

This page does not promise a complete boundary around what a race may know. Some displays and steps use the actual objects on purpose. Not every retained record survives every capture, deletion, import or window action. The copy, live and cached behaviour described here applies to the steps this page names. Database edits from outside the game and combinations of saved copies are illustrative edges of loading, not supported ways to play.

This page does not catalogue the omniscience of special race AI, every override of body names, every combat step that records observations or every window refresh. The companion pages own those systems.

Concept map

Section titled “Concept map”

Resources

Section titled “Resources”

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