martin/champions-of-luneraria
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
champions-of-luneraria/docs/port/KNOWN-BEHAVIOR-DIFFERENCES.md
Martin Stickelbroeck c386206876 U5.5-pilot Figuren: Meshy-Kohlenbeißer, Lava-Glut, GPU-Skinning 
Pilot für eine generierte Figur: der Kohlenbeißer g01 kommt als Meshy-Ergebnis
in den Port und ersetzt dort das Phase-4-Modell. Eine Figur genügt, um Pipeline,
Bild und Leistung zu bewerten; Anatomie, Gesichter und Haare bleiben
Künstler-Sculpts oder lizenzierte Packs (Vorgabe vom 1. Oktober).

- Meshy-Pipeline unter tools/meshy/: API-Client (meshy.py, Ledger, Schlüssel
  nie geloggt) und Blender-Generator (build_figure.py) aus den unveränderten
  Downloads in assets-source/meshy/g01/. Export über den Manifest-Eintrag
  kohlenbeisser mit "replaces": "g01"; LuneUnitLibraryBuilder hängt die Figur
  zusätzlich unter der Godot-ID ein.
- UV-Material AI_Kohlenbeisser (Familie authored): die Karten der Figur selbst,
  Lava-Glut aus der Albedo-Alpha (Meshy 7.1 ohne Emission-Map) mit _Glow 1,25.
- Schatten ohne Normalen-Versatz (LuneShadowBias, _ShadowNormalScale 0): die
  UV-Naht-Kopien tragen geknickte Normalen; URP ApplyShadowBias zog helle
  Nähte durch den Schatten. Die Figur wirft nur mit Tiefen-Bias.
- GPU-Batched-Skinning (PlayerSettings.meshDeformation, LuneProjectSetup):
  35 Meshy-Kohlenbeißer kosteten mit CPU-Skinning rund 1 ms Haupt- und
  1,7 ms Render-Thread je Bild.
- LuneBenchmark: -luneBenchmarkRound und -luneBenchmarkArmy (Figuren-Stress).
  LuneAssetPreview: LUNE_ONLY für Vorher/Nachher, Trefferframe aus der
  Kontaktzeit des Manifests. FigureViewsTests (Explicit) für die vier
  Spielmomente der Figur.
- Tests: EditMode 29/29, PlayMode 14/14 (6 Explicit), Verify 718/0,
  Player-Selbsttest 30/30, Kerntests 457/457, Fingerabdrücke unverändert
  (DCE95C96556F3A1A, 7B8E43AEFC0D60C5).
- Leistung (A/B im selben Fenster, 35x g01): Meshy -21 % Mid (109,7 zu 138,8)
  und -13 % Karte (91,7 zu 105,6) gegenüber Phase-4. GPU-Skinning hebt Mid
  um 7-27 % und entlastet Haupt- und Render-Thread. Standard-Partie ab Runde 21
  ohne g01 im Bild: drei Varianten bis 6 %.
- Doku: U5-VISUAL (U5.5), PORT-QA, PORT-STATUS, KNOWN-BEHAVIOR-DIFFERENCES;
  Bilder screenshots/u5.5/ und u5.5-gpu/, Rohdaten logs/u5.5/.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-09 14:14:59 +02:00

76 lines
7 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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).
## 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](U2-WORLD.md#u2c--simulation-und-darstellung)).
## 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](U3-UI.md#theme-symbole-schriften)). |
## Darstellung (U5)
| Wert | Warum kein Regelunterschied |
| --- | --- |
| PBR-Maps über den Weltfarben | Die Regeln und die Golden-Parität lesen keine Materialien. Der Lankorridor trägt gebackene Albedo-/Normal-/ORM-Sätze. |
| Stufen Lane/Rand (U5.2) | `LuneZones.NearLane` (22 m) trennt Zielqualität von der Randstufe (Farbe + Steinschicht). Harte Grenze je Weltknoten; Regeln lesen keine Materialien. |
| Hit- und Angriffs-Flash | Der Kern-HitFlash (0,18 s) und der Angriffs-Flash färben die Figur über einen MaterialPropertyBlock. Darstellerisch; keine Regel liest den Blitz. |
| Nebel und Farbabstimmung | `RenderSettings.fog` und das Volume (ACES, Bloom, Weißabgleich, Vignette) betreffen nur das Bild. |
| Turmblitze als Funke | Drei Punkte mit Breitenkurve statt des einfachen Rohrs aus U2; dieselben Angriffsereignisse (`AttackSerial`). |
| Meshy-Figur für `g01` (U5.5) | Der Kohlenbeißer zeigt die Meshy-Geometrie und UV-Textur statt des Phase-4-Modells (`"replaces"` in der Bibliothek). Dieselbe Definition, dieselben Regeln; nur die Darstellung wechselt. |
| Lava-Glut aus Albedo-Alpha (U5.5) | Meshy 7.1 liefert keine Emission-Map. Die Maske steckt in der Albedo-Alpha und wird mit `_Glow` (1,25) als Emission addiert — rein darstellerisch. |
| Schatten der Meshy-Figur ohne Normalen-Versatz (U5.5) | UV-Naht-Kopien tragen geknickte Normalen; `ShadowNormalScale 0` lässt die Figur nur mit Tiefen-Bias werfen, damit die Sonne keine hellen Nähte zieht. Kein Regelergebnis. |
| GPU-Batched-Skinning (U5.5) | `PlayerSettings.meshDeformation = GPUBatched` verformt skinned Figuren in Compute-Batches. Gleiche Posen und Angriffszeiten, andere Thread-Last (siehe Leistung U5.5). |
## Netzwerk (U4)
| Wert | Warum kein Regelunterschied |
| --- | --- |
| Transport TCP statt ENet | Der Host rechnet weiter autoritativ; Clients senden nur Absichten. Kampfrahmen laufen auf demselben Socket und werden über die Serial verworfen (wie `unreliable_ordered`). Unter Paketverlust kann TCP Head-of-Line-Blocking erzeugen — rein darstellerisch, kein Regelergebnis. |
| Mehr-Runden-Loopback im Prozess | `net_rounds.py` startet zwei Godot-Prozesse; `NetRoundsSuite` koppelt zwei `LuneSession` über `LuneLoopback`. Protokoll, Prüfsummen, Übernahme und Wiedereinstieg sind dieselben Pfade. |
| Rückkehr zum Startbildschirm (U4-Nachtrag) | Godots HUD-Knopf „Menü“ kehrt sofort zurück und gibt das Spielobjekt frei. Der Port fragt vorher (Dialog aus U3), behält die Szene und setzt den Treiber auf eine ruhende neue Partie. In beiden Fällen endet die Sitzung; keine Regel ist betroffen. |
## 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).
Reference in a new issue View git blame Copy permalink