# 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](U1.5-UNITY.md#float-befund).

## 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. |

## 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](U1-RULES.md#bewusst-andere-technische-repräsentation).

## 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).