feat(map): die Mitte wird ein Gebiet mit schmalen Zufahrten (21.7, #94, D-109) - #122
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Was
Paket 21.7 aus Sprint 21 (#94, Entscheidung D-109) — das letzte offene Paket des Sprints und sein teuerstes.
a) Die Mitte wird ein Gebiet. Aus dem einen Feld bei (62,62) mit 15.000 AE werden fünf Felder à 8.000 — zusammen 40.000 AE, also 28 % des Kartenwerts. Das ist exakt das Gewicht, das das Einzelfeld vorher hatte (29 %), nur teilbar: die Mitte bleibt der Preis, um den es sich zu kämpfen lohnt, ist aber nicht mehr ein einziger Klotz, den einer nimmt oder keiner. Die Karte trägt damit 15 Vorkommen mit 142.000 AE.
b) Chokepoints aus einer einzigen Quelle. Um die Zone liegt ein Felsring — Chebyshev-Radius 14–15 um die Mitte, 168 gesperrte Zellen — mit vier Ecköffnungen auf den Anmarschdiagonalen: den beiden Startbasen (SW/NE) und den beiden umkämpften Flanken (NW/SE). Jede Kehle ist vier Zellen breit, gemessen gegen den MS-1-Trupp aus sechs Einheiten bei 0,5 Zellen Radius: vier passen nebeneinander durch. Eine schmalere Öffnung wäre eine Blockade, kein Engpass.
Die Kernauflage aus D-109 ist erfüllt
Gameplay/Match/GlutrinneTerrainMaphält die kanonische Tabelle. Die Simulation bekommt sie überCostField.SetCostbeim Aufbau der Eröffnung (MatchBootstrap:745, mit harter Zellzahl-Sperre), dieGlutrinneBlockoutView:240baut exakt dieselben Zellen als Felsrücken, und die alte Deko-Felsstreuung hält über ein_wallProximity-Feld Abstand zum Ring. Zwei getrennte Quellen hätten Einheiten ergeben, die durch Felsen laufen und an unsichtbaren Wänden hängenbleiben — das Fehlerbild, das dieses Paket verhindern soll.Die Snapshot-Falle, und wie sie umgangen ist
CostFieldist kein Snapshot-Block. Seine Wiederherstellbarkeit war bisher strukturell begründet: der Inhalt folgt vollständig aus dem Bau-Snapshot. Statisches Gelände bricht diese Begründung — es sei denn, es steht auf jedem Host identisch und vor dem ersten Snapshot.Deshalb liegt das Schreiben in der Host-Konstruktion, nicht im Setup-Pass: der Wiedergabe-Host durchläuft
SetupMatchnie. Schreibzahl und Schreibreihenfolge (y, dann x, aufsteigend) liegen fest, damit derEpochüberall auf demselben Wert landet und spätere Baumutationen nach einem Restore im Gleichschritt weiterzählen. Der neue TestSnapshotRestore_ReproducesTheTerrainCarryingCostFieldExactlybeweist zellgenaue Identität,Epoch-Gleichheit und byte-identischen Umlauf.Weil der headless-Pfad
Gameplay/nicht kompiliert, trägtDeterminism10000Scenarioeinen handgespiegelten Zweitausdruck — zellgenau und über eine gemeinsame FNV-1a-Prüfsumme gepinnt.Gegengelesen — und was dabei herauskam
Diese Arbeit ist von einem zweiten, unabhängigen Worker angegriffen worden, der den Bericht des Autors bewusst zuletzt gelesen hat. Urteil: APPROVED, mit drei Befunden, die hier offen stehen sollen.
1. Eine falsche Begründung in tragender Doku — in diesem PR korrigiert. Der Docstring behauptete, die Wand sei zwei Zellen dick, weil eine einzellige Wand „diagonal leckt". Das ist falsch: ein Königszug ändert
max(|dx|,|dy|)um höchstens 1 und kann eine geschlossene Chebyshev-Schale nicht überspringen. Ich habe es nachgerechnet — eine einschalige geschlossene Wand leckt nicht. Die gebaute zweischalige Wand ist trotzdem richtig und dicht; nur ihre Begründung war es nicht. Der Docstring nennt jetzt den echten Grund (Tiefe der Öffnung, sichtbare Masse) und den Beweis, warum eine Schale bereits genügen würde. Das ist kein Schönheitsfehler: genau eine solche unpräzise Docstring-Aussage hat in diesem Sprint schon einmal zu einer falschen Inhaberentscheidung geführt (D-108).2. Eine Verifikationslücke, die bestehen bleibt. Die EditMode-Spur, die den Gameplay-Ausdruck pinnt, läuft in keiner CI (
tests.ymlfährt nur die headless-Kette). Die headless-Spur pinnt nur ihren eigenen Spiegel. Eine einseitige Drift vonGlutrinneTerrainMap.csbliebe in der CI also dauerhaft grün. Das ist die konkrete Rechnung, die die offene Hälfte von #110 aufmacht — ein manueller EditMode-Lauf ist hier das eigentliche Merge-Gate, und er steht aus.3. Ein blinder Fleck im Erreichbarkeitstest.
IntegrationField.Generatesät die Zielzelle ohne Begehbarkeitsprüfung. Ein Feld, das künftig unter einer Wand läge, würde als „erreichbar" gelten. Heute liegt kein Feld auf einer Wand, und die Zell-Pins fangen es ab — aber der Test verspricht mehr, als er hält.Simulation/Pathfinding/gehört dem Einheitenstrang; der Befund geht als eigenes Issue raus.Nachweis
dotnet test tools/Nova.SimRunner.Tests -c Release: 736/736 grün — vom Orchestrator auf frischemmainunabhängig nachgefahren, vor und nach der Docstring-KorrekturHerkunft
Gebaut von Kimi K3 als delegiertem Worker gegen die Sprintdatei als bindende Vorgabe, gegengelesen von einem zweiten unabhängigen Kimi-Lauf, Geometrie und Testkette vom Orchestrator nachgerechnet. Beide Berichte folgen im Doku-PR.