66867f3332
Das G3-HUD ist abgenommen; der Meilenstein U3 ist damit fertig. - Prüfung (Port von verify_g3, Teile A–H plus I): 718 Prüfungen ohne Fehler. Teil I prüft die Feld-Darstellung um das HUD (U3-Zugabe aus dem Motivvergleich): Aufstellungsflächen, Grotteneingang, ruhender Boss, Namensschilder, Eigentümer-Ring, Ancient-Balken. - Feld um das HUD: Namensschilder für Helden (mit Stufe), Angriffs- champions und den eingesetzten Boss („für Blau“), Eigentümer-Ring, Ancient-Balken bei Schaden, ruhende Schlundkrone auf dem Podest, eigener Grotteneingang, Aufstellungsflächen als eigene Objekte. - Schriften korrigiert: Die Referenz deklariert Cantarell 560/700–760 und Cinzel 700, wendet die Gewichte aber nie an (variation_opentype mit dem String-Schlüssel „wght“ wird von Godot ignoriert). G3 zeigt Regular 400, der Port ebenso — Cinzel-Regular statt Bold, keine Kontur zur Aufdickung. Laufweite aus spacing_glyph umgerechnet; dunkler Saum als Schatten statt TextCore-Kontur. - Werkzeuge: HudViewsTests (14 G3-Motive), HudPlaytest (Spieltest über die echte Oberfläche per Befehlsdateien), ui_ms_per_frame im LuneBenchmark. Layout folgt den echten Panelhöhen, Kamera startet wie Godot _ready auf der eigenen Lane. - Tests: EditMode 23/23, PlayMode 13/13, Kerntests 402/402, Verify 718/0. Fingerabdrücke der Bot-Partien unverändert (DCE95C96556F3A1A, 7B8E43AEFC0D60C5). - Bilder: 14 Motive bei 1920×1080, Auflösungen 1152×720 bis 2560×1440, Prüf-Schlüsselbilder, Spieltest-Screenshots. - Leistung (macOS-Player mit HUD, 116 Einheiten): 169 fps Übersicht, 218 fps Mid nah; HUD-Skripte 0,090 bzw. 0,078 ms je Bild. - Dokumentation: U3-UI (U3D, Schriftbefund), PORT-QA (U3), PORT-STATUS (U3 fertig, U4 nächster Schritt), KNOWN-BEHAVIOR-DIFFERENCES. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.5 KiB
4.5 KiB
Bekannte Verhaltensunterschiede
Diese Datei führt jedes bekannte Verhalten des Unity-Ports, das von der Godot-Referenz (luneraria/g3, 1b540f2) abweicht oder bewusst gleich falsch bleibt. Jeder Eintrag nennt Ursache, Wirkung, Nachweis und Status. Neue Befunde kommen hier hinein, bevor sie behoben werden.
Legacy defects retained for parity
Diese Fehler der Referenz sind im Port absichtlich nachgebildet. Die Golden-Parität bleibt so erhalten, und Bots und Partien verhalten sich fachlich wie in Godot. Jeder Fehler wird später in einem eigenen Schritt behoben, mit neuer Golden-Referenz und eigenem Commit.
R1 · Bot vergisst die Bossjagd nach einer Champion-Buchung
| Ort in der Referenz | saumwacht-godot/scripts/luneraria/core/lune_bot.gd, _plan_boss (Zeile 150) |
| Ort im Port | Assets/Luneraria/Core/Simulation/LuneBot.cs, PlanBoss (Kommentar R1) |
| Ursache | Das Bot-Gedächtnis wird von zwei Stellen befüllt. Die Champion-Planung legt einen Eintrag nur mit champion_round an. _plan_boss liest danach memory.bar und memory.sent, die fehlen. GDScript meldet Invalid access to property or key 'bar' und bricht die Funktion ab. |
| Wirkung | Ein Bot, der vor seiner ersten Bossplanung einen Champion gebucht hat, schickt in dieser Partie nie eine Expedition in die Grotte. Das betrifft vor allem das Profil bossjagd. Die Bossjagd der Bots ist dadurch seltener, als die Profile vorsehen. |
| Nachweis | Beim Erzeugen der Golden-Referenzen trat der Fehler in vier Szenarien auf. Der Port liefert in allen 19 Szenarien dieselben Bossentscheidungen (Golden-Bereich „Boss“: 1.559 Werte, 0 Abweichungen). |
| Status | bewusst übernommen (U1, U1.5). Nicht korrigieren, solange U1 als Paritätsreferenz dient. |
| Korrektur später | In einer eigenen Bot- oder Balance-Phase: fehlende Felder mit Standardwerten anlegen (bar = 1,35, sent = 0), neue Golden-Referenz erzeugen und den Unterschied zu dieser Referenz dokumentieren. |
Laufzeitunterschiede
F1 · Mono rechnet float32-Zwischenwerte doppelt genau (behoben in U1.5)
| Ursache | Unitys Mono 6.13 hält float32-Zwischenwerte doppelt genau (erlaubt nach ECMA-335 I.12.1.3). .NET 8 und Godot runden nach jeder Operation. |
| Wirkung ohne Korrektur | Positionen weichen nach 10–60 s um bis zu 0,22 mm ab, die Blickrichtung um bis zu 1,6·10⁻³ rad. In mirror_match verliert eine Einheit in Schritt 599 ihr Ziel, und der Kampf dauert 4,8 s länger. Die Abweichung beeinflusst also Entscheidungen. |
| Maßnahme | Vec2 rundet jeden Zwischenwert explizit auf float32. Keine Regeländerung; .NET-Ergebnisse sind byteidentisch zu vorher. |
| Status | behoben. Im Unity-Editor (Release und Debug) sind alle Golden-Werte bitgleich. CoreIntegrationTests.CoreFloatArithmeticMatchesGodot sichert das ab. |
| Offen | IL2CPP sowie Player unter Windows 11 und Fedora 44 sind noch nicht gemessen (Build-Module fehlen). |
Details: U1.5-UNITY.md.
Unity-Szene (U2)
Die Szene ändert kein Verhalten. Der Host treibt den Kern im festen Takt; die Ansichten lesen nur. Die vollständige Bot-Partie (Seed 2) und die Partie ab Runde 21 (Seed 9) liefern in der Szene denselben Fingerabdruck wie der reine Kernlauf. Das gilt auch bei 30, 60 und 120 fps, unbegrenzter Bildrate, Rucklern und erhöhtem Spieltempo (U2-WORLD.md).
Darstellungswerte
| Wert | Warum kein Regelunterschied |
|---|---|
Blickrichtung (LuneUnit.Facing) |
Der Kern schreibt sie nur (Bewegungsrichtung ab 1 mm Schritt); keine Regel liest sie. Die Darstellung darf sie glätten. |
| Schriftgewichte (U3D) | Das Theme der Referenz deklariert Cantarell 560/700–760 und Cinzel 700, wendet sie aber nie an: SaumwachtTheme.font schreibt variation_opentype = {"wght": …} mit dem String-Schlüssel „wght“, den Godot 4.7.2 ignoriert. G3 zeigt Regular 400, der Port ebenso. Die Rollen bleiben getrennt, damit U5 echte Gewichte vergeben kann (U3-UI.md). |
Technische Repräsentation
Klassen statt Dictionaries, stabile Einfügesortierung, 32-Bit-int, der ungenutzte Zufallsgenerator entfällt. Keiner dieser Unterschiede ändert Ergebnisse. Die Liste steht in U1-RULES.md.
Noch nicht gemessen
- IL2CPP-Player (alle Plattformen).
- Mono-Player unter Windows 11 (x64) und Fedora 44 (x86_64).
- Läufe auf x86-64-Prozessoren. Bisher lief alles auf Apple M5 (ARM64).