SeymourBETA

Update 2.234

8/18/2026

v2.234.0.0BETAMINOR

SeymourAug 18, 2026

Persistent HD monster models in Aurora: 340 `.chr`→glTF bakes (Phyre HD mesh + PS2 skeleton + `.mgrp` motion) textured/animated, Y-up, committed + persistent repo-relative path

Bake regeneration (phyre_chr_gate pipeline recovered from commit a731de5f): 340/341 monsters with real mesh, 328 textured, 237 with PS2 animations (18–25 r0g0_.. clips), 340 Y-up (--flip-y = flip_root node rotation [1,0,0,0] = 180° X). Only m999 (test dummy slot, no mesh) skipped.
Persistence (requested so end users see monsters+textures): the ~892MB assets moved out of work/ (gitignored) into RuntimeTools/FFXModelAssets/chr/<id>/ (committed). No new prefix: the Aurora EditViewer is served by python -m http.server AT THE REPO ROOT (python does no prefix-mapping) -> the anchor path is REPO-RELATIVE.
Anchor path in editor: AuroraChamber_DataModel now emits /RuntimeTools/FFXModelAssets/chr/m{id:D3}/m{id:D3}_animated.gltf (was /work/phyre_chr_anim/models/...). Requires an editor rebuild; reload the EditViewer to see enemies as models (no longer spheres).
Catalog: RuntimeTools/FFXModelAssets/catalog.json (340 entries, animated/textured flags).
Tooling: the regenerable runner work/phyre_chr_anim/BakeBatch.ps1 + recovered tool work/phyre_chr_gate_build/ stay in work/ (gitignored); the ASSETS (result) are committed.
Honest (HD-lane limits): texture is the primary .dds.phyre; ~12 monsters untextured by design (no tex/ in manifest); T-pose for those without their own motion (237/340 animated); possible residual torsion in the offline bind (A1/frame0/matrixParents already applied — judge on screen). AuroraFieldExplorer_ChrModelResolver stays on /work/ (separate npc/pc/sum/obj/wep category, out of scope).
Bump reconciliation: subsumed the PATCH bump v2.233.1.0 (other lane, contended csproj) into MINOR 2.234.0.0; entries in CHANGELOG/changelogUS/VERSIONING.
Gates: editor build 0 errors (455 pre-existing warnings); StringsIntegrityTests 3/3 (unaffected). Visual RT2 validation pending (rebuild + manual re-render).

v2.233.1.0

v2.234.0.1BETAPATCH

SeymourAug 18, 2026

Encoding fix + project-load crash: `FfxEncoding.us.cs` regenerated from baseline (UTF-8+BOM, correct chars) with `UsEncoder` deduplicated (duplicate `char` keys made the `Dictionary<char,byte>` throw `ArgumentException` when `FfxEncoding` was initialized during `KernelMonsterMagicLiveSync` on project load); 279 `.cs` cp1252-ified by the banner script converted to UTF-8+BOM (prevents string mojibake under SDK-10's UTF-8 default)

Crash root cause: UsEncoder in FfxEncoding.us.cs had duplicate char keys (pre-existing latent bug; ~192 entries). A Dictionary rejects duplicate keys → the FfxEncoding static ctor threw on first use (now triggered by KernelMonsterMagicLiveSync.SyncProject when opening a project). Fix: regenerate us.cs from baseline (d91986a1) and first-wins dedup of UsEncoder. Baseline already had 56 dup keys — latent, only now exposed.
Mojibake: the banner script stripped BOMs and cp1252-ified UTF-8 files with high bytes. 279 .cs converted to UTF-8+BOM (lossless) so SDK-10 (reads BOM-less as UTF-8) decodes strings correctly.
Gates: build 0 errors; editor opens and loads a project without crashing.

v2.234.0.0

v2.234.1.0BETAPATCH

YunaAug 18, 2026

Aurora RealGame: content-similarity fallback in `EncounterIndexBridge`; unlocks Open RealGame for battles with no byte-identical 0e/ bin

Root cause: Open RealGame "wouldn't even open" for bika02_00 because EncounterIndexBridge.TryResolve required a byte-identical SHA-256 match to a 0e/<id>.bin. Of the 858 vanilla battles, only 614 hash-match the noclip 0e/ extraction (817 bins); 244 stay SEM MATCH → BuildBattleUrl returned null → the viewer window was never created.
Fix (proven from 3 sources): new 256-byte block-similarity fallback (FNV-1a, rsync-style) in EncounterIndexBridge.Build — for each battle with no exact SHA, pick the 0e/ with the highest block overlap, and if the fraction ≥ MinSimilarityScore (0.50) record it in BattleIdToNearestEncounter, unlocking 191 of 244 unmatched. TryResolve/IsSimilarityResolved expose the fallback; Aurora3DLauncher.BuildBattleUrl reports "approx match (similarity)" honestly in the status.
Evidence: (1) Python work/probe_bika_v5.py: bika02_00 → 00d0.bin score 0.98 (91/93 blocks), global 191/244 unlocked; (2) Python work/probe_bika_v6.py: bika02_00 == 00d0.bin at 99.75% identical bytes with same monster ids — the SAME encounter, just extracted 32 bytes smaller; (3) C# RuntimeTools/Aurora3DLinkLab (build+run exit 0): bika02_00 -> 0e/00D0.bin via=SIMILARIDADE, other probes intact (azit03_00 exact, sfia00_00 honestly SEM MATCH).
Gates: build 0 errors (editor + lab). Not committed (multi-lane dirty worktree + in-game RT2 pending), per lane rule. The 0e/ override still keeps its .aurora3d.bak backup.

v2.234.0.1

Back to updates

SeymourBETA

Update 2.234

8/18/2026

v2.234.0.0BETAMINOR

SeymourAug 18, 2026

Persistent HD monster models in Aurora: 340 `.chr`→glTF bakes (Phyre HD mesh + PS2 skeleton + `.mgrp` motion) textured/animated, Y-up, committed + persistent repo-relative path

Bake regeneration (phyre_chr_gate pipeline recovered from commit a731de5f): 340/341 monsters with real mesh, 328 textured, 237 with PS2 animations (18–25 r0g0_.. clips), 340 Y-up (--flip-y = flip_root node rotation [1,0,0,0] = 180° X). Only m999 (test dummy slot, no mesh) skipped.
Persistence (requested so end users see monsters+textures): the ~892MB assets moved out of work/ (gitignored) into RuntimeTools/FFXModelAssets/chr/<id>/ (committed). No new prefix: the Aurora EditViewer is served by python -m http.server AT THE REPO ROOT (python does no prefix-mapping) -> the anchor path is REPO-RELATIVE.
Anchor path in editor: AuroraChamber_DataModel now emits /RuntimeTools/FFXModelAssets/chr/m{id:D3}/m{id:D3}_animated.gltf (was /work/phyre_chr_anim/models/...). Requires an editor rebuild; reload the EditViewer to see enemies as models (no longer spheres).
Catalog: RuntimeTools/FFXModelAssets/catalog.json (340 entries, animated/textured flags).
Tooling: the regenerable runner work/phyre_chr_anim/BakeBatch.ps1 + recovered tool work/phyre_chr_gate_build/ stay in work/ (gitignored); the ASSETS (result) are committed.
Honest (HD-lane limits): texture is the primary .dds.phyre; ~12 monsters untextured by design (no tex/ in manifest); T-pose for those without their own motion (237/340 animated); possible residual torsion in the offline bind (A1/frame0/matrixParents already applied — judge on screen). AuroraFieldExplorer_ChrModelResolver stays on /work/ (separate npc/pc/sum/obj/wep category, out of scope).
Bump reconciliation: subsumed the PATCH bump v2.233.1.0 (other lane, contended csproj) into MINOR 2.234.0.0; entries in CHANGELOG/changelogUS/VERSIONING.
Gates: editor build 0 errors (455 pre-existing warnings); StringsIntegrityTests 3/3 (unaffected). Visual RT2 validation pending (rebuild + manual re-render).

v2.233.1.0

v2.234.0.1BETAPATCH

SeymourAug 18, 2026

Encoding fix + project-load crash: `FfxEncoding.us.cs` regenerated from baseline (UTF-8+BOM, correct chars) with `UsEncoder` deduplicated (duplicate `char` keys made the `Dictionary<char,byte>` throw `ArgumentException` when `FfxEncoding` was initialized during `KernelMonsterMagicLiveSync` on project load); 279 `.cs` cp1252-ified by the banner script converted to UTF-8+BOM (prevents string mojibake under SDK-10's UTF-8 default)

Crash root cause: UsEncoder in FfxEncoding.us.cs had duplicate char keys (pre-existing latent bug; ~192 entries). A Dictionary rejects duplicate keys → the FfxEncoding static ctor threw on first use (now triggered by KernelMonsterMagicLiveSync.SyncProject when opening a project). Fix: regenerate us.cs from baseline (d91986a1) and first-wins dedup of UsEncoder. Baseline already had 56 dup keys — latent, only now exposed.
Mojibake: the banner script stripped BOMs and cp1252-ified UTF-8 files with high bytes. 279 .cs converted to UTF-8+BOM (lossless) so SDK-10 (reads BOM-less as UTF-8) decodes strings correctly.
Gates: build 0 errors; editor opens and loads a project without crashing.

v2.234.0.0

v2.234.1.0BETAPATCH

YunaAug 18, 2026

Aurora RealGame: content-similarity fallback in `EncounterIndexBridge`; unlocks Open RealGame for battles with no byte-identical 0e/ bin

Root cause: Open RealGame "wouldn't even open" for bika02_00 because EncounterIndexBridge.TryResolve required a byte-identical SHA-256 match to a 0e/<id>.bin. Of the 858 vanilla battles, only 614 hash-match the noclip 0e/ extraction (817 bins); 244 stay SEM MATCH → BuildBattleUrl returned null → the viewer window was never created.
Fix (proven from 3 sources): new 256-byte block-similarity fallback (FNV-1a, rsync-style) in EncounterIndexBridge.Build — for each battle with no exact SHA, pick the 0e/ with the highest block overlap, and if the fraction ≥ MinSimilarityScore (0.50) record it in BattleIdToNearestEncounter, unlocking 191 of 244 unmatched. TryResolve/IsSimilarityResolved expose the fallback; Aurora3DLauncher.BuildBattleUrl reports "approx match (similarity)" honestly in the status.
Evidence: (1) Python work/probe_bika_v5.py: bika02_00 → 00d0.bin score 0.98 (91/93 blocks), global 191/244 unlocked; (2) Python work/probe_bika_v6.py: bika02_00 == 00d0.bin at 99.75% identical bytes with same monster ids — the SAME encounter, just extracted 32 bytes smaller; (3) C# RuntimeTools/Aurora3DLinkLab (build+run exit 0): bika02_00 -> 0e/00D0.bin via=SIMILARIDADE, other probes intact (azit03_00 exact, sfia00_00 honestly SEM MATCH).
Gates: build 0 errors (editor + lab). Not committed (multi-lane dirty worktree + in-game RT2 pending), per lane rule. The 0e/ override still keeps its .aurora3d.bak backup.

v2.234.0.1