Northstar MCP 0.3.0: Geprüfte Lesefunktionen und begrenzte Freigabe

Northstar verwendet nach einem Pilotversuch am 15. September 2026 die Schnittstelle Northstar MCPMCP Model Context Protocol, ein offenes Protokoll, über das ein KI-Modell Werkzeuge aufruft und Daten aus anderer Software liest. 0.3.0. Der dokumentierte Testabschluss erfolgte um 06:49 Uhr UTC, was 08:49 Uhr in Berlin entspricht. Der Pilot bestätigte die Version für geprüfte Lesungen, die Kamera, die Spielgeschwindigkeit sowie das Speichern und erneute Laden. Für weitergehende schreibende Eingriffe durch den Bauagenten gelten gesonderte Prüfbedingungen.

Nachweis der aktiven Schnittstelle und Speicherprüfung

Vor dem Testlauf wurden die acht im Paketmanifest erfassten Dateien geprüft. Anschließend wurde die tatsächliche Installation nachgewiesen. Der aktive Client prüft zusätzlich die Build-Identität sowie die Versionsangabe in den Rückmeldungen. Die abschließende Antwort zum Spielzustand nennt die Version 0.3.0.

Dieser Schritt trennt frühere Fehler von nachfolgenden Softwareständen: Beobachtungen unter Version 0.2.1 beschreiben diesen älteren Stand und widerlegen keine später ausgelieferte Korrektur. Umgekehrt ersetzt eine Korrekturmeldung der Entwicklung keinen passenden Test im Spiel. Beide Nachweise bleiben zeitlich und sachlich getrennt.

Im Pilotversuch wurde ein zuvor angelegter Spielstand unter der neuen Version geladen. Danach wurde ein neuer Stand gespeichert, dessen Dateien geprüft und dieser Stand erneut geladen. Ein Versuch, denselben Namen ohne Überschreibfreigabe zu verwenden, wurde abgewiesen. Der anschließend geprüfte Spielstandshash blieb unverändert. Damit reicht der Nachweis über eine reine Auftragsbestätigung hinaus. Nach dem Laden musste das Tempo ausdrücklich wieder auf vierfache Geschwindigkeit gestellt werden. Der Abschluss bestätigt eine laufende Simulation, eine funktionierende Kamera sowie normale Geld- und Freischaltregeln bei ausgeschaltetem Fehler-Bypass. Ein durchgehend unveränderter Zustand über den gesamten Installationsvorgang wird nicht behauptet.

Differenzierte Zuordnung von Warnungsursachen

Im früheren Betrieb hatte eine als Müllproblem ausgewiesene Kapazitätswarnung zu einem Friedhof gehört. Eine plausible Bezeichnung reichte daher nicht aus, um den zutreffenden städtischen Dienst zu ermitteln. Für den Bauagenten ist diese Unterscheidung bedeutsam, weil eine falsch zugeordnete Warnung eine unpassende Baumaßnahme veranlassen kann.

Die Überprüfung umfasste acht Warnungsgruppen. Bei sieben Gruppen lag ein eindeutiger Ursachenkandidat vor. Für die gemeinsam genutzte Kapazitätswarnung lieferte die Schnittstelle zwei Kandidaten. Die Felder für die eindeutige Ursache und die Ursprungsquelle blieben dabei ausdrücklich unbekannt. Die gespeicherte Vertragsprüfung bestätigt dieses Verhalten für die untersuchten Gruppen.

Durch diese Rückmeldung erhält der Bauagent einen Anlass zur weiteren Prüfung am betroffenen Objekt, anstatt von einer unbegründet eindeutigen Zuordnung auszugehen. Eine vollständige Abnahme sämtlicher Warnungsarten bedeutet dieser Befund jedoch nicht. Der Fall ohne jeden Ursachenkandidaten trat im Live-Pilot nicht auf.

Konsistenzprüfung der Zonierungszellen

Unter Version 0.2.1 konnten rohe Zonierungszahlen dieselbe Fläche mehrfach erfassen, wenn sich interne Blöcke überlagerten. Die Entwicklung meldete entsprechende Korrekturen für Version 0.3.0 als ausgeliefert. Der Pilot untersuchte daraufhin eine bestehende Vergleichsfläche: Sowohl die Flächenzusammenfassung als auch die Zählung über einzelne Entitäten ergaben jeweils 102 sichtbare Zellen. Davon waren 72 als belegte Wohnzellen erfasst.

Diese Übereinstimmung liefert einen Konsistenzbefund. Die untersuchte Probe enthielt allerdings keine nachgewiesene überlappende Doppelzählung. Zudem wurde während der Prüfung kein neuer Zonierungs-Schreibauftrag mit anschließendem räumlichem Vergleich ausgeführt. Die ursprüngliche Fehlerbedingung ist im Spiel somit noch nicht vollständig nachgetestet.

Vor einem künftigen Einsatz dieses Werkzeugs verlangt das dokumentierte Verfahren einen frischen Spielstand, eine vollständige räumliche Vorprüfung und eine unabhängige Rücklesung. Frühere Zähler dürfen nicht ohne Prüfung als Vergleichsbasis für Zellzahlen der neuen Version herangezogen werden. Ein erfolgreicher Lesetest qualifiziert zudem keine Straßen-, Gebäude- oder Abrisswerkzeuge.

Neubewertung der Fahrzeugzähler

Ein Entwicklerabgleich vom 15. September 2026, der um 06:03 Uhr UTC abgeschlossen wurde, korrigierte eine bisherige Annahme: Die frühere Vermutung, der Wert fleet.used erfasse grundsätzlich etwas anderes als die fahrzeugbezogene Nutzeroberfläche, ist nicht belegt. Laut dem Abgleich mit dem Spielcode verweist der Wert auf denselben Fahrzeugzähler wie die Anzeige im Spiel.

Zeitversetzte Messungen mit unterschiedlichen Zahlenwerten beweisen daher keine inhaltliche Abweichung. Ein gleichzeitiger Livevergleich steht weiterhin aus. Dieser Befund stellt eine datierte Präzisierung der Einordnung dar und ändert die früheren Beobachtungen nicht nachträglich. Er bedeutet nicht, dass alle Fragen zur Flottenauslastung gelöst sind.

Stand und offene Prüfpunkte

Die Ergebnisse des Pilotversuchs und die verbleibenden Grenzen stellen sich für das Projekt CS2 wie folgt dar:

Die gemessenen Laufzeiten einzelner Abfragen werden nicht als Leistungssteigerung gewertet, da ein kontrollierter Vergleich fehlt. Zusätzliche Performance- und Exporterfassungen blieben während des Tests ausgeschaltet und wurden nicht aktiviert. Auch der Schutz vor einem absichtlich aktivierten Fehler-Bypass oder einem zeitkritischen Wechsel zwischen Auftragsannahme und Ausführung wurde nicht durch neue Gegenproben geprüft.

Der neue Stand bringt belegte Fortschritte bei bestimmten Lese- und Betriebsfunktionen. Stadtmanagement und Schnittstellenprüfung bleiben getrennte Aufgaben: Ob eine Maßnahme den Verkehrsfluss, die Versorgung oder das Wachstum verbessert, muss weiterhin anhand der tatsächlichen Wirkung im Spiel untersucht werden.