Beta Update

Cette archive regroupe les anciennes notes de la phase bêta. Les nouvelles notes sont sur la page des mises à jour.

WakkaBETAMINOR

Mise à jour 2.126

16/06/2026

updatearenaJARVIS-ARENA

Arena+ Multi Dark Aeon : CLI de validateur de catalogue (`--validate`). Voie Jarvis-ARENA. MINOR (nouvelle capacité dans `RuntimeTools/ArenaMultiBossLab` : premier validateur de catalogue v2 hors ligne). Nouveau `RuntimeTools/ArenaMultiBossLab/CatalogValidator.cs` + `--validate [--catalog <path>] [--vanilla-root <btlRoot>]` dans `Program.cs`. 5 vérifications : (1) `format/format_version` ; (2) champs requis par ligne (`token_mode`, `battle_token`, `base_template`, `battle_id`, `raw_monster_ids`, `gil_cost`, `progress_flag`, `rt2_status`, `risk`, `evidence`) ; (3) cohérence d'`unlock_requires` (chaque drapeau doit apparaître comme `progress_flag` sur une autre ligne, y compris `unlock.requires` au niveau échelon) ; (4) regex `0xXXXXXXXX` pour `battle_token`, `0xXXXX` par slot dans `raw_monster_ids` + anti-trou (slot vide avant slot occupé = ERREUR) ; (5) la référence `recipe` pointe vers un fichier existant. Balayage de recettes optionnel via sous-processus de cette même CLI avec `--dry-run` quand `--vanilla-root` est fourni (ré-exécute automatiquement chaque recette dans `./recipes`). Codes de sortie : 0 OK, 4 catalogue incohérent, 5 un dry-run de recette a échoué. Exécution actuelle contre `spira-arena-catalog.json` : PASS 0 erreurs / 0 avertissements sur 13 lignes / 13 drapeaux distincts.

Lire les notes

YunaBETAREVISION

Mise à jour 2.125

16/06/2026

updateauroraJARVIS-AURORA

Finalisation balistica Aurora Phase 1 : sonde `aurora-calib-v2` (CSV/JSON avec résiduel identity/flipZ/yaw180 + height_0x534). Voie Jarvis-AURORA. MINOR (nouvelle capacité : nouveau mode `ffxprobectl` émettant un artefact CSV+JSON avec un nouveau schéma de calibration de résiduel ; première fois qu'on couple `chunk3.monLive` × `actor+0x3B0` × `actor+0x534` dans une sonde structurée). Implémente la Phase 1 du plan Aurora (`.cursor/plans/aurora_balistica.plan.md`). Spec suivie : `docs/reverse/FFX_AURORA_CALIBRATION_PROBE_SPEC_2026-06-15.md` (identité XZ prouvée le 2026-06-05 par IDA ; résiduel Y encore RT2-en-attente). Le mode : `ffxprobectl aurora-calib-v2 [--route <field> <group> <formation>] [--battle <id>] [--out <json>] [--csv <csv>] [--max-slots <N>]` (lecture seule, pas d'instrumentation MMF au-delà de la fenêtre de lecture `Arm(1, ...)` existante). Pour chaque slot `monLive` jusqu'à `min(monCount, max-slots=16)` : lit `chunk3.monLive[s]` depuis `g_FFX_Battle_AreaChunk + ptr@+0x20 + 16s` (XYZW), résout `actor[s] = 0x11334CC + 0xF90s`, lit `actor+0x3B0` (XYZW monde), `actor+0x3C0` (XYZW cache optionnel), `actor+0x534` (float de hauteur). Calcule 3 résiduels : `identity = actor - chunk`, `flipz = actor - (cx,cy,-cz)`, `yaw180 = actor - (-cx,cy,-cz)` avec les composantes `dx/dy/dz` + RMS (plein + XZ-only). Acceptance (correspond à A01) : `identity_rms_xz < 0.5` ET `identity_rms 5 < flipz_rms` ET `identity_rms 5 < yaw180_rms` -> `winner=identity` ; les alternatives ne gagnent que si leur rms<1.0 (improbable post-IDA — émet une alerte « UNEXPECTED — investigate ») ; slot bloqué si tableau d'acteurs invalide / monde non-fini (despawn/animating) — cas `blocked-runtime-state`, PAS `fail`. Sortie : JSON (`work/actor_overlay/aurora_calib_<battle_id>_<utcstamp>.json` par défaut) avec `verdict` consolidé (`identity-confirmed-live` / `ALERT-non-identity-winner` / `blocked-runtime-state` / `partial`) + un tableau `rows` ; CSV parallèle avec 36 colonnes (qpc, battle_id, route field/group/formation, area_chunk_va, actor_array_va, slot, dict_id, chunk_xyzw, actor_xyzw, actor_cache_xyz, height_0x534, identity/flipz/yaw180_dx/dy/dz/rms, identity_rms_xz, winner, reason). Build : `dotnet build RuntimeTools/FfxDinput8Probe/ctl/Ctl.csproj -c Release` PASS (0 erreurs, seulement les avertissements préexistants CS8632/CS0219). Ne touche pas : DLL de sonde (`ffx-probe.dll`), portes hors ligne, FfxHooksDll. Prochaine phase : RT2 calib-v2 avec Halyson sur 4 batailles dorées (`azit03_00`, `bsil05`, `klyt00_00` + un contrôle comme `425/0/0`) — recette dans `docs/reverse/FFX_AURORA_FORCE_BATTLE_CALIBRATION_PROTOCOL_2026-06-15.md`. RT2 Phase 1 = N/A (build de sonde seulement) ; RT2 Phase 2 = bloqué sur l'humain (Halyson).

Lire les notes

LuluBETAREVISION

Mise à jour 2.124

16/06/2026

updatemagic-dllJARVIS-MAGIC

Cap de pile d'items 99→255 : nouveau `ItemStackCapHook` dans `FfxHooksDll` (nouvelle capacité, gardée par drapeau). Voie Jarvis-MAGIC. MINOR (nouvelle capacité : un nouveau hook runtime + patch type-écrivain qui lève le cap de pile par slot au-dessus du vanilla ; première fois qu'on touche `FFX_Inventory_AddItem`). Le constat (prouvé via idalib MCP sur `FFX_recon.i64` 2026-06-16) : la limite d'inventaire de 99 par slot est clampée dans une fonction centrale unique de `FFX.exe` — `FFX_Inventory_AddItem`@`0x003905A0` (IDA flat `0x7905A0`) — via DEUX sites `push 63h` alimentant le helper générique `FFX_Math_ClampInt(v, 0, 99)`@`0x0039A0D0`. Les 14 appelants (steal/drop/mix/shop/treasure/event/menu) passent tous par cette fonction unique — aucun clamp copié-collé ailleurs. Aucune normalisation sauvegarde-chargement (prouvé sur `FFX_Btl_PrepareSaveCommandState`@`0x786BC0` : n'initialise que les slots vides, ne re-clampe pas les comptes existants). Le stockage (1 octet à `QuantityBase+slot` dans la sauvegarde + `byte[112]` en RAM à `0xD30B5C`) supporte déjà 0..255 sans réallocation. Stratégie choisie : un patch étroit en octets ne peut PAS atteindre 255 (le push imm8 `6A FF` serait sign-étendu à -1) → détour trampoline 5 octets + stub de tas par site (même motif que `NovaSuperDamageHook`). Chaque stub : `push imm32 <cap>` remplace le `push 63h` original, rejoue les 2..3 octets déplacés, revient via `jmp rel32` vers `0x00390622`/`0x00390652`. Le cap est configurable via la variable d'env `FFXHOOKS_ITEM_STACK_CAP` (défaut 255, clampée à 1..255). Gating : `item_stack_cap_255.flag` (désactivé par défaut = comportement vanilla préservé, test de régression naturel). Octets sentinelles vérifiés avant le patch : `kExpectedNew[5] = {6A 63 6A 00 53}` (site #1 / nouveau slot) et `kExpectedExist[5] = {6A 63 8D 04 1E}` (site #2 / slot existant). Rollback automatique si l'écriture du second site échoue (pas d'états mi-installés). Build PolyHook PASS (11/11 cpp dont le nouveau `ItemStackCapHook.cpp`), DLL Release déployée (`932352→935936 bytes`, +3584 depuis le nouveau hook). Renames+commentaires `.i64` appliqués (RÈGLE D'OR IDA) : `0x7905A0`→`FFX_Inventory_AddItem`, `0x79A0D0`→`FFX_Math_ClampInt`, `0x790500`→`FFX_Inventory_GetItemCount`, `0x784A90`→`FFX_Inventory_DebugMaxAll`, `g_CmdAggregateAvailArrays`→`g_FFX_InventoryAggregate`, commentaires sur `0x79061D`/`0x79064D` (sites de clamp avec la recette de trampoline). Verdict UI (du spike) : `safe-above-99-likely` (le getter renvoie l'octet brut sans re-clamp ; le risque visuel = le layout à 2 chiffres peut déborder sur « 100 »+ mais le formateur `%d` gère 3 chiffres sans crash). Patch UI Phase 3 non appliqué préventivement — le RT2 confirme. Recette RT2 Phase 4 avec 6 scénarios (édition-sauvegarde Quantity=200, steal/drop, achat shop, mix, usage Potion, rendu UI) dans `docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md` §8. RT2 en jeu Nécessite un Test (Halyson). Doc : `docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md`. Nouveaux fichiers : `RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}`. Fichiers touchés : `shared/ffx_addresses.h` (10 nouvelles RVA+constantes), `dllmain.cpp` (include + enablers de drapeaux + InstallItemStackCapHook dans `InstallHooks` + RemoveItemStackCapHook), `FfxHooksDll.vcxproj`, `build_hooks.ps1`.

Lire les notes

WakkaBETAREVISION

Mise à jour 2.123

16/06/2026

updatearenaJARVIS-ARENA

Arena+ Multi Dark Aeon : sidecar de progression + lecteur/écrivain dans FfxHooksDll. Voie Jarvis-ARENA. MINOR : (a) nouveau sidecar `mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json}` (dossier sec. 15 schéma v1) avec `flags{}` cleared/first_clear_utc/last_clear_utc/clear_count/evidence + `tier_lock_state{}` optionnel (LOCKED/READY/CLEARED) ; clé par `progress_flag` du catalogue (`arena.dark.<slug>`) ; le README documente les règles d'usage et le mapping catalogue<->sidecar. (b) Nouveau module `RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp}` — lecteur/écrivain JSON best-effort (sans dépendances), `ArenaProgress_Initialize/IsRowCleared/RecordCleared` gardés par `arena_plus_progress.flag` (désactivé par défaut), cherche `$FFXHOOKS_ARENAPLUS_PROGRESS_PATH` -> `<DllDir>/mods/Spira Reforge/arena/progress/...` -> repli `<DllDir>/spira-arena-progress.json`. Persistance atomique via `.tmp + MoveFileEx`. L'env `FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2` permet aux devs de semer des drapeaux manuellement pour tester l'UI. (c) `dllmain.cpp` appelle `ArenaProgress_Initialize` dans `InstallHooks` après l'overlay de catalogue. (d) La vraie détection de victoire n'est toujours PAS câblée — gardée comme TODO documenté ; la Fase 6 du plan reconnaît cette scission, et l'API publique `ArenaProgress_RecordCleared(flag, note)` est prête pour un futur consommateur hook `battleEnd`. Build PolyHook PASS 10/10 cpp. RT2 en jeu Nécessite un Test (via `FFXHOOKS_ARENAPLUS_FAKE_CLEAR`).

Lire les notes

WakkaBETAREVISION

Mise à jour 2.122

16/06/2026

updatearenaJARVIS-ARENA

Arena+ Multi Dark Aeon : catalogue v2 + lecteur DLL + spike du résolveur de tokens personnalisés. Voie Jarvis-ARENA. MINOR : (a) `mods/Spira Reforge/arena/spira-arena-catalog.schema.json` passé de v1 à v2 avec `token_mode`/`base_template`/`raw_monster_ids`/`unlock_requires`/`rt2_status`/`risk`/`recipe` par ligne ; (b) `spira-arena-catalog.json` rempli avec 5 échelons (Solo 9 vanilla + Duo + Trio + Quartet + Penta stretch) ; (c) `FfxHooksDll/dllmain.cpp` a gagné `ArenaPlus_LoadCatalogOverlay()` + l'accesseur `ArenaPlus_GetRoute(int)` : quand `arena_plus_catalog.flag` est posé + JSON trouvé, les `battleToken`/`battleId`/labels par slot sont écrasés (le `kArenaPlusBossRoutes[9]` codé en dur gagne toujours en cas d'échec) ; (d) nouveau hook `RuntimeTools/FfxHooksDll/hooks/ResolverLogHook.{h,cpp}` — détour PolyHook en lecture seule sur `FFX_Field_ResolveEncounterToken@0x7828B0` qui journalise (token, résultat, outField, outGroup, outEntry), gardé par `arena_plus_resolver_log.flag` ; (e) doc RE `docs/reverse/FFX_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER_HOOK_SPIKE.md` avec décompilation annotée (HIWORD = clé de champ, octet bas du LOWORD = clé d'entrée, octet du milieu = 0), 4 appelants, layout de `g_EncounterFieldTable@0x112A9C8` + `g_EncounterGroupBlobBase@0x112A9CC`, spec de plage de tokens personnalisés `0xA001..0xAFFF`, plan pour l'Option A (redirection pré-résolveur) ; (f) renames + commentaires appliqués au vrai `.i64` (`work/reverse/ida/FFX_recon.i64`) — sub_79D1B0/D1E0/D190/D230 deviennent `FFX_Field_EncounterField/Group` (règle d'or). Build PolyHook PASS 9/9 cpp.

Lire les notes

WakkaBETAREVISION

Mise à jour 2.121

16/06/2026

updatearenaJARVIS-ARENA

Voie d'authoring Arena+ Multi Dark Aeon (ArenaMultiBossLab + recettes multi-alias). Voie Jarvis-ARENA. MINOR : la nouvelle CLI `RuntimeTools/ArenaMultiBossLab` applique les JSON de recettes de façon déterministe — `chunk2` via `FormationSlotWriter` (RT0 slot-only) + `chunk3` via `BattleArenaPositionWriter` (RT0 position-only) ou `BattleArenaGrowWriter` (grow monLive plafonné à 8 acteurs), avec garde de relecture et déploiement loose-file plus backup `.spiraforge.bak`. Recettes actives : `dark_duo_valefor_ifrit` (alias `kino00_70` / token `0x00DC0046`). Doc de recette + modèle de checklist RT2 + README multi-alias sous `mods/Spira Reforge/arena/recipes/`. Stratégie : B (multi-alias) + C (hook de résolveur RE en voie parallèle) + contenu d'abord (duo → trio → quartet avant le catalogue v2 / le lecteur DLL). Dossier de base : `docs/reverse/FFX_ARENA_PLUS_MULTI_DARK_AEON_AUTHORING_DOSSIER_2026-06-16.md`. Plan : `.cursor/plans/arena_plus_multi_dark_aeon_.plan.md`. Déploiement duo généré hors ligne RT0 PASS (7780 octets byte-identiques hors des 16 octets du chunk2 + 48 octets monLive du chunk3) ; le RT2 en jeu Nécessite un Test via `_RT2_CHECKLIST.md`.

Lire les notes

LuluBETAPATCH

Mise à jour 2.120

16/06/2026

updatemagic-dllJARVIS-MAGIC

Outils audio des SFX de bataille empaquetés + versionnés. Voie Jarvis-MAGIC. MINOR : `vgmstream` + `fsbext` dans git sous `tools/` ; copiés à côté du `.exe` au build ; UI Repair audio tools seulement quand absent ; `tools/AUDIO_TOOLS_LICENSES.md`.

Lire les notes

LuluBETAMINOR

Mise à jour 2.119

16/06/2026

updatemagic-dllJARVIS-MAGIC

SFX de bataille personnalisés Phase 2 : nouveau seId sans écrasement. Voie Jarvis-MAGIC. MINOR : `FsbDumpDatAppender` + `Fsb9999SampleAppendWriter` (sous-chanson FSB +1 via dump.dat) ; `FevLegacySequenceWriter` + ligne sidecar `9999_common.txt` ; `CommandSoundPackService.NewSeIdAudio` déploiement triple FEV+FSB+common+DLL ; UI New seId slot de Kernel Commands ; portes `--fsb9999-append-lab`, `--fev9999-sequence-clone-wave9`, `--command-sound-new-seid-pack` ; doc RE I36 ; layout `work/.../wav/` + script de nettoyage. RT2 en jeu en attente.

Lire les notes