Identity namespaces and counter scope

Section titled “Identity namespaces and counter scope”

This page covers numeric identity, ID allocation, how a save and a load rebuild records, and the creation dates the game keeps for fleets, ships, populations (colonies) and commanders. An “older database” here means an earlier saved copy of the game state, not an older version of Aurora or of its database layout. Restoring such a copy can issue an ID again. A link that stores only the ID can then look intact while it finds an object from a different continuation of play. The rules on this page describe what the game writes and reads. They do not rely on any foreign key or uniqueness rule in the database.

The four object types use separate whole-number ID ranges. ShipID 51 and FleetID 51 can exist side by side, because each type has its own counter and its own list. The race is a property of the object, not part of the list key. All races in a loaded game draw from the same counters. Commander identity spans the active and the retired commanders, and retirement does not restart the numbering.

Object ID column Held in a loaded game ID counter starts from Saved counter column
Fleet FCT_Fleet.FleetID The game’s fleets, listed by FleetID The highest FCT_Fleet.FleetID None
Ship FCT_Ship.ShipID The game’s ships, listed by ShipID The highest FCT_Ship.ShipID None
Population (colony) FCT_Population.PopulationID The game’s populations, listed by PopulationID The highest FCT_Population.PopulationID None
Commander FCT_Commander.CommanderID The active commanders and the retired commanders, both listed by CommanderID The highest FCT_Commander.CommanderID None

Every one of these lists finds an object by its whole-number ID. The counters belong to the loaded game. Each new ID raises its counter, and loading a game sets each counter from the highest ID in its table. The game record that a save writes to FCT_Game holds the game time (GameTime) and the game settings. Neither FCT_Game nor FCT_Race has a column for these four counters, so a save does not store them in either table.

The highest-ID query covers the whole database, not just the selected game. The query reads the highest value of the ID column across the whole table, with no GameID or RaceID filter. An empty table gives 0. A failed query shows a Function #484 error and also gives 0. The starting counter is therefore the largest surviving row of that table across every game in the database the game has open. References to an ID, the ShipID stored on wrecks, history rows, deleted rows and IDs that were issued but never saved do not count.

Loading objects is different. It reads only the rows whose GameID matches the selected game. The loaded lists belong to that one loaded game, and their whole-number keys carry no game or race part. Ordinary creation within one loaded game rises across all races, while existing rows of other games in the same database can raise the starting maximum. This is not a permanent identity across database files, restored copies or games loaded separately. Two loaded games do not coordinate their counters. Commander persistence shows the same table-wide rule keeping other games’ commander traits apart.

The hull number (FCT_Ship.HullNumber) is a separate display number. Each race keeps a count per hull type. The first ship of a hull type gets hull number 1, and each later ship of that type gets the count plus one. Ship creation leaves a civilian ship of a shipping line at hull number 0 and gives every ship without a shipping line the next hull number. These counts are saved in FCT_HullNumber.HullCount with GameID, RaceID and HullTypeID and restored to the race when a game loads, unlike the four ID counters, which come from table maxima. The class count (FCT_ShipClass.TotalNumber) also drives generated names. When no name is given, the generated name is the class name, a space and the count padded to three digits (001, 012, 123). It rises by one for each new ship of the class and for each refit to the class. Neither display number nor generated name is the ShipID. Hull numbers and ship names cover the naming rules.

Allocation and new-game initialisation

Section titled “Allocation and new-game initialisation”

For each object type, a new ID raises that type’s counter by one and returns the new value. A counter at M gives M + 1. The ID step does not look for gaps, does not check whether the ID is already in use and does not look at creation time. The ID is drawn before the object is finally added, so a failure after the draw can use up a number without leaving a saved object. Issuing an ID has no collision or overflow check. An ID asked for a type that has no counter is 1, and a failure while issuing an ID shows a Function #1401 error and also gives 1. An abnormal draw therefore does not guarantee a fresh ID.

Creation Order of steps
Fleet creation Builds the fleet, draws its FleetID at once, sets its attributes, adds it to the game’s fleets and writes the creation history entry.
Ship creation Builds the ship, picks a fleet or creates one first, draws the ShipID, adds the ship to its fleet, sets the construction date and starting state and adds it to the game’s ships later. The fleet and ship counters stay independent.
Population creation Resolves the species, using the race’s primary species when none is given, and returns an existing population of that race and species on that body when one exists. Otherwise it computes the colony cost, builds the population, draws the PopulationID, sets empty quantities and starting state and adds it to the game’s populations.
Commander creation Builds the commander, draws the CommanderID before the random setup, sets the career and history and adds the commander to the end of the active commanders.

When ship creation is given no usable fleet, it first creates a new fleet named after the hull type abbreviation and the ship name, so that fleet draws its FleetID before the ship draws its ShipID. Fleet creation covers the fleet side. Commander creation sources lists every path that creates a commander.

A newly built game record starts with every counter and the game clock at 0. The Game Information window takes the new GameID from the counters of the game currently open, which start from the highest FCT_Game.GameID. It sets Starting Year (StartYear) to 2050 by default, then applies the chosen settings. Creating the new game loads the fixed game definitions before it generates systems and races, and that step sets every ID counter from the highest ID in its table. New-game numbering therefore starts above the highest IDs already in the database rather than at 1. Creating the game ends with a save. Game rule defaults lists the other settings.

A colony is a population record, not a planet ID. Population creation matches race, species and body, so several populations can share one body. A new population has surface population (Population), orbital population and total population 0, so an empty colony record can exist before any colonists arrive. The game records no first-settlement time there. Colony identity and founding covers the rest of a new colony’s state.

Saving, loading and reconstructing references

Section titled “Saving, loading and reconstructing references”

A save opens the game’s database, begins one transaction, makes the backup copies, runs every save step and commits. Each save step for these objects deletes the selected game’s old rows and inserts the objects currently in play. A save gives no new ID to an existing object. A removed object disappears from the rewritten table unless the save step still holds it or selects it.

The backup copies fixed file names in the game folder. It copies the existing AuroraDBSaveBackup.db to AuroraDBPreviousSaveBackup.db, then copies AuroraDB.db to AuroraDBSaveBackup.db. It does this whichever database file the game has open, so a backup does not prove that the open database was backed up. An error during a save step shows a function error and ends that step, and the save then goes on with the next step. A few steps, such as the ships step, also catch errors for each ship and for each of its tables. In the ships step an error stops the saving of every ship after it, so the step still ends there. One transaction therefore does not show that every object was written.

Loading a game restores the GameID, the Starting Year (StartYear) and the game clock (GameTime) from FCT_Game. It then loads the fixed game definitions, and that step sets the ID counters before any of these objects load. The counters come from database rows, not from the highest ID among the loaded objects. A row that is later skipped for a missing dependency still counts toward the starting maximum.

Loading builds fresh objects, gives each its saved whole-number ID and adds it to the game’s lists. Relationship IDs are saved as numbers. The links between objects, and the lists that point back from a target to the objects linked to it, are rebuilt by looking those numbers up. Links between objects are not saved as links, only as ID numbers. Loading does not run the creation of new objects, so a reload adds no creation history and does not replace construction dates with the load time.

The load order that matters here is populations, then naval admin commands, then fleets, then sub-fleets and fleet histories, then ships, then ship histories, shipyards and shipyard tasks, then ground formations, then commanders, then contacts, then move orders. Some links wait. Fleet anchors and the fleet destinations of populations resolve after all fleets load. Mothership and tractor links resolve after all ships load. Governors and officers connect to their posts, and the posts back to them, while commanders load.

Deletion, reload and restored-branch reuse

Section titled “Deletion, reload and restored-branch reuse”
Situation Consequence or condition
Delete an object and keep playing in the same loaded game Removal does not lower the counters. The next ID continues above the earlier counter.
Delete a low ID, then save and reload while a higher row survives in any game in that database The surviving higher row sets M, and the next ID stays M + 1. The low gap is not filled.
Delete the highest IDs, save and load again If no row as high or higher survives in that table in any game, the maximum falls and a high ID issued earlier can recur. History and reference rows do not reserve it.
Restore an older database and load from it IDs that existed only in the discarded continuation are absent. Future creation can issue those numbers again.
Restore one game’s state while other games’ higher rows remain Those rows can keep the maxima higher, so reuse depends on them and does not follow every restore.
Reload an object with its saved ID The game rebuilds the object as it was in that saved copy. Numeric continuity within one saved copy differs from continuity with an object created after it.

These results follow from counters that only rise, maxima taken over the whole table and saves that replace the game’s rows. Removing a fleet, ship or population clears specific links and orders. The game keeps no ledger of every ID ever issued. Persistence and reload boundaries applies this to destroyed and captured hulls, and ship removal order lists what removal clears.

Every active commander is saved, but retired commanders are saved only when marked RetainRetired or Prisoner. Retirement moves the same commander, with the same ID, from the active commanders to the retired commanders. A high retired CommanderID that is not saved stops counting toward the next maximum. Retained and prisoner retired rows still count. Commander persistence covers the rest of the commander save.

None of these four records carries a mark of which restored copy it came from. Restoring, on this page, means putting an older copy of the database in place and loading the game from it as normal.

Creation, build, establishment and birth dates

Section titled “Creation, build, establishment and birth dates”

Units and display

Section titled “Units and display”

The creation values below are simulation seconds on the game clock, stored as decimals, not real-world timestamps. FCT_Game.GameTime saves and restores the clock, and each sub-pulse adds the sub-pulse length (SubPulseLength) to it. A year in game rules is 31,536,000 seconds, a fixed 365 days. Displayed dates count the clock seconds forward from January 1 of the Starting Year (StartYear) on the ordinary calendar. Age and service calculations therefore use fixed 365-day years, while the displayed calendar can include leap years. Clocks and calendar display covers the clock in full.

The date-only display shows the long date without the time of day. The date display works from a less precise copy of the clock value, caps any time above 1,000 fixed years (31,536,000,000 seconds) at that limit, and falls back to January 1 of the Starting Year when the date cannot be computed. A failure in the date display shows a Function #1690 error and the text “error”. Displayed dates and history description text therefore differ in precision and behaviour from the raw numbers. Creation steps apply no rounding. Age and service years round the elapsed fixed years down.

Section titled “Complete creation-related inventory for these subjects”
Subject Value Setting, default and meaning Saved columns
Fleet No creation date of its own. The fleet history holds the game time of the creation entry. Fleet creation adds a history entry “Created on “ followed by the current date. Adding a fleet history entry sets its game time to the current game time. A fleet’s history list starts empty until that entry is added. It dates the fleet record, not the construction of its ships. FCT_FleetHistory.GameTime with FleetID, GameID and Description, attached by FleetID when a game loads. The FCT_Fleet row has no creation column.
Ship Construction date Defaults to 0. Ship creation sets it to the current game time in every construction mode. It marks the completed creation, not the start or the estimate of a shipyard task. A ship present at game start can have 0. FCT_Ship.Constructed, saved directly and read back as a decimal.
Ship Game time of the construction history entry Ship creation writes an entry at the current time, “Constructed at” followed by the shipyard name, or “Constructed” without a shipyard. It repeats the construction evidence and is not a separate identity. FCT_ShipHistory.GameTime with ShipID, GameID and Description.
Population (colony) No stored establishment, creation or birth date Population creation makes an empty record without a timestamp. The population does not date its first record or its first colonist arrival or growth separately. No establishment column is written or read.
Commander Career start Defaults to 0. Commander creation sets it to the current game time minus a d5 roll of fixed years (1 to 5 x 31,536,000 seconds). It is a simulated career or commission baseline, not the creation of the record or a birth. Starting personnel can have negative values. FCT_Commander.CareerStart, saved directly and read back as a decimal.
Commander Game times of the commander history entries Commander creation adds a generic entry “Promoted to” followed by the rank name at the current time when the commander has a rank. In that path it accompanies creation, but no dedicated created or born entry exists. Later promotions also add entries. FCT_CommanderHistory.GameTime with CommanderID, GameID and HistoryText.
Commander Birth date No value of its own. Age = floor((current game time - career start) / 31,536,000) + species graduation age (GraduationAge). No commander birth-date column. A birth date worked back from career and species is an inference, not a stored birth identity.

Fleet history entries, ship history entries and commander history entries list every entry these records can hold.

Fleet creation history survives only under conditions. When the game saves an NPR fleet, or any fleet with a shipping line, it keeps only the history entries strictly newer than the current game time minus 157,680,000 seconds (five years of 31,536,000 seconds). Entries exactly at the cutoff are removed. The pruning changes the fleet’s history in play as well as the saved rows. Ordinary player fleets without a shipping line are not pruned. No permanent fleet creation value is guaranteed. History persistence gives the save and load rules for every history table.

Career start can change. A promotion made with the time requirement waived moves the career start back by (2 + d5) x 31,536,000 seconds after each such promotion. New-race setup and independence setup create commanders and then run these waived-time promotions. The same CommanderID can therefore later carry a different career baseline. Academy graduation uses the same commander creation step, so new graduates also start with a backdating of one to five years. Promotion and demotion and recruitment and academy commandants cover those paths.

Other dates are not creation identity

Section titled “Other dates are not creation identity”
Subject Dates and timers Persistence and distinction
Fleet Last move time (LastMoveTime), last transit time (LastTransitTime) and last fleet damage time (LastFleetDamageTime), the last surrender decision time, the escape time remaining (EscapeTimeRemaining) The first three are saved and restored event timestamps. The last surrender decision time is not saved with the FCT_Fleet row. The escape time remaining is a duration. None dates the fleet’s creation.
Ship LastOverhaul, LastShoreLeave, LastLaunchTime, LastTransitTime, LastFiringTime, LastShipDamageTime, LastMissileHitTime, LastBeamHitTime, LastPenetratingDamageTime Separate FCT_Ship columns. Last overhaul and last shore leave start equal to the construction time, but later events change them. The combat and transit times date events.
Population Last bombardment, last missile bombardment and last beam bombardment times, the last colony cost (LastColonyCost) The bombardment timestamps are not written to FCT_Population. The last colony cost is an environmental cost, not a time.
Commander GameTimeAssigned, GameTimePromoted, service years The first two are saved separately. Both start as a copy of the career start, then assignments and promotions change them. Service years are derived, not a birth or creation date.
Shipyard task The completion estimate, in seconds remaining and as an expected completion time A work estimate or duration, not the construction start of the ship or a saved ship identity. Completing a construction task runs ship creation. A refit acts on an existing ship.

Transfers, refits, splits and merges

Section titled “Transfers, refits, splits and merges”
Operation Identity and date behaviour
Ship to another fleet The move transfers the same ship and changes its fleet. It gets no new ShipID or construction date.
Ship captured or transferred to another race The ship transfer changes the race, species, class and state of the same ship. A receiving fleet may be created with a new FleetID and its own history. The ship’s ID and construction date survive. Race, class and name are changeable descriptions.
Ship refit Completing a refit replaces the class, equipment and state of the existing ship without a new ShipID or construction date. The population adds the refit history entry “Refit to” followed by the new class name, “completed at” and the population name, and separately adjusts the last overhaul time.
Ship created next to a reference ship, or from a copied design or loadout Ship creation still draws a new ID and sets the current construction date. The reference ship supplies location, not an identity or a date. Copying a design or a combat loadout does not clone the ship record.
Fleet detached or split Detachment creates a fleet, then transfers existing ships to it. The new fleet has a new FleetID and history, and the ships keep their old ShipID values and dates.
Fleet absorbed Absorbing moves the ships to the receiving fleet, removes the absorbed fleet’s FleetID and leaves the receiving fleet as the result. It does not copy the absorbed fleet’s creation history. A link to a fleet does not follow its former ships.
Population control transferred The control transfer changes the existing population’s race, original race (OriginalRaceID), name, survey and political state and keeps its PopulationID. An empty population may change species to the new race’s primary species. There is no establishment date to reset.
Population quantities combined or converted Genetic conversion finds or creates the target population for that race, body and species, then adds and subtracts population. An existing target keeps its ID, or a new ID is drawn. No establishment date follows the quantities.
Commander reassigned, retired or generated under another commander’s influence Assignments change links and dates. Retirement keeps the identity across the active and retired commanders. A commander passed to commander creation influences the generated commander type and bonus rolls, and academy graduation passes the academy commandant. It copies no identity and sets no stored parent or birth relationship.

Relationship IDs and lookup behaviour

Section titled “Relationship IDs and lookup behaviour”

These are the relationship paths that matter for identity, not a full catalogue of the database. None of these links stores the target’s construction time next to the target ID.

Relationship Saved columns and reconstruction
Ship to fleet FCT_Ship.FleetID. Loading a ship requires its fleet to be loaded. Only then does the game set the ship’s fleet, add the ship to that fleet and add it to the game’s ships. A missing fleet means that row adds no ship.
Fleet to anchor fleet FCT_Fleet.AnchorFleetID. After all fleets load, a fleet with that ID becomes the anchor. Creation history is not compared.
Population to production fleets FCT_Population.FighterDestFleetID, SpaceStationDestFleetID and ParasiteSourceID. Population loading holds the numbers, and fleet loading resolves the positive IDs.
Population to mass-driver population FCT_Population.MassDriverDest. A later lookup by ID sets the mass-driver destination population.
Ship to mothership, assigned mothership and tractor links FCT_Ship.MothershipID, AssignedMSID, TractorTargetShipID and TractorParentShipID. Lookups by ID after all ships load.
Commander to command FCT_Commander.CommandType with CommandID picks a ship post, a colony post, a sector, a ground formation, a research project, a naval admin command or an academy. When that command is missing, the game sets the command type to none (CommandType 0). An existing ID is enough, with no date match.
Commander to location and transport FCT_Commander.PopLocationID, EducationColony, HomeworldID and TransportShipID use population, body and ship lookups. A missing optional target leaves that link empty.
Move order to owner, target and item FCT_MoveOrders.FleetID, DestinationType with DestinationID, PopulationID, and DestinationItemType with DestinationItemID. Loading requires the owner race, the fleet and the race’s survey of the start system, and a positive population, new system or new jump point ID must exist. Destination and item numbers are copied without checking every target at load time.
Contact to observed object FCT_Contacts.UniqueID identifies the observation. ContactID with ContactType identifies the observed object. Ship contacts look up the game’s ships, and population-related types look up populations. The observation time is not the object’s birth.
History to owner History attaches by the owner’s ID within the selected GameID. History does not reserve the ID when the counters are set.

Move order IDs are independent too. The move order counter starts from the highest FCT_MoveOrders.MoveOrderID and rises by one per new order. A fleet’s orders are listed by that ID, while the queue position is saved separately as MoveOrder. A DestinationID needs its DestinationType to have a meaning, and an item ID needs the item type and the action. Tractor and transfer orders can look up a ShipID through DestinationItemID while the enclosing destination is a FleetID. The tractor specified ship action (MoveActionID 159) finds its ship by DestinationItemID inside a fleet destination (DestinationType 10). A deep space population destination (DestinationType 15) stores a system body ID, as a system body destination (DestinationType 2) does, not a PopulationID. The population is a separate column. An order holds duration and delay state and no creation value. Movement persistence covers how orders resume after a reload.

A missing dependency can skip a row. A duplicate ID, or a required target ID that does not exist, can cause an error. The error shows a function error and ends that table’s load step, so the remaining rows of that table are not loaded (Function #3248 for a fleet row, #1202 for ships, #1301 for commanders and #1168 for move orders). A successful lookup by ID proves only that an object exists under that ID in the loaded game. The reconstruction described here does not compare construction time, creation history, former name or class, or former ownership. Ground formation reconstruction applies the same rules to parents and support targets.

Worked timelines and composite identity limits

Section titled “Worked timelines and composite identity limits”
Section titled “Older snapshot and falsely intact link”

The timeline is illustrative, with made-up numbers. It assumes no higher fleet or ship rows in other games and that every dependency of the creation steps is valid.

Step Counter state Result
Save S at simulation second 1,000 Saved fleet maximum 40, ship maximum 100 The saved copy has neither fleet 41 nor ship 101.
Branch A at second 2,000 creates ship A without a usable assigned fleet Fleet 40 to 41, ship 100 to 101 Ship creation creates the fleet first. A has ShipID 101, FleetID 41 and construction date 2,000. An outside record links to A by game, type and ID.
Restore S and load it Maxima recomputed as 40 and 100, clock restored to 1,000 A’s later IDs and objects are absent. The outside record lies outside S.
Branch B at second 3,000 creates a different ship B the same way Fleet 40 to 41, ship 100 to 101 B reuses both IDs, with construction date 3,000 and fleet creation history time 3,000.
Resolve the old link by looking up ship 101, or fleet 41 The ID exists The lookup finds B. The ID is present, so the link looks intact, although A belonged only to the discarded branch A.

The last rows model an outside record, such as an external tool, that keeps an Aurora ID across a restore and looks it up again. The game itself can reissue an ID and looks links up by number. That does not mean any particular tool silently relinks. The relationships restored together with S are S’s relationships. Branch A’s internal links do not remain inside S just because an outside record survived. Synthetic before-and-after timelines follows ship 101 in fleet 40 through death and capture.

Highest-ID deletion without older restore

Section titled “Highest-ID deletion without older restore”

If the highest ShipID is 101, removing that ship takes it out of the game’s ships, and the next save rewrites the game’s remaining rows. When the highest surviving FCT_Ship row anywhere in that database is 100, loading again sets the ship counter to 100 and the next new ship gets 101. If another game’s row 500 remains, the next is 501. A wreck, history row or reference that stores 101 does not change the highest FCT_Ship.ShipID.

Composite identity limits

Section titled “Composite identity limits”
Observation What it shows, and its limit
ShipID with the raw construction date Tells A at 2,000 from B at 3,000 above. The game does not use it as a key.
The same ID reissued at the same replayed simulation tick The exact construction time can recur. Restoring the clock and creating a different object at the same tick reproduces both parts. Several objects also share a time within one tick, so time does not identify the continuation.
FleetID with the game time of the creation history entry Can tell creation ticks apart while a recognisable creation entry exists. History pruning can remove it, and no dedicated permanent creation value exists.
PopulationID with an establishment time The second part does not exist. Body, race, species, name and first observation are descriptions, not a stored fixed establishment time.
CommanderID with the career start Can differ for generated people, but the random backdating can recur and waived-time promotions change the same person’s baseline. It is not a birth or creation time.
ID with the displayed date The date-only display loses the time of day and depends on the Starting Year, the calendar and the reduced precision of the displayed value. Different times can show the same date.
GameID with type and ID Supplies the range context, but both branches restored from S keep the same GameID. Separate database copies can hold the same GameID and IDs. The race can change during capture or a control transfer.
Matching evidence in a restored copy Supports continuity with that saved copy, not proof of continuity with a later branch it never contained.

Concept map

Section titled “Concept map”