feat(ui): eine Ressourcenleiste für Aetherium, Decke und Strom (#137) - #139
Merged
Conversation
cubetribe
added a commit
that referenced
this pull request
Aug 31, 2026
…ägt das Startguthaben (#136, #131) (#141) ## Warum Aus der Proberunde des Inhabers vom 31.08.2026 auf Build `97e5459`: > „Ich hatte den Fall, dass das Lager voll ist, aber die Sammler fahren weiter. Die ernten ab, bringen das zur Raffinerie, aber das erhöht den Kontostand nicht. Das vernichtet Material." Fixes #136 Fixes #131 ## #136 — gebremst wird beim Aufnehmen, nicht beim Abliefern Genau so war es implementiert, und die Einzahlungsdeckelung ist gewollt (D-024, „Überschuss verfällt"). Was die Regel nicht vorsah: dass der Sammler trotzdem weiterfährt. Seit die Vorkommen endlich sind (#80) ging dabei nicht nur die Fahrt verloren, sondern **der Rohstoff selbst** — das Feld hatte die Menge bereits abgegeben, unwiederbringlich, während der Spieler zusah und es für Fortschritt hielt. Der Sammler hält jetzt **beim Aufnehmen** an, nicht erst beim Abliefern. Das ist die ehrlichere Stelle: was nie abgebaut wurde, ist nicht verloren. Er behält Auftrag und Ladung, und nimmt die Arbeit von selbst wieder auf, sobald Platz ist — durch ein neues Lager oder schlicht durch Ausgeben. Drei Tests pinnen den Halt, **beide** Wege der Wiederaufnahme und die Grenze „1 AE Platz heißt arbeiten"; ein Sammler, der nach dem Lagerbau nicht wieder anfängt, wäre schlimmer als das Problem. **Was ausdrücklich bleibt:** dass der Überschuss verfällt. Das ist D-024. Geändert hat sich nur, ob überhaupt noch abgebaut wird. ## #131 — die Decke trägt wieder, was das Spiel austeilt `HqBaseCapacityAE` steigt von 2.000 auf 3.000 AE. Die Herkunft ist die eigentliche Geschichte: die 3.000 AE Startguthaben kamen mit **D-077** als bewusst gesetzter Eröffnungspuffer, die 2.000er-Decke erst viel später mit **D-024 / Sprint 16.4**. Beide Konstanten taten genau, was ihre Entscheidung sagte — nur hob die zweite die erste auf, und niemandem fiel es auf. Ein Drittel des Startguthabens verdampfte in den ersten fünfzehn Sekunden jeder Partie. Bewusst in Kauf genommen: das Lagergebäude wird früh weniger wertvoll, weil man erst ab 3.000 eines braucht. **Der eigentliche Ertrag ist der Test, den es bis heute nicht gab.** Kein Test sah Startguthaben und Decke zusammen — genau deshalb blieb der Widerspruch drei Wochen stehen. Er ist jetzt da. ## Die nachgezogenen Pins — jeder einzeln begründet | Pin | alt → neu | warum | |---|---|---| | `SellStorage_…` | 4000 → **4050** | Mit der höheren Decke passt die ganze 150-AE-Rückerstattung, vorher nur 100 davon | | `SellStorage_…` Verfall | 3500 → **3788** | Der Überschuss nach dem Verkauf ist 1.050 statt 2.000 | | `CurrentRulesHash_MovesPastRevisionTwo…` | `0x05CCA847…` → **`0xD1B68383…`** | `HqBaseCapacityAE` ist eine gehashte Regelkonstante — die Bewegung ist der Zweck | | `RulesRevisionOneAndTwo…` (Rev 1 + 2) | siehe unten | **Das ist keine gewöhnliche Neusetzung** | | `CanonicalAiMatch_DecidesOnThePinnedTick…` | `0x10B83E94…` → **`0x4A861D9F…`** | **Arns Datei**, siehe unten | | `StartField_…` (4 Tests) | Werte **unverändert** | Die Fixture war kaputt, nicht die Messung | ### Die Startfeld-Messung: Fixture repariert, Zahlen unverändert Die vier 21.3-Tests schlugen mit „field not exhausted after 20000 ticks" fehl — das Feld wurde **nie** leer. Grund: `CapacityFor` liefert für einen Slot **ohne fertiges HQ** eine Decke von **null**, und die Fixture spawnte nur eine Raffinerie. Seit #136 heißt das „permanent voll", also rührte sich kein Sammler mehr. Die Fixture bekommt deshalb ein HQ und einen Verbraucher, der das Konto jeden Tick leert. Beides stellt her, was sie immer zu messen behauptete: wie lange das **Feld** bei reiner Ernterate trägt, mit der Lagerdecke bewusst aus der Frage heraus. **Die gepinnten Tickzahlen sind unverändert** (4527 / 2263 / 1509) — die Erntedynamik hat sich nie geändert, nur die Bedingung, unter der sie pausiert. ### Die Revision-Pins überstreichen einen bekannten Defekt `RulesRevisionOneAndTwo_GoldenHashesRemainByteStable` sichert zu, dass die **historischen** Regel-Revisionen eingefroren sind. Eine Änderung an einer **heutigen** Konstante hat sie bewegt — weil `ComputeRulesHash64` für jede Revision die heutigen Konstanten hasht und nur die Feldzahl historisch ist. Das ist [#138](#138). Die Neusetzung macht den Test grün. **Sie macht die Zusicherung nicht wieder wahr.** Damit das der nächste Leser nicht übersieht, steht der Verweis auf #138 jetzt als Kommentar direkt an der Zusicherung — ein sauberer grüner Test an dieser Stelle wäre irreführend. ### Der gepinnte KI-Ausgang gehört dem Einheitenstrang `CanonicalAiOutcomeTests` ist **Arns Datei**. Die Wirtschaftsänderung bewegt die kanonische Partie, und das ist exakt Risiko **R-3** aus Sprint 21, das hier eintritt. Der Pin ist nachgezogen, damit die Kette grün ist — **das Merge-Fenster, das ihn bewegt hat, ist dieses hier.** Wer den alten Wert sucht: `0x10B83E94F86F2E55`. ## Nachweis - `dotnet test tools/Nova.SimRunner.Tests -c Release`: **754/754 grün**, vom Orchestrator gefahren - Keine der vier vom `baseline-guard` geschützten Golden-Byte-Dateien ist berührt — kein `baseline-reset-approved` nötig. Alle Bewegungen sind Erwartungswerte, und der Wächter sagt in seinem eigenen Kommentar, dass eine Testanpassung für sich keine Verhaltensänderung ist - **Nicht belegt:** die EditMode-Spiegel sind mitgezogen, aber nicht gelaufen — und wie sich der pausierende Sammler anfühlt, kann kein Test sagen. Er braucht die Sichtbarkeit aus [#139](#139), die dafür schon auf `main` liegt ## Herkunft Erarbeitet von **Kimi K3** als delegiertem Worker; die acht roten Tests hat er gemeldet statt grün gemacht, mit alten und neuen Werten. Die Pins, die Fixture-Reparatur und der #138-Vermerk stammen vom Orchestrator.
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
1 participant
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.
Warum
Aus der Proberunde des Inhabers vom 31.08.2026 auf Build
97e5459:Fixes #137
Bisher erfuhr der Spieler seinen Zustand nur an Stellen, die dafür nicht gemacht sind: den Kontostand in der Baukarte, wo er Knöpfe sperrt; Strom und Lagerdecke ausschließlich in der DebugHud, teils erst hinter
F3— einem Entwicklerwerkzeug. Die Lagerdecke stand nirgends im Spiel-UI.Damit waren drei Regeln unsichtbar, die aktiv in die Partie eingreifen:
Was die Leiste zeigt
2.318 / 3.000liest sich sofort als „darüber";2.318allein sagt nichts. Die Decke kommt immer ausCapacityFor— nirgends steht eine Zahl fest, denn sie wächst mit jedem Lager und fällt, wenn eines zerstört wird.Wie es gebaut ist
Die Formatier- und Zustandslogik liegt in
Gameplay/UI/ResourceBarPresenterals reine, Unity-freie Funktionen, diePresentation/UI/ResourceBarHudnur noch zeichnet. Dasselbe Muster, das Paket 21.5 mitCommandCardPresenteretabliert hat: was inOnGUIhängt, kann niemand testen; was daneben liegt, schon. 19 neue EditMode-Tests decken den Presenter ab.Die Leiste steht bewusst nicht in
IsPointerOverHud: sie ist eine reine Anzeige und schluckt keine Klicks. Die Entscheidung samt Begründung steht im Docstring, nicht nur hier.Im Szenengenerator wird sie als letzte Komponente hinzugefügt — die
AddComponent-Reihenfolge ist dieOnGUI-Malreihenfolge, sie zeichnet also über der Debug-Statuszeile statt darunter.Nachweis — erstmals in Unity gefahren
Das ist der Teil, der bei den letzten Paketen offen bleiben musste:
dotnet test tools/Nova.SimRunner.Tests: 739/739 grün, unverändert — diese Kette kompiliertPresentation/gar nicht mit und belegt hier nur, dass nichts in die Simulation durchgeschlagen ist.Nicht belegt und nur am Bildschirm zu klären: wie die Leiste aussieht und ob sie sich mit anderen Flächen beißt. Bekannte Nachbarschaft, bewusst in Kauf genommen: bei geöffnetem F3-Panel und sehr schmalem Fenster und zwei gleichzeitigen Warnungen kann sie das Debug-Panel überlappen. F3 ist Entwicklersicht; die Leiste weicht dafür keiner Spiel-Fläche aus.
Zwei Nebenwirkungen der Szenenerzeugung
MAP_Glutrinne.assetbekommt 10 Zeilen dazu. Das ist die Wirkung von Paket 22.3: seit #125 liest der Generator die Feldlage ausMatchBootstrapstatt sie zu wiederholen — das Asset trägt jetzt die 15 Vorkommen statt der alten 5. Der erste Beleg, dass die Korrektur greift.UniversalRenderPipelineGlobalSettings.assetwurde bewusst zurückgesetzt. Unity hat die Datei beim Frischimport neu serialisiert und dabei eine Laufzeitliste geleert. Das hat mit diesem PR nichts zu tun und könnte das Rendering ändern — es gehört nicht heimlich mit hinein.Herkunft
Erarbeitet von Kimi K3 als delegiertem Worker (Presenter, HUD, Tests). Verdrahtung im Szenengenerator, Szenenerzeugung und der Unity-Testlauf vom Orchestrator.