How to read the data

Section titled “How to read the data”

The game database as shipped holds eight rows in DIM_PopPoliticalStatus. An edited database can hold different values, and the game uses whatever the database holds. The table reproduces every column and every stored value. NextStatusID is the status a population moves to next. SPRequired is the progress threshold for that move. The other numeric columns are decimal multipliers that the game reads as stored, without conversion.

StatusID StatusName NextStatusID SPRequired ProductionMod WealthMod OccupationForceMod ProtectionRequired ServiceSector
1 Imperial Population 0 0 1 1 0 1 1
2 Conquered 3 100 0.2 0.2 1 0 0.1
3 Occupied 4 250 0.4 0.4 0.75 0 0.25
4 Subjugated 7 600 0.6 0.6 0.25 0.5 0.4
5 Slave Colony 0 0 0.7 0.1 1.5 0 0
6 Client State 1 1800 0.8 0.8 0 2 0.75
7 Candidate Population 1 1200 0.8 0.8 0 1 0.75
8 Vanquished 4 300 0.2 0.2 0 1 0.1

The game’s rules refer to statuses 1 to 7 individually. ID 8 (Vanquished) exists only as a database row, and no game rule ever assigns it. When a game is loaded, every row becomes a status in the running game, including ID 8.

No population reaches Vanquished in play with the game database as shipped. Every rule that sets a population’s political status uses one of statuses 1 to 7, restores a saved ID, or follows a NextStatusID link. No rule assigns ID 8, and no row has NextStatusID 8. No window offers a control that lists or selects a political status, and Spacemaster mode has none either. The Economics window transfer button always hands a population over as Imperial Population. The Vanquished link to Subjugated is therefore dormant. A population holds Vanquished only after a database edit writes ID 8 into FCT_Population.PoliticalStatus or into another row’s NextStatusID. Status reachability in play lists every rule that sets a status. The order of the IDs says nothing about the order of transitions.

When a game is loaded, the game reads SPRequired, NextStatusID, all five coefficient columns and StatusName from each row. It then links each status to its next status only when a row with that NextStatusID exists. A target of 0 normally has no linked status because the table has no status 0.

Section titled “Directed progression links”

These are the links stored in the NextStatusID column. They are not a presumed social hierarchy.

From Link Meaning with the game database as shipped
Conquered (2) to Occupied (3) Progress threshold 100
Occupied (3) to Subjugated (4) Progress threshold 250
Subjugated (4) to Candidate Population (7) Progress threshold 600
Candidate Population (7) to Imperial Population (1) Progress threshold 1200
Client State (6) to Imperial Population (1) Progress threshold 1800
Vanquished (8) to Subjugated (4) Progress threshold 300
Imperial Population (1) to ID 0 (no row in the table) Imperial progress is switched off
Slave Colony (5) to ID 0 (no row in the table) Threshold is zero. See the special case below

Runtime progression rules

Section titled “Runtime progression rules”

The political progress step runs once per construction cycle for each population, right after the unrest and stability update. It adds status points only when unrest is exactly 0 and the current status is not Imperial Population. It does not require a positive population, and it does not check that a next status exists before it adds points.

The daily rate is 1.5 - whole-number((determination + militancy + xenophobia) / 300). Combined values from 0 to 299 produce 1.5 points per day. Values from 300 to 599 produce 0.5. Values from 600 to 899 produce -0.5. The three species traits therefore change the rate in steps, not continuously. For example, values 100/50/50 sum to 200, so the rate is 1.5, not 0.8333.

When the body’s radiation level is strictly greater than 100, the rate is divided by radiation level / 100. At 100 radiation there is no divisor. At 200 the rate is halved. The elapsed time in seconds is divided by 86400 and multiplied by the resulting rate, and the result is added to the stored points. Progress can go negative when the species sum reaches 600 or more. The game does not stop it at zero.

A status change requires stored points strictly greater than SPRequired, and NoStatusChange equal to 0 in the population’s FCT_Population row. Equal points do not cause a change. On a change the game resets the points to zero and gives the population the linked next status. It makes at most one change per cycle and discards any excess points. It then logs an event that gives the population name, then “has moved to a political status of”, then the new status name. The event type is 115, Pop Status Change, in DIM_EventType. NoStatusChange blocks the change but not the accumulation.

For example, a Conquered population at exactly 100 points remains Conquered. At 100.01 points, with zero unrest and NoStatusChange 0, it advances to Occupied and its points reset. A long time increment still advances only one link.

A Slave Colony has threshold 0 and target 0. If a population held it and gained a positive amount of points, it would pass the strict threshold and receive the missing next status, so it would be left with no political status at all. The event message that follows reads the new status name and fails. The game reports error code 2087 (shown as Function #2087) and the political progress step ends there, leaving the population with no political status. Every later cycle with unrest exactly 0 fails again when the update checks the current status. The production, protection, wealth and save steps that read the status also fail.

This zero target is dormant data. No game rule assigns Slave Colony and no row links to ID 5, so a population reaches it only after a database edit, as status reachability in play shows. The zero target is not evidence of an intended destination.

Imperial Population never accumulates points, whatever its SPRequired or next ID. Other statuses accrue only at exactly zero unrest. Even a small positive unrest value pauses accrual. The update does not reject a negative elapsed time. Cycles in which NoStatusChange is nonzero still add progress, which can leave the points above the threshold until a later eligible cycle.

Meaning and use of coefficient fields

Section titled “Meaning and use of coefficient fields”

The stored values are plain decimal multipliers, not percentages. OccupationForceMod is a direct factor in the required occupation strength. Required occupation strength = resistance factor per million x population in millions x OccupationForceMod. The resistance factor per million is (determination + militancy + xenophobia) / 300, without dropping the fraction. For a 10-million population with resistance factor 1, Conquered’s value 1 means 10 strength required. Occupied’s 0.75 means 7.5. A stored zero means zero required occupation. A stored one keeps the baseline species-resistance requirement. The population summary shows “Occupation Required / Actual” for every population that is not Imperial Population. Occupation-shortfall unrest applies only when the required strength is greater than 0 and greater than the actual occupation strength. Zero occupation demand does not switch off other sources of unrest.

ProtectionRequired is also a direct multiplier. Protection required = population in millions x (militancy / 100) x ProtectionRequired. The resulting demand is in HS of qualifying weapons. For 20 million population, militancy 50 and coefficient 0.5, the requirement is 5 HS. Coefficient 1 gives the baseline 10 HS, while zero gives no positive demand. Protection counts undamaged qualifying weapons on noncommercial ships, excluding CIWS and decoy launchers. Each undamaged weapon adds its size in HS. A commercial ship adds nothing. The total sums every ship of every non-civilian fleet of the same race in the population’s system.

Protection-shortfall unrest applies only to populations strictly above 10 million that are neither capitals nor NPR colonies. The population summary refresh applies the same three conditions. A calculated requirement is therefore distinct from whether its shortfall causes unrest. See the occupation, protection, unrest and stability rules.

ProductionMod and WealthMod are factors in the production and wealth calculations. Research lab output, for example, is the number of research labs times the economic production modifier times manufacturing efficiency times the radiation production modifier times stability times ProductionMod. The wealth modifier is WealthMod times the race’s wealth creation rate times the radiation production modifier. The colony governor’s wealth creation bonus then multiplies it, the sector governor’s wealth creation bonus multiplies it at a quarter of its strength above 1, and stability multiplies it when unrest is above 0. A stored 1 is neutral in these formulas. A stored 0 suppresses the affected amount, while 0.2 multiplies it by one fifth. The population summary multiplies each value by 100 and shows it as a percent with up to two decimals, under “Political Status Production Modifier” and “Political Status Wealth Modifier”. A value of 0.2 is shown as 20%.

ServiceSector is read when a game is loaded and then never used. The workforce calculation derives the agriculture, service and manufacturing shares from population and environment and does not use the status service value. The service values in this table therefore have no effect in play. They are distinct from the calculated service workforce fraction.

Assignment, occupation, and save/load boundaries

Section titled “Assignment, occupation, and save/load boundaries”

Ground-combat surrender hands the population to the winner through the shared control transfer, with the resulting status Conquered (ID 2). The surrender test runs first. The surrender requirement is (determination + militancy + xenophobia) / 300 x population in millions, and the population surrenders when the occupying side’s occupation strength is at least that value. The shared transfer assigns the requested status only when the new owner differs from the population’s recorded original race and the population is nonzero. A return to the original race, or the transfer of an empty colony, assigns Imperial Population. Either way the transfer resets status points and unrest to zero. At the end it overwrites the recorded original race with the outgoing current owner, then assigns the new owner. The recorded original race, stored as FCT_Population.OriginalRaceID, is therefore not a fixed founding-race history. See population control transfer.

Independence uses the same transfer with Imperial Population as the requested status. A newly created population starts as Imperial Population. When a game is loaded, each population’s saved status ID is looked up among the statuses loaded from the current DIM_PopPoliticalStatus.

Ongoing occupation uses the status occupation factor and separately computes net police and annual unrest reduction. The initial surrender and ongoing occupation are distinct checks. The protection factor sets the required fleet protection. Of the five coefficients, only ServiceSector has no effect. The game saves each population’s status ID in FCT_Population.PoliticalStatus and its progress in FCT_Population.StatusPoints. It rewrites the FCT_Population rows of the game on every save. Loading rebuilds the statuses and their next links from the current DIM_PopPoliticalStatus, so a changed database can change the rebuilt graph. See saved state and reload.

Status reachability in play

Section titled “Status reachability in play”

Five game rules set a population’s political status. A population has no default status. When a game is loaded and the saved ID has no row in DIM_PopPoliticalStatus, the population is left with no political status at all.

Rule Status assigned Condition
Loading a saved game The saved FCT_Population.PoliticalStatus ID The loaded statuses contain the ID
Political progress step The current status’s linked next status The progress gate passes
Control transfer to another race The requested status The new owner is not the recorded original race and the population is nonzero
Control transfer to another race Imperial Population Any other transfer
Creating a population Imperial Population A new population is created

Four game actions request a status from the control transfer. Two of them request Imperial Population, so only ground surrender and sovereignty diplomacy can produce a non-Imperial status by transfer.

Action Requested status Trigger
Ground-combat surrender, during ground combat resolution Conquered Occupation strength meets the surrender requirement of species sum / 300 x population in millions
Transfer of an NPR’s populations in a system to the occupying race, from either of the two acceptance outcomes of NPR territorial sovereignty diplomacy Occupied An NPR accepts another race’s sovereignty claim on one of its systems
Grant of independence, from the Economics window independence button Imperial Population The player grants independence
Economics window transfer button Imperial Population The player transfers the population

When an NPR accepts a sovereignty claim, each of its populations in that system with more than 0.01 million population or any installation transfers, and the game removes the rest. A transferred population with zero population receives Imperial Population instead of Occupied.

ID Status Reachable in play Route
1 Imperial Population Yes Direct assignment at creation, on independence, on transfer back to the original race or of an empty colony, and through the Economics transfer. Progression from Candidate Population
2 Conquered Yes Direct assignment through ground-combat surrender only
3 Occupied Yes Direct assignment through sovereignty diplomacy. Progression from Conquered
4 Subjugated Yes Progression from Occupied. The link from Vanquished is dormant
5 Slave Colony No No rule assigns it and no row has NextStatusID 5
6 Client State No No rule assigns it and no row has NextStatusID 6. Its link to Imperial Population is dormant
7 Candidate Population Yes Progression from Subjugated only
8 Vanquished No No rule assigns it, and no row has NextStatusID 8

“No” means unreachable without a database edit to FCT_Population.PoliticalStatus or to a DIM_PopPoliticalStatus link. Each progression route also requires the gate to pass. Unrest must be exactly zero, the species sum must stay under 600 for positive accrual, and NoStatusChange must be zero. Nothing in play changes NoStatusChange, so only a database edit changes it. The game reads it from FCT_Population when a game is loaded and writes the same value back on save.

With the game database as shipped, a population reaches five of the eight statuses in play. Imperial Population, Conquered and Occupied are assigned directly, and Subjugated and Candidate Population follow by progression. Slave Colony, Client State and Vanquished are unreachable without database edits, so their rows, their links and the Slave Colony zero target are dormant data. ServiceSector has no effect in play.

Concept map

Section titled “Concept map”

Resources

Section titled “Resources”

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