JARVIS-ARENA

Mise à jour 2.128

16/06/2026

v2.128.0.0MINORJarvis-ARENA

Arena+ Multi Dark Aeon : résolveur de jetons personnalisés REDIRECT (Option A du spike)

(nouvelle fonctionnalité de la DLL : le spike en lecture seule dispose désormais du chemin de redirection décrit dans la documentation FFX_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER_HOOK_SPIKE.md). Le hook ResolverLogHook dispose désormais de 2 modes : (a) LOGGER — comportement précédent, par défaut ; (b) REDIRECT — activation via arena_plus_custom_token_resolver.flag (environnement : FFXHOOKS_ENABLE_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER). En mode redirect, AVANT d’appeler le trampoline vanilla, le shim consulte une table customToken -> aliasToken (plage obligatoire HIWORD 0xA001..0xAFFF) ; en cas de correspondance, le token est remplacé par l’alias vanilla, ce qui fait que le résolveur renvoie un row valide. En aval, on ne fait pas la distinction avec un jeton « vanilla » ; inversion = suppression du drapeau ou de la DLL. Nouvelles API dans l'en-tête hooks/ResolverLogHook.h : SetCustomTokenRedirects(table, count) (cap 32, plage valide), SetCustomTokenRedirectEnabled(bool), IsCustomTokenRedirectEnabled(), ResolverRedirectHitCount(). Nouveau sidecar mods/Spira Reforge/arena/spira-arena-custom-tokens.{json,schema.json} contenant 4 entrées (duo 0xA0010 046->0x00DC0046, trio 0xA0020046->0x00DC0046, quartet 0xA0030046->0x01AE0046, penta 0xA0040046->0x01AE0046). Carregamento no boot via ArenaPlus_LoadCustomTokenRedirects() em dllmain.cpp — busca em $FFXHOOKS_ARENAPLUS_CUSTOM_TOKENS_PATH -> <DllDir>/mods/Spira Reforge/arena/spira-arena-custom-tokens.json -> <DllDir>/spira-arena-custom-tokens.json; falha em I/O ou parse mantem o hook em modo logger (zero regressao). Build PolyHook PASS 11/11 cpp. RT2 in-game Precisa Testar (espera ate o launcher gerar token custom; ainda nao foi conectado em UI). [anterior: v2.127.0.0]

v2.128.0.1REVISIONJarvis-MAGIC

Ronso Mana (6e tour RE) : RUNTIME FERMÉ — le `−1` de l'OD de Kimahri réduit le `WalkMenuBlobIndex(blob2,43)==0` ; jauge/OD-ready SUPPRIMÉS définitivement (le log RT2 de `hudSafe=24` le prouve)

(RE/doc + commentaires sur le .i64 réel ; AUCUN changement de comportement, DLL inchangée — l’autre salle continue de l’utiliser). J'ai lu le log RT2 de hudSafe=24 (%TEMP%\ffx-hooks.log) que le détournement B0-resolve lui-même capturait déjà — cela clôt la chaîne causale du bug n° 1. Preuve : B0 resolve a1=2 a2=1 treeId=43 a4=1 ->-1 (dans ringKind=1 ET ringKind=12) avec P0 dispatch charge=100 max=100 590=0x0D (OD-ready FORCÉ : le hook définit déjà les bits 0x590, 79AF70 renvoie 1, 6C8, et bloque max:=charge) — et l’OD est resté masqué. ⇒ OD-ready/charge==max N’EST PAS la porte (clôture de hudSafe 17–24). De plus : blob2=0x1B5C8D70 = pointeur vers le HEAP ACTIF (et non le system_00 vide du mode hors ligne) → la porte est l’index du blob, une donnée d’exécution. PERCÉE structurelle (arithmétique des symboles, sans exécution) : dword_1134564[N] ≡ unk_C8F8D0[N+1217317] ((0x1134564−0xC8F8D0)/4=1217317 exact) ⇒ dword_1134564[0] (compteur que le Resolve lit) C'est le compteur que PushMenuTreeEntry(797B80) incrémente, et dword_1134564[2*v8+1537] C'est l'entrée poussée → le Push alimente exactement la boucle node-def de ResolveMenuTreeNode(797D60) ; case 2 subtype=1 → unk_112A994[8]=0x112A9B4=blob2. Par conséquent, le −1 réduit le WalkMenuBlobIndex(blob2,43)==0 ⇒ blob2[2+43]==0xFF (t reeId 43 non enregistré) OU 43>=blob2[1] (count ≤ 43). Comme kind=1 (sel=1) ET kind=12 (sel=12) ont TOUS DEUX donné −1, il s'agit de la PORTE PRIMAIRE (et non du sélecteur secondaire). 79BB70 (BuildActorCommandMenu) décompilé et ÉCARTÉ en tant qu’écrivain de la porte : il ne monte que la couche de tampon circulaire A (ringBase+1144*slot+catOffset, routage byte24 1→+120/2→+72/3→+168/4→+296/0xE→+232 ; en-tête dword28 &0x1000→+40/&0x800→+56/sinon→+0), ne écrit ni le blob de résolution ni actor+0xF7C. Il manque 1 mesure (blob2[1] count + blob2[2+43] idx) — j’ai préparé le patch DIAG clé en main (≤6 lignes, en lecture seule) prêt à être intégré au shim B0-resolve au §12.4 du document, avec les 3 candidats de correction affinés (B = écrire blob2[2+43], C = rediriger vers le chemin a2=0 comme les Aeons, A = synthétiser le nœud) déterminés par le dump sur 1 RT2. Commentaires .i64 (RÈGLE D'OR, enregistrés) : 0x797D60/0x797B80/0x797420/0x7985A0/0x112A9B4. Doc : docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §12. [précédent : v2.128.0.0]

Retour aux mises à jour

JARVIS-ARENA

Mise à jour 2.128

16/06/2026

v2.128.0.0MINORJarvis-ARENA

Arena+ Multi Dark Aeon : résolveur de jetons personnalisés REDIRECT (Option A du spike)

(nouvelle fonctionnalité de la DLL : le spike en lecture seule dispose désormais du chemin de redirection décrit dans la documentation FFX_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER_HOOK_SPIKE.md). Le hook ResolverLogHook dispose désormais de 2 modes : (a) LOGGER — comportement précédent, par défaut ; (b) REDIRECT — activation via arena_plus_custom_token_resolver.flag (environnement : FFXHOOKS_ENABLE_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER). En mode redirect, AVANT d’appeler le trampoline vanilla, le shim consulte une table customToken -> aliasToken (plage obligatoire HIWORD 0xA001..0xAFFF) ; en cas de correspondance, le token est remplacé par l’alias vanilla, ce qui fait que le résolveur renvoie un row valide. En aval, on ne fait pas la distinction avec un jeton « vanilla » ; inversion = suppression du drapeau ou de la DLL. Nouvelles API dans l'en-tête hooks/ResolverLogHook.h : SetCustomTokenRedirects(table, count) (cap 32, plage valide), SetCustomTokenRedirectEnabled(bool), IsCustomTokenRedirectEnabled(), ResolverRedirectHitCount(). Nouveau sidecar mods/Spira Reforge/arena/spira-arena-custom-tokens.{json,schema.json} contenant 4 entrées (duo 0xA0010 046->0x00DC0046, trio 0xA0020046->0x00DC0046, quartet 0xA0030046->0x01AE0046, penta 0xA0040046->0x01AE0046). Carregamento no boot via ArenaPlus_LoadCustomTokenRedirects() em dllmain.cpp — busca em $FFXHOOKS_ARENAPLUS_CUSTOM_TOKENS_PATH -> <DllDir>/mods/Spira Reforge/arena/spira-arena-custom-tokens.json -> <DllDir>/spira-arena-custom-tokens.json; falha em I/O ou parse mantem o hook em modo logger (zero regressao). Build PolyHook PASS 11/11 cpp. RT2 in-game Precisa Testar (espera ate o launcher gerar token custom; ainda nao foi conectado em UI). [anterior: v2.127.0.0]

v2.128.0.1REVISIONJarvis-MAGIC

Ronso Mana (6e tour RE) : RUNTIME FERMÉ — le `−1` de l'OD de Kimahri réduit le `WalkMenuBlobIndex(blob2,43)==0` ; jauge/OD-ready SUPPRIMÉS définitivement (le log RT2 de `hudSafe=24` le prouve)

(RE/doc + commentaires sur le .i64 réel ; AUCUN changement de comportement, DLL inchangée — l’autre salle continue de l’utiliser). J'ai lu le log RT2 de hudSafe=24 (%TEMP%\ffx-hooks.log) que le détournement B0-resolve lui-même capturait déjà — cela clôt la chaîne causale du bug n° 1. Preuve : B0 resolve a1=2 a2=1 treeId=43 a4=1 ->-1 (dans ringKind=1 ET ringKind=12) avec P0 dispatch charge=100 max=100 590=0x0D (OD-ready FORCÉ : le hook définit déjà les bits 0x590, 79AF70 renvoie 1, 6C8, et bloque max:=charge) — et l’OD est resté masqué. ⇒ OD-ready/charge==max N’EST PAS la porte (clôture de hudSafe 17–24). De plus : blob2=0x1B5C8D70 = pointeur vers le HEAP ACTIF (et non le system_00 vide du mode hors ligne) → la porte est l’index du blob, une donnée d’exécution. PERCÉE structurelle (arithmétique des symboles, sans exécution) : dword_1134564[N] ≡ unk_C8F8D0[N+1217317] ((0x1134564−0xC8F8D0)/4=1217317 exact) ⇒ dword_1134564[0] (compteur que le Resolve lit) C'est le compteur que PushMenuTreeEntry(797B80) incrémente, et dword_1134564[2*v8+1537] C'est l'entrée poussée → le Push alimente exactement la boucle node-def de ResolveMenuTreeNode(797D60) ; case 2 subtype=1 → unk_112A994[8]=0x112A9B4=blob2. Par conséquent, le −1 réduit le WalkMenuBlobIndex(blob2,43)==0 ⇒ blob2[2+43]==0xFF (t reeId 43 non enregistré) OU 43>=blob2[1] (count ≤ 43). Comme kind=1 (sel=1) ET kind=12 (sel=12) ont TOUS DEUX donné −1, il s'agit de la PORTE PRIMAIRE (et non du sélecteur secondaire). 79BB70 (BuildActorCommandMenu) décompilé et ÉCARTÉ en tant qu’écrivain de la porte : il ne monte que la couche de tampon circulaire A (ringBase+1144*slot+catOffset, routage byte24 1→+120/2→+72/3→+168/4→+296/0xE→+232 ; en-tête dword28 &0x1000→+40/&0x800→+56/sinon→+0), ne écrit ni le blob de résolution ni actor+0xF7C. Il manque 1 mesure (blob2[1] count + blob2[2+43] idx) — j’ai préparé le patch DIAG clé en main (≤6 lignes, en lecture seule) prêt à être intégré au shim B0-resolve au §12.4 du document, avec les 3 candidats de correction affinés (B = écrire blob2[2+43], C = rediriger vers le chemin a2=0 comme les Aeons, A = synthétiser le nœud) déterminés par le dump sur 1 RT2. Commentaires .i64 (RÈGLE D'OR, enregistrés) : 0x797D60/0x797B80/0x797420/0x7985A0/0x112A9B4. Doc : docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §12. [précédent : v2.128.0.0]