JARVIS-ARENA

Aggiornamento 2.128

16/06/2026

v2.128.0.0MINORJarvis-ARENA

Risolutore token personalizzato Arena+ Multi Dark Aeon REDIRECT (Opzione A del spike)

(nuova capacità della DLL: il read-only dello spike ha ottenuto il percorso di redirect descritto nel doc FFX_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER_HOOK_SPIKE.md). L'hook ResolverLogHook ora ha 2 modalità: (a) LOGGER — comportamento precedente, predefinita; (b) REDIRECT — opt-in tramite arena_plus_custom_token_resolver.flag (env: FFXHOOKS_ENABLE_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER). Nella modalità redirect, PRIMA di chiamare il trampoline vanilla, lo shim consulta una tabella customToken -> aliasToken (range obbligatorio HIWORD 0xA001..0xAFFF); se c'è corrispondenza, il token viene sostituito dall'alias vanilla, facendo sì che il risolutore restituisca un row legittimo. Il downstream non distingue da un token vanilla; la reversione = rimuovere la flag o la DLL. Nuove API nell'header hooks/ResolverLogHook.h: SetCustomTokenRedirects(table, count) (cap 32, valida il range), SetCustomTokenRedirectEnabled(bool), IsCustomTokenRedirectEnabled(), ResolverRedirectHitCount(). Nuovo sidecar mods/Spira Reforge/arena/spira-arena-custom-tokens.{json,schema.json} popolato con 4 entry (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 (6ª passata RE): RUNTIME CHIUSO — l'`−1` del OD di Kimahri riduce la `WalkMenuBlobIndex(blob2,43)==0`; gauge/OD-ready SCARTATI definitivamente (log RT2 del `hudSafe=24` dimostra)

(RE/doc + commenti nella .i64 reale; NESSUN cambio di comportamento, DLL intatta — l'altra sala continua a usarla). Ho letto il log RT2 del hudSafe=24 (%TEMP%\ffx-hooks.log) che il detour stesso B0-resolve catturava già — chiude la catena causale del bug #1. Prove: B0 resolve a1=2 a2=1 treeId=43 a4=1 ->-1 (in ringKind=1 E ringKind=12) con P0 dispatch charge=100 max=100 590=0x0D (OD-ready FORZATO: l'hook imposta già i bit 0x590, 79AF70 restituisce 1, 6C8, e fissa max:=charge) — e l'OD è rimasto nascosto. ⇒ OD-ready/charge==max NON è il gate (chiude hudSafe 17–24). Inoltre: blob2=0x1B5C8D70 = puntatore di HEAP VIVO (non il system_00 vuoto dell'offline) → il gate è l'indice del blob, dato di runtime. Svolta strutturale (aritmetica dei simboli, senza runtime): dword_1134564[N] ≡ unk_C8F8D0[N+1217317] ((0x1134564−0xC8F8D0)/4=1217317 esatto) ⇒ dword_1134564[0] (count che il Resolve legge) È il count che il PushMenuTreeEntry(797B80) incrementa, e dword_1134564[2*v8+1537] È l'entrata spinta → il Push alimenta esattamente il ciclo di node-def del ResolveMenuTreeNode(797D60); case 2 subtype=1 → unk_112A994[8]=0x112A9B4=blob2. Dunque il −1 riduce la WalkMenuBlobIndex(blob2,43)==0 ⇒ blob2[2+43]==0xFF (t ID ree 43 non registrato) OPURE 43>=blob2[1] (count≤43). Poiché kind=1 (sel=1) E kind=12 (sel=12) ENTRAMBI hanno dato −1, si tratta del GATE PRIMARIO (non del selettore secondario). 79BB70 (BuildActorCommandMenu) decompilato e SCARTATO come writer del gate: costruisce solo il ring buffer layer-A (ringBase+1144*slot+catOffset, routing byte24 1→+120/2→+72/3→+168/4→+296/0xE→+232; header dword28 &0x1000→+40/&0x800→+56/altrimenti→+0), non scrive il blob di risoluzione né actor+0xF7C. Mancano 1 misurazione (blob2[1] count + blob2[2+43] idx) — ho lasciato il patch DIAG pronto all'uso (≤6 righe, read-only) da incollare nello shim B0-resolve alla §12.4 del doc, con i 3 candidati di fix calibrati (B=scrivere blob2[2+43], C=redirigere al percorso a2=0 come gli Aeons, A=sintetizzare il nodo) decisi dal dump in 1 RT2. Commenti .i64 (REGOLA D'ORO, salvati): 0x797D60/0x797B80/0x797420/0x7985A0/0x112A9B4. Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §12. [precedente: v2.128.0.0]

Torna agli aggiornamenti

JARVIS-ARENA

Aggiornamento 2.128

16/06/2026

v2.128.0.0MINORJarvis-ARENA

Risolutore token personalizzato Arena+ Multi Dark Aeon REDIRECT (Opzione A del spike)

(nuova capacità della DLL: il read-only dello spike ha ottenuto il percorso di redirect descritto nel doc FFX_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER_HOOK_SPIKE.md). L'hook ResolverLogHook ora ha 2 modalità: (a) LOGGER — comportamento precedente, predefinita; (b) REDIRECT — opt-in tramite arena_plus_custom_token_resolver.flag (env: FFXHOOKS_ENABLE_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER). Nella modalità redirect, PRIMA di chiamare il trampoline vanilla, lo shim consulta una tabella customToken -> aliasToken (range obbligatorio HIWORD 0xA001..0xAFFF); se c'è corrispondenza, il token viene sostituito dall'alias vanilla, facendo sì che il risolutore restituisca un row legittimo. Il downstream non distingue da un token vanilla; la reversione = rimuovere la flag o la DLL. Nuove API nell'header hooks/ResolverLogHook.h: SetCustomTokenRedirects(table, count) (cap 32, valida il range), SetCustomTokenRedirectEnabled(bool), IsCustomTokenRedirectEnabled(), ResolverRedirectHitCount(). Nuovo sidecar mods/Spira Reforge/arena/spira-arena-custom-tokens.{json,schema.json} popolato con 4 entry (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 (6ª passata RE): RUNTIME CHIUSO — l'`−1` del OD di Kimahri riduce la `WalkMenuBlobIndex(blob2,43)==0`; gauge/OD-ready SCARTATI definitivamente (log RT2 del `hudSafe=24` dimostra)

(RE/doc + commenti nella .i64 reale; NESSUN cambio di comportamento, DLL intatta — l'altra sala continua a usarla). Ho letto il log RT2 del hudSafe=24 (%TEMP%\ffx-hooks.log) che il detour stesso B0-resolve catturava già — chiude la catena causale del bug #1. Prove: B0 resolve a1=2 a2=1 treeId=43 a4=1 ->-1 (in ringKind=1 E ringKind=12) con P0 dispatch charge=100 max=100 590=0x0D (OD-ready FORZATO: l'hook imposta già i bit 0x590, 79AF70 restituisce 1, 6C8, e fissa max:=charge) — e l'OD è rimasto nascosto. ⇒ OD-ready/charge==max NON è il gate (chiude hudSafe 17–24). Inoltre: blob2=0x1B5C8D70 = puntatore di HEAP VIVO (non il system_00 vuoto dell'offline) → il gate è l'indice del blob, dato di runtime. Svolta strutturale (aritmetica dei simboli, senza runtime): dword_1134564[N] ≡ unk_C8F8D0[N+1217317] ((0x1134564−0xC8F8D0)/4=1217317 esatto) ⇒ dword_1134564[0] (count che il Resolve legge) È il count che il PushMenuTreeEntry(797B80) incrementa, e dword_1134564[2*v8+1537] È l'entrata spinta → il Push alimenta esattamente il ciclo di node-def del ResolveMenuTreeNode(797D60); case 2 subtype=1 → unk_112A994[8]=0x112A9B4=blob2. Dunque il −1 riduce la WalkMenuBlobIndex(blob2,43)==0 ⇒ blob2[2+43]==0xFF (t ID ree 43 non registrato) OPURE 43>=blob2[1] (count≤43). Poiché kind=1 (sel=1) E kind=12 (sel=12) ENTRAMBI hanno dato −1, si tratta del GATE PRIMARIO (non del selettore secondario). 79BB70 (BuildActorCommandMenu) decompilato e SCARTATO come writer del gate: costruisce solo il ring buffer layer-A (ringBase+1144*slot+catOffset, routing byte24 1→+120/2→+72/3→+168/4→+296/0xE→+232; header dword28 &0x1000→+40/&0x800→+56/altrimenti→+0), non scrive il blob di risoluzione né actor+0xF7C. Mancano 1 misurazione (blob2[1] count + blob2[2+43] idx) — ho lasciato il patch DIAG pronto all'uso (≤6 righe, read-only) da incollare nello shim B0-resolve alla §12.4 del doc, con i 3 candidati di fix calibrati (B=scrivere blob2[2+43], C=redirigere al percorso a2=0 come gli Aeons, A=sintetizzare il nodo) decisi dal dump in 1 RT2. Commenti .i64 (REGOLA D'ORO, salvati): 0x797D60/0x797B80/0x797420/0x7985A0/0x112A9B4. Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §12. [precedente: v2.128.0.0]