SeymourBETA

Mise à jour 2.234

18/08/2026

v2.234.0.0BETAMINOR

Seymour18 août 2026

Modèles HD de monstres persistants dans Aurora : 340 cuissons `.chr`→glTF (mesh Phyre HD + squelette PS2 + mouvement `.mgrp`) texturées/animées, Y-up, commitées + chemin persistant relatif au dépôt

Régénération des cuissons (pipeline phyre_chr_gate récupéré du commit a731de5f) : 340/341 monstres avec vrai mesh, 328 texturés, 237 avec animations PS2 (18–25 clips r0g0_..), 340 Y-up (--flip-y = rotation du nœud flip_root [1,0,0,0] = 180° X). Seul m999 (slot factice de test, pas de mesh) sauté.
Persistance (demandée pour que les utilisateurs finaux voient monstres+textures) : les ~892 Mo d'actifs sortis de work/ (gitignoré) vers RuntimeTools/FFXModelAssets/chr/<id>/ (commités). Aucun nouveau préfixe : l'EditViewer Aurora est servi par python -m http.server À LA RACINE DU DÉPÔT (python ne fait pas de mapping de préfixe) -> le chemin d'ancre est RELATIF AU DÉPÔT.
Chemin d'ancre dans l'éditeur : AuroraChamber_DataModel émet désormais /RuntimeTools/FFXModelAssets/chr/m{id:D3}/m{id:D3}_animated.gltf (était /work/phyre_chr_anim/models/...). Exige un rebuild de l'éditeur ; recharger l'EditViewer pour voir les ennemis comme des modèles (plus des sphères).
Catalogue : RuntimeTools/FFXModelAssets/catalog.json (340 entrées, drapeaux animé/texturé).
Outillage : le runner régénérable work/phyre_chr_anim/BakeBatch.ps1 + l'outil récupéré work/phyre_chr_gate_build/ restent dans work/ (gitignoré) ; les ACTIFS (résultat) sont commités.
Honnête (limites de la voie-HD) : la texture est le .dds.phyre primaire ; ~12 monstres non texturés par design (pas de tex/ dans le manifeste) ; T-pose pour ceux sans mouvement propre (237/340 animés) ; torsion résiduelle possible dans le bind hors ligne (A1/frame0/matrixParents déjà appliqués — juger à l'écran). AuroraFieldExplorer_ChrModelResolver reste sur /work/ (catégorie séparée npc/pc/sum/obj/wep, hors périmètre).
Réconciliation de bump : le bump PATCH v2.233.1.0 (autre voie, csproj disputé) subsumé dans le MINOR 2.234.0.0 ; entrées dans CHANGELOG/changelogUS/VERSIONING.
Portes : build éditeur 0 erreurs (455 avertissements préexistants) ; StringsIntegrityTests 3/3 (non affectés). Validation visuelle RT2 en attente (rebuild + re-rendu manuel).

v2.233.1.0

v2.234.0.1BETAPATCH

Seymour18 août 2026

Correctif d'encodage + crash au chargement de projet : `FfxEncoding.us.cs` régénéré depuis la baseline (UTF-8+BOM, bons caractères) avec `UsEncoder` dédupliqué (des clés `char` dupliquées faisaient lancer `Dictionary<char,byte>` au `ArgumentException` quand `FfxEncoding` était initialisé pendant `KernelMonsterMagicLiveSync` au chargement de projet) ; 279 `.cs` cp1252-ifiés par le script de bannière convertis en UTF-8+BOM (empêche le mojibake de chaînes sous le défaut UTF-8 du SDK-10)

Cause racine du crash : UsEncoder dans FfxEncoding.us.cs avait des clés char dupliquées (bug latent préexistant ; ~192 entrées). Un Dictionary rejette les clés dupliquées → le ctor statique de FfxEncoding lançait à la première utilisation (désormais déclenché par KernelMonsterMagicLiveSync.SyncProject à l'ouverture d'un projet). Correctif : régénérer us.cs depuis la baseline (d91986a1) et dédup first-wins de UsEncoder. La baseline avait déjà 56 clés dupliquées — latentes, exposées seulement maintenant.
Mojibake : le script de bannière a retiré les BOM et cp1252-ifié des fichiers UTF-8 avec octets hauts. 279 .cs convertis en UTF-8+BOM (sans perte) pour que le SDK-10 (lit sans BOM en UTF-8) décode correctement les chaînes.
Portes : build 0 erreurs ; l'éditeur s'ouvre et charge un projet sans crash.

v2.234.0.0

v2.234.1.0BETAPATCH

Yuna18 août 2026

Aurora RealGame : repli de similarité de contenu dans `EncounterIndexBridge` ; débloque Open RealGame pour les batailles sans bin 0e/ byte-identique

Cause racine : Open RealGame « ne s'ouvrait même pas » pour bika02_00 car EncounterIndexBridge.TryResolve exigeait une correspondance SHA-256 byte-identique avec un 0e/<id>.bin. Des 858 batailles vanilla, seulement 614 correspondent par hash à l'extraction BuildBattleUrl de noclip (817 bins) ; 244 restent SEM MATCH → BuildBattleUrl renvoyait null → la fenêtre du visualiseur n'était jamais créée.
Correctif (prouvé depuis 3 sources) : nouveau repli de similarité de blocs de 256 octets (FNV-1a, style rsync) dans EncounterIndexBridge.Build — pour chaque bataille sans SHA exact, choisir le 0e/ avec le plus grand chevauchement de blocs, et si la fraction ≥ MinSimilarityScore (0.50) l'enregistrer dans BattleIdToNearestEncounter, débloquant 191 des 244 non correspondantes. TryResolve/IsSimilarityResolved exposent le repli ; Aurora3DLauncher.BuildBattleUrl rapporte « approx match (similarity) » honnêtement dans le statut.
Preuves : (1) Python work/probe_bika_v5.py : bika02_00 → 00d0.bin score 0,98 (91/93 blocs), global 191/244 débloqués ; (2) Python work/probe_bika_v6.py : bika02_00 == 00d0.bin à 99,75 % d'octets identiques avec les mêmes ids de monstres — le MÊME encounter, juste extrait 32 octets plus petit ; (3) C# RuntimeTools/Aurora3DLinkLab (build+run exit 0) : bika02_00 -> 0e/00D0.bin via=SIMILARIDADE, autres sondes intactes (azit03_00 exact, sfia00_00 honnêtement SEM MATCH).
Portes : build 0 erreurs (éditeur + lab). Non commité (worktree sale multi-voies + RT2 en jeu en attente), selon la règle de voie. L'override 0e/ garde toujours son backup .aurora3d.bak.

v2.234.0.1

Retour aux mises à jour

SeymourBETA

Mise à jour 2.234

18/08/2026

v2.234.0.0BETAMINOR

Seymour18 août 2026

Modèles HD de monstres persistants dans Aurora : 340 cuissons `.chr`→glTF (mesh Phyre HD + squelette PS2 + mouvement `.mgrp`) texturées/animées, Y-up, commitées + chemin persistant relatif au dépôt

Régénération des cuissons (pipeline phyre_chr_gate récupéré du commit a731de5f) : 340/341 monstres avec vrai mesh, 328 texturés, 237 avec animations PS2 (18–25 clips r0g0_..), 340 Y-up (--flip-y = rotation du nœud flip_root [1,0,0,0] = 180° X). Seul m999 (slot factice de test, pas de mesh) sauté.
Persistance (demandée pour que les utilisateurs finaux voient monstres+textures) : les ~892 Mo d'actifs sortis de work/ (gitignoré) vers RuntimeTools/FFXModelAssets/chr/<id>/ (commités). Aucun nouveau préfixe : l'EditViewer Aurora est servi par python -m http.server À LA RACINE DU DÉPÔT (python ne fait pas de mapping de préfixe) -> le chemin d'ancre est RELATIF AU DÉPÔT.
Chemin d'ancre dans l'éditeur : AuroraChamber_DataModel émet désormais /RuntimeTools/FFXModelAssets/chr/m{id:D3}/m{id:D3}_animated.gltf (était /work/phyre_chr_anim/models/...). Exige un rebuild de l'éditeur ; recharger l'EditViewer pour voir les ennemis comme des modèles (plus des sphères).
Catalogue : RuntimeTools/FFXModelAssets/catalog.json (340 entrées, drapeaux animé/texturé).
Outillage : le runner régénérable work/phyre_chr_anim/BakeBatch.ps1 + l'outil récupéré work/phyre_chr_gate_build/ restent dans work/ (gitignoré) ; les ACTIFS (résultat) sont commités.
Honnête (limites de la voie-HD) : la texture est le .dds.phyre primaire ; ~12 monstres non texturés par design (pas de tex/ dans le manifeste) ; T-pose pour ceux sans mouvement propre (237/340 animés) ; torsion résiduelle possible dans le bind hors ligne (A1/frame0/matrixParents déjà appliqués — juger à l'écran). AuroraFieldExplorer_ChrModelResolver reste sur /work/ (catégorie séparée npc/pc/sum/obj/wep, hors périmètre).
Réconciliation de bump : le bump PATCH v2.233.1.0 (autre voie, csproj disputé) subsumé dans le MINOR 2.234.0.0 ; entrées dans CHANGELOG/changelogUS/VERSIONING.
Portes : build éditeur 0 erreurs (455 avertissements préexistants) ; StringsIntegrityTests 3/3 (non affectés). Validation visuelle RT2 en attente (rebuild + re-rendu manuel).

v2.233.1.0

v2.234.0.1BETAPATCH

Seymour18 août 2026

Correctif d'encodage + crash au chargement de projet : `FfxEncoding.us.cs` régénéré depuis la baseline (UTF-8+BOM, bons caractères) avec `UsEncoder` dédupliqué (des clés `char` dupliquées faisaient lancer `Dictionary<char,byte>` au `ArgumentException` quand `FfxEncoding` était initialisé pendant `KernelMonsterMagicLiveSync` au chargement de projet) ; 279 `.cs` cp1252-ifiés par le script de bannière convertis en UTF-8+BOM (empêche le mojibake de chaînes sous le défaut UTF-8 du SDK-10)

Cause racine du crash : UsEncoder dans FfxEncoding.us.cs avait des clés char dupliquées (bug latent préexistant ; ~192 entrées). Un Dictionary rejette les clés dupliquées → le ctor statique de FfxEncoding lançait à la première utilisation (désormais déclenché par KernelMonsterMagicLiveSync.SyncProject à l'ouverture d'un projet). Correctif : régénérer us.cs depuis la baseline (d91986a1) et dédup first-wins de UsEncoder. La baseline avait déjà 56 clés dupliquées — latentes, exposées seulement maintenant.
Mojibake : le script de bannière a retiré les BOM et cp1252-ifié des fichiers UTF-8 avec octets hauts. 279 .cs convertis en UTF-8+BOM (sans perte) pour que le SDK-10 (lit sans BOM en UTF-8) décode correctement les chaînes.
Portes : build 0 erreurs ; l'éditeur s'ouvre et charge un projet sans crash.

v2.234.0.0

v2.234.1.0BETAPATCH

Yuna18 août 2026

Aurora RealGame : repli de similarité de contenu dans `EncounterIndexBridge` ; débloque Open RealGame pour les batailles sans bin 0e/ byte-identique

Cause racine : Open RealGame « ne s'ouvrait même pas » pour bika02_00 car EncounterIndexBridge.TryResolve exigeait une correspondance SHA-256 byte-identique avec un 0e/<id>.bin. Des 858 batailles vanilla, seulement 614 correspondent par hash à l'extraction BuildBattleUrl de noclip (817 bins) ; 244 restent SEM MATCH → BuildBattleUrl renvoyait null → la fenêtre du visualiseur n'était jamais créée.
Correctif (prouvé depuis 3 sources) : nouveau repli de similarité de blocs de 256 octets (FNV-1a, style rsync) dans EncounterIndexBridge.Build — pour chaque bataille sans SHA exact, choisir le 0e/ avec le plus grand chevauchement de blocs, et si la fraction ≥ MinSimilarityScore (0.50) l'enregistrer dans BattleIdToNearestEncounter, débloquant 191 des 244 non correspondantes. TryResolve/IsSimilarityResolved exposent le repli ; Aurora3DLauncher.BuildBattleUrl rapporte « approx match (similarity) » honnêtement dans le statut.
Preuves : (1) Python work/probe_bika_v5.py : bika02_00 → 00d0.bin score 0,98 (91/93 blocs), global 191/244 débloqués ; (2) Python work/probe_bika_v6.py : bika02_00 == 00d0.bin à 99,75 % d'octets identiques avec les mêmes ids de monstres — le MÊME encounter, juste extrait 32 octets plus petit ; (3) C# RuntimeTools/Aurora3DLinkLab (build+run exit 0) : bika02_00 -> 0e/00D0.bin via=SIMILARIDADE, autres sondes intactes (azit03_00 exact, sfia00_00 honnêtement SEM MATCH).
Portes : build 0 erreurs (éditeur + lab). Non commité (worktree sale multi-voies + RT2 en jeu en attente), selon la règle de voie. L'override 0e/ garde toujours son backup .aurora3d.bak.

v2.234.0.1