SeymourBETA

Update 2.234

18.8.2026

v2.234.0.0BETAMINOR

Seymour18. Aug. 2026

Persistente HD-Monster-Modelle in Aurora: 340 `.chr`→glTF-Bakes (Phyre-HD-Mesh + PS2-Skelett + `.mgrp`-Motion) texturiert/animiert, Y-up, committet + persistenter Repo-relativer Pfad

Bake-Regeneration (phyre_chr_gate-Pipeline aus Commit a731de5f wiederhergestellt): 340/341 Monster mit echtem Mesh, 328 texturiert, 237 mit PS2-Animationen (18–25 r0g0_..-Clips), 340 Y-up (--flip-y = flip_root-Node-Rotation [1,0,0,0] = 180° X). Nur m999 (Test-Dummy-Slot, kein Mesh) übersprungen.
Persistenz (angefordert, damit Endnutzer Monster+Texturen sehen): die ~892MB-Assets aus work/ (gitignored) in RuntimeTools/FFXModelAssets/chr/<id>/ verschoben (committet). Kein neues Präfix: der Aurora-EditViewer wird von python -m http.server AM REPO-ROOT bedient (python macht kein Prefix-Mapping) -> der Anker-Pfad ist REPO-RELATIV.
Anker-Pfad im Editor: AuroraChamber_DataModel emittiert jetzt /RuntimeTools/FFXModelAssets/chr/m{id:D3}/m{id:D3}_animated.gltf (war /work/phyre_chr_anim/models/...). Erfordert einen Editor-Rebuild; EditViewer neu laden, um Gegner als Modelle zu sehen (nicht mehr Kugeln).
Katalog: RuntimeTools/FFXModelAssets/catalog.json (340 Einträge, animiert/texturiert-Flags).
Tooling: der regenerierbare Runner work/phyre_chr_anim/BakeBatch.ps1 + das wiederhergestellte Tool work/phyre_chr_gate_build/ bleiben in work/ (gitignored); die ASSETS (Ergebnis) sind committet.
Ehrlich (HD-Lane-Grenzen): Textur ist die primäre .dds.phyre; ~12 Monster absichtlich untexturiert (kein tex/ im Manifest); T-Pose für die ohne eigene Motion (237/340 animiert); mögliche Resttorsion im Offline-Bind (A1/frame0/matrixParents bereits angewendet — am Bildschirm beurteilen). AuroraFieldExplorer_ChrModelResolver bleibt auf /work/ (separate npc/pc/sum/obj/wep-Kategorie, außerhalb des Umfangs).
Bump-Abstimmung: den PATCH-Bump v2.233.1.0 (andere Lane, umkämpftes csproj) in MINOR 2.234.0.0 subsumiert; Einträge in CHANGELOG/changelogUS/VERSIONING.
Gates: Editor-Build 0 Fehler (455 vorbestehende Warnungen); StringsIntegrityTests 3/3 (unbeeinflusst). Visuelle RT2-Validierung ausstehend (Rebuild + manuelles Re-Rendern).

v2.233.1.0

v2.234.0.1BETAPATCH

Seymour18. Aug. 2026

Encoding-Fix + Projekt-Lade-Crash: `FfxEncoding.us.cs` aus der Baseline neu generiert (UTF-8+BOM, korrekte Zeichen) mit dedupliziertem `UsEncoder` (doppelte `char`-Keys ließen das `Dictionary<char,byte>` beim Initialisieren von `ArgumentException` während `FfxEncoding` beim Projekt-Laden eine `KernelMonsterMagicLiveSync` werfen); 279 `.cs`-Dateien, die vom Banner-Skript cp1252-ifiziert wurden, in UTF-8+BOM konvertiert (verhindert String-Mojibake unter SDK-10s UTF-8-Standard)

Crash-Ursache: UsEncoder in FfxEncoding.us.cs hatte doppelte char-Keys (vorbestehender latenter Bug; ~192 Einträge). Ein Dictionary lehnt doppelte Keys ab → der FfxEncoding-statische Ctor warf beim ersten Gebrauch (jetzt durch KernelMonsterMagicLiveSync.SyncProject beim Öffnen eines Projekts ausgelöst). Fix: us.cs aus der Baseline (d91986a1) neu generieren und First-Wins-Dedup von UsEncoder. Die Baseline hatte bereits 56 Dup-Keys — latent, erst jetzt exponiert.
Mojibake: das Banner-Script entfernte BOMs und cp1252-ifizierte UTF-8-Dateien mit hohen Bytes. 279 .cs in UTF-8+BOM konvertiert (verlustfrei), sodass SDK-10 (liest ohne BOM als UTF-8) Strings korrekt dekodiert.
Gates: Build 0 Fehler; Editor öffnet und lädt ein Projekt ohne Crash.

v2.234.0.0

v2.234.1.0BETAPATCH

Yuna18. Aug. 2026

Aurora RealGame: Content-Ähnlichkeits-Fallback in `EncounterIndexBridge`; entsperrt Open RealGame für Kämpfe ohne byte-identische 0e/-Bin

Ursache: Open RealGame „wollte sich nicht einmal öffnen" für bika02_00, weil EncounterIndexBridge.TryResolve einen byte-identischen SHA-256 Match zu einer 0e/<id>.bin verlangte. Von den 858 Vanilla-Kämpfen matchen nur 614 den Hash der noclip-0e/-Extraktion (817 Bins); 244 bleiben SEM MATCH → BuildBattleUrl gab null zurück → das Viewer-Fenster wurde nie erstellt.
Fix (aus 3 Quellen bewiesen): neuer 256-Byte-Block-Ähnlichkeits-Fallback (FNV-1a, rsync-artig) in EncounterIndexBridge.Build — für jeden Kampf ohne exakten SHA die 0e/ mit der höchsten Block-Überlappung wählen, und wenn der Anteil ≥ MinSimilarityScore (0.50) ist, in BattleIdToNearestEncounter eintragen, wodurch 191 von 244 ungematchten. TryResolve/IsSimilarityResolved exponieren den Fallback; Aurora3DLauncher.BuildBattleUrl meldet „ungefähre Übereinstimmung (Ähnlichkeit)" ehrlich im Status.
Beweise: (1) Python work/probe_bika_v5.py: bika02_00 → 00d0.bin Score 0.98 (91/93 Blöcke), global 191/244 entsperrt; (2) Python work/probe_bika_v6.py: bika02_00 == 00d0.bin bei 99.75% identischen Bytes mit denselben Monster-ids — derselbe Kampf, nur 32 Bytes kleiner extrahiert; (3) C# RuntimeTools/Aurora3DLinkLab (Build+Run Exit 0): bika02_00 -> 0e/00D0.bin via=SIMILARIDADE, andere Probes intakt (azit03_00 exakt, sfia00_00 ehrlich SEM MATCH).
Gates: Build 0 Fehler (Editor + Lab). Nicht committet (Multi-lane-dirty-Worktree + In-Game-RT2 ausstehend), gemäß lane-Regel. Der 0e/-Override behält weiterhin sein .aurora3d.bak-Backup.

v2.234.0.1

Zurück zu Updates

SeymourBETA

Update 2.234

18.8.2026

v2.234.0.0BETAMINOR

Seymour18. Aug. 2026

Persistente HD-Monster-Modelle in Aurora: 340 `.chr`→glTF-Bakes (Phyre-HD-Mesh + PS2-Skelett + `.mgrp`-Motion) texturiert/animiert, Y-up, committet + persistenter Repo-relativer Pfad

Bake-Regeneration (phyre_chr_gate-Pipeline aus Commit a731de5f wiederhergestellt): 340/341 Monster mit echtem Mesh, 328 texturiert, 237 mit PS2-Animationen (18–25 r0g0_..-Clips), 340 Y-up (--flip-y = flip_root-Node-Rotation [1,0,0,0] = 180° X). Nur m999 (Test-Dummy-Slot, kein Mesh) übersprungen.
Persistenz (angefordert, damit Endnutzer Monster+Texturen sehen): die ~892MB-Assets aus work/ (gitignored) in RuntimeTools/FFXModelAssets/chr/<id>/ verschoben (committet). Kein neues Präfix: der Aurora-EditViewer wird von python -m http.server AM REPO-ROOT bedient (python macht kein Prefix-Mapping) -> der Anker-Pfad ist REPO-RELATIV.
Anker-Pfad im Editor: AuroraChamber_DataModel emittiert jetzt /RuntimeTools/FFXModelAssets/chr/m{id:D3}/m{id:D3}_animated.gltf (war /work/phyre_chr_anim/models/...). Erfordert einen Editor-Rebuild; EditViewer neu laden, um Gegner als Modelle zu sehen (nicht mehr Kugeln).
Katalog: RuntimeTools/FFXModelAssets/catalog.json (340 Einträge, animiert/texturiert-Flags).
Tooling: der regenerierbare Runner work/phyre_chr_anim/BakeBatch.ps1 + das wiederhergestellte Tool work/phyre_chr_gate_build/ bleiben in work/ (gitignored); die ASSETS (Ergebnis) sind committet.
Ehrlich (HD-Lane-Grenzen): Textur ist die primäre .dds.phyre; ~12 Monster absichtlich untexturiert (kein tex/ im Manifest); T-Pose für die ohne eigene Motion (237/340 animiert); mögliche Resttorsion im Offline-Bind (A1/frame0/matrixParents bereits angewendet — am Bildschirm beurteilen). AuroraFieldExplorer_ChrModelResolver bleibt auf /work/ (separate npc/pc/sum/obj/wep-Kategorie, außerhalb des Umfangs).
Bump-Abstimmung: den PATCH-Bump v2.233.1.0 (andere Lane, umkämpftes csproj) in MINOR 2.234.0.0 subsumiert; Einträge in CHANGELOG/changelogUS/VERSIONING.
Gates: Editor-Build 0 Fehler (455 vorbestehende Warnungen); StringsIntegrityTests 3/3 (unbeeinflusst). Visuelle RT2-Validierung ausstehend (Rebuild + manuelles Re-Rendern).

v2.233.1.0

v2.234.0.1BETAPATCH

Seymour18. Aug. 2026

Encoding-Fix + Projekt-Lade-Crash: `FfxEncoding.us.cs` aus der Baseline neu generiert (UTF-8+BOM, korrekte Zeichen) mit dedupliziertem `UsEncoder` (doppelte `char`-Keys ließen das `Dictionary<char,byte>` beim Initialisieren von `ArgumentException` während `FfxEncoding` beim Projekt-Laden eine `KernelMonsterMagicLiveSync` werfen); 279 `.cs`-Dateien, die vom Banner-Skript cp1252-ifiziert wurden, in UTF-8+BOM konvertiert (verhindert String-Mojibake unter SDK-10s UTF-8-Standard)

Crash-Ursache: UsEncoder in FfxEncoding.us.cs hatte doppelte char-Keys (vorbestehender latenter Bug; ~192 Einträge). Ein Dictionary lehnt doppelte Keys ab → der FfxEncoding-statische Ctor warf beim ersten Gebrauch (jetzt durch KernelMonsterMagicLiveSync.SyncProject beim Öffnen eines Projekts ausgelöst). Fix: us.cs aus der Baseline (d91986a1) neu generieren und First-Wins-Dedup von UsEncoder. Die Baseline hatte bereits 56 Dup-Keys — latent, erst jetzt exponiert.
Mojibake: das Banner-Script entfernte BOMs und cp1252-ifizierte UTF-8-Dateien mit hohen Bytes. 279 .cs in UTF-8+BOM konvertiert (verlustfrei), sodass SDK-10 (liest ohne BOM als UTF-8) Strings korrekt dekodiert.
Gates: Build 0 Fehler; Editor öffnet und lädt ein Projekt ohne Crash.

v2.234.0.0

v2.234.1.0BETAPATCH

Yuna18. Aug. 2026

Aurora RealGame: Content-Ähnlichkeits-Fallback in `EncounterIndexBridge`; entsperrt Open RealGame für Kämpfe ohne byte-identische 0e/-Bin

Ursache: Open RealGame „wollte sich nicht einmal öffnen" für bika02_00, weil EncounterIndexBridge.TryResolve einen byte-identischen SHA-256 Match zu einer 0e/<id>.bin verlangte. Von den 858 Vanilla-Kämpfen matchen nur 614 den Hash der noclip-0e/-Extraktion (817 Bins); 244 bleiben SEM MATCH → BuildBattleUrl gab null zurück → das Viewer-Fenster wurde nie erstellt.
Fix (aus 3 Quellen bewiesen): neuer 256-Byte-Block-Ähnlichkeits-Fallback (FNV-1a, rsync-artig) in EncounterIndexBridge.Build — für jeden Kampf ohne exakten SHA die 0e/ mit der höchsten Block-Überlappung wählen, und wenn der Anteil ≥ MinSimilarityScore (0.50) ist, in BattleIdToNearestEncounter eintragen, wodurch 191 von 244 ungematchten. TryResolve/IsSimilarityResolved exponieren den Fallback; Aurora3DLauncher.BuildBattleUrl meldet „ungefähre Übereinstimmung (Ähnlichkeit)" ehrlich im Status.
Beweise: (1) Python work/probe_bika_v5.py: bika02_00 → 00d0.bin Score 0.98 (91/93 Blöcke), global 191/244 entsperrt; (2) Python work/probe_bika_v6.py: bika02_00 == 00d0.bin bei 99.75% identischen Bytes mit denselben Monster-ids — derselbe Kampf, nur 32 Bytes kleiner extrahiert; (3) C# RuntimeTools/Aurora3DLinkLab (Build+Run Exit 0): bika02_00 -> 0e/00D0.bin via=SIMILARIDADE, andere Probes intakt (azit03_00 exakt, sfia00_00 ehrlich SEM MATCH).
Gates: Build 0 Fehler (Editor + Lab). Nicht committet (Multi-lane-dirty-Worktree + In-Game-RT2 ausstehend), gemäß lane-Regel. Der 0e/-Override behält weiterhin sein .aurora3d.bak-Backup.

v2.234.0.1