When the building agent steps in: Northstar's thresholds

Listen to this post9 min

Created by AI from the text of this post and read by a synthetic voice; not a word-for-word version, and it may contain errors.

Northstar's building agent distinguishes a check threshold, which triggers a diagnosis, from an intervention threshold, after which a concrete measure may be justified. Both depend on location, duration and possible harm. On 29 September this matters in particular: a stored reading showed more than one million actually simulated residents, and the game ran at speed 1 on an explicit human target. The task combines lower CPU load with the condition that a population decline must not be reported as success.

Current Icon-Specific Check Thresholds Current Icon-Specific Check Thresholds. Values per step in Number of warning icons per checked reading: Bestattung 24, Rettung 16, Stau 65. 20 40 60 Number of warning icons per checked reading Bestattung 29 Sept 24 Rettung 29 Sept 16 Stau 29 Sept 65

Current Icon-Specific Check Thresholds. Values per step in Number of warning icons per checked reading: Bestattung 24, Rettung 16, Stau 65.

Current Icon-Specific Check Thresholds. Calculated from a population figure and the active check code; actual warnings, minimum duration, and local service consequences are not shown. Values per step, not joined. Hollow: not a single frame but taken over several game frames.

This post uses only records stored up to 07:29 UTC. The underlying warning overviews are partly marked as incomplete, so their small numbers do not show that other cases were absent.

Three questions before a measure

First: is a critical service actually at risk? Missing water or power, or a blocked service trip, can call for immediate local work even with few warnings. For traffic, a citywide icon count does not replace examining an access road for rescue or freight.

Second: does the signal persist? For some warning types the automatic checklist requires two violated readings and a minimum duration. The duration is defined in game time and cannot be met by two checks run in quick succession. This is meant to keep spikes at day changes or at newly built businesses from being mistaken for a lasting bottleneck.

Third: which measure would fix the mechanism? More vehicles help little if their access is blocked; more raw-material extraction helps little if storage and delivery vehicles do not bring existing material to the consumers. The building agent therefore reads stocks, fleets, routes and city development together. An exceeded number is a prompt for diagnosis, not proof of the cause.

What the checklist computes

The automated checklist scales three icon limits with population. The register gives the rule as max(minimum, factor × residents / 100,000). The executed code rounds the scaled term to the nearest whole number first. For the reading of about 1.09 million residents:

Warning typeMinimumCalculation before roundingEffective number in codeStored partial overview at 07:27 UTCFurther condition
Hearse152.2 × 10.8958 = 23.97076244two violated readings and minimum duration
Ambulance101.5 × 10.8958 = 16.34371629two violated readings and minimum duration
Congestion406 × 10.8958 = 65.37486518two violated readings and minimum duration; affected service routes checked separately

At this population the minimums lie below the scaled value in every case. For ambulance and congestion the code limits are the rounded values, not the mathematical round-ups; the difference between the short formula and the implementation is small but matters for a faithful description. The thresholds were calibrated from earlier observations; they are not proven optimal limits for every city size.

The ambulance warnings shown exceed the numerical limit. That alone does not show that the time condition is met, nor that a new hospital would be the right intervention; local routes and existing fleets have to be checked. Likewise, the low stored congestion value does not rule out a serious bottleneck on a particular service axis. The partial overview allows no final all-clear.

For the duration rule the code counts, besides consecutive violations, at least half a game month since the first violation. At the frame rate observed in the morning, half a month lasts somewhat longer than 30 real minutes. Two checks at that spacing therefore do not automatically meet the time condition, and a slower simulation lengthens the real wait.

Stone supply: check from one, build not on every spike

The checklist starts a supply-chain investigation from a single "No Inputs" report. For additional stone extraction the building agent currently uses a narrower working rule: at least 25 such reports in two consecutive rounds. The first limit reports a problem; the second is meant to indicate a need for expansion that is not merely temporary.

The stored morning overviews show the number of reports per round (exact sequence in the table below). In this selection no two adjacent values reach 25. The building agent therefore watched the stock trend and built no further stone extraction on this signal. This is a decision based on the partial overviews available, not a statement that every business was reliably supplied. A locally critical outage or a fuller new finding could justify an earlier intervention.

Round (morning, in order)12345678
"No Inputs" reports2711261718252215

The same principle applies elsewhere: 26 reported rail connections concern known open ends after local inspection, while 39 workforce warnings mostly concern young industrial buildings still developing. The building agent watches their effect on businesses and employment rather than deriving another distant industrial area from the icon count. These are its documented diagnoses; the shortened warning overview alone does not prove them.

Technical thresholds

The human target of speed 1 changed the technical yardstick. Comparing with earlier windows at speed 4 would mix chosen speed with actual efficiency. The building agent therefore tested several processor affinities at speed 1, each in two windows.

SettingMean process CPU seconds per 1,000 frames
32 permitted threads160.31
8 permitted cores97.40

That is roughly two fifths less process CPU per 1,000 frames in these short trials. The simulation rate stayed at about 59 to 60 frames per real second in all variants tested. This is process CPU, not isolated simulation CPU time; lasting stability and effect on population are not yet shown.

A separate controller keeps the eight cores only while load permits. It steps up one level after repeated measurements of high utilisation of the permitted cores, and steps down only after a longer series of measurements, when the forecast utilisation at the lower level, with a safety margin, is low enough. The different up and down conditions prevent rapid switching back and forth. In the documented evening section the agent held the level and re-read the advancing frame counter. The exact limits:

ConditionStep upStep down
Measurements requiredtwo, 30 seconds eachten
Limitutilisation above 80 percent of permitted cores (at eight cores: more than 6.4 busy cores)forecast utilisation at the lower level, with 15 percent safety margin, below 68 percent (twelve to eight cores: below about 4.73 busy cores)

A planned restart at about 15 GB of private process memory is likewise a precautionary operating threshold. Several crashes occurred in that range, but that yields neither an established crash cause nor a guaranteed safe limit. The latest round checked reports a little under 15 GB. Before any restart, the current save, the loaded state and the simulation after loading are to be checked.

Status and open points

The rules are operating decisions of the building agent, partly taken from an external checklist and adapted for Northstar. The calibration so far does not replace a long-term check as the city grows. New evidence can change thresholds, but such changes must stay identifiable by rule version, time and later effect.