JARVIS-ARENA

Atualização 2.128

16/06/2026

v2.128.0.0MINORJarvis-ARENA

Arena+ Multi Dark Aeon custom-token resolver REDIRECT (Opcao A do spike)

(nova capacidade de DLL: o spike read-only ganhou o caminho de redirect descrito no doc FFX_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER_HOOK_SPIKE.md). O hook ResolverLogHook agora tem 2 modos: (a) LOGGER — comportamento anterior, default; (b) REDIRECT — opt-in via arena_plus_custom_token_resolver.flag (env: FFXHOOKS_ENABLE_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER). No modo redirect, ANTES de chamar o trampoline vanilla, o shim consulta uma tabela customToken -> aliasToken (range obrigatorio HIWORD 0xA001..0xAFFF); se houver match, o token e substituido pelo alias vanilla, fazendo o resolver devolver um row legitimo. Downstream nao distingue de um token vanilla; reversao = remover flag ou DLL. Novas APIs no header hooks/ResolverLogHook.h: SetCustomTokenRedirects(table, count) (cap 32, valida range), SetCustomTokenRedirectEnabled(bool), IsCustomTokenRedirectEnabled(), ResolverRedirectHitCount(). Novo sidecar mods/Spira Reforge/arena/spira-arena-custom-tokens.{json,schema.json} populado com 4 entries (duo 0xA0010046->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)

v2.127.0.0

v2.128.0.1REVISIONJarvis-MAGIC

Ronso Mana (6ª passada RE): RUNTIME FECHADO — o `−1` do OD do Kimahri reduz a `WalkMenuBlobIndex(blob2,43)==0`; gauge/OD-ready DESCARTADOS de vez (log RT2 do `hudSafe=24` prova)

(RE/doc + comentários na .i64 real; NENHUMA mudança de comportamento, DLL intocada — a outra sala continua usando). Li o log RT2 do hudSafe=24 (%TEMP%\ffx-hooks.log) que o próprio detour B0-resolve já capturava — fecha a cadeia causal do bug #1. Evidência: B0 resolve a1=2 a2=1 treeId=43 a4=1 ->-1 (em ringKind=1 E ringKind=12) com P0 dispatch charge=100 max=100 590=0x0D (OD-ready FORÇADO: o hook já seta bits 0x590, 79AF70 retorna 1, 6C8, e pina max:=charge) — e o OD continuou oculto. ⇒ OD-ready/charge==max NÃO é o gate (encerra hudSafe 17–24). Ainda: blob2=0x1B5C8D70 = ponteiro de HEAP VIVO (não o system_00 vazio do offline) → o gate é o índice do blob, dado de runtime. BREAKTHROUGH estrutural (aritmética de símbolos, sem runtime): dword_1134564[N] ≡ unk_C8F8D0[N+1217317] ((0x1134564−0xC8F8D0)/4=1217317 exato) ⇒ dword_1134564[0] (count que o Resolve lê) É o count que o PushMenuTreeEntry(797B80) incrementa, e dword_1134564[2*v8+1537] É a entrada empurrada → o Push alimenta exatamente o loop de node-def do ResolveMenuTreeNode(797D60); case 2 subtype=1 → unk_112A994[8]=0x112A9B4=blob2. Logo o −1 reduz a WalkMenuBlobIndex(blob2,43)==0 ⇒ blob2[2+43]==0xFF (treeId 43 não registrado) OU 43>=blob2[1] (count≤43). Como kind=1 (sel=1) E kind=12 (sel=12) AMBOS deram −1, é o GATE PRIMÁRIO (não o seletor secundário). 79BB70 (BuildActorCommandMenu) decompilado e DESCARTADO como writer do gate: ele monta só o ring buffer layer-A (ringBase+1144*slot+catOffset, roteamento byte24 1→+120/2→+72/3→+168/4→+296/0xE→+232; header dword28 &0x1000→+40/&0x800→+56/senão→+0), não escreve o blob de resolução nem actor+0xF7C. Falta 1 medição (blob2[1] count + blob2[2+43] idx) — deixei o patch DIAG turnkey (≤6 linhas, read-only) pronto pra colar no shim B0-resolve em §12.4 do doc, com os 3 candidatos de fix afinados (B=escrever blob2[2+43], C=redirect pro caminho a2=0 como os Aeons, A=sintetizar o nó) decididos pelo dump em 1 RT2. Comentários .i64 (REGRA DE OURO, salvos): 0x797D60/0x797B80/0x797420/0x7985A0/0x112A9B4. Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §12

v2.128.0.0

Voltar para atualizações

JARVIS-ARENA

Atualização 2.128

16/06/2026

v2.128.0.0MINORJarvis-ARENA

Arena+ Multi Dark Aeon custom-token resolver REDIRECT (Opcao A do spike)

(nova capacidade de DLL: o spike read-only ganhou o caminho de redirect descrito no doc FFX_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER_HOOK_SPIKE.md). O hook ResolverLogHook agora tem 2 modos: (a) LOGGER — comportamento anterior, default; (b) REDIRECT — opt-in via arena_plus_custom_token_resolver.flag (env: FFXHOOKS_ENABLE_ARENA_PLUS_CUSTOM_TOKEN_RESOLVER). No modo redirect, ANTES de chamar o trampoline vanilla, o shim consulta uma tabela customToken -> aliasToken (range obrigatorio HIWORD 0xA001..0xAFFF); se houver match, o token e substituido pelo alias vanilla, fazendo o resolver devolver um row legitimo. Downstream nao distingue de um token vanilla; reversao = remover flag ou DLL. Novas APIs no header hooks/ResolverLogHook.h: SetCustomTokenRedirects(table, count) (cap 32, valida range), SetCustomTokenRedirectEnabled(bool), IsCustomTokenRedirectEnabled(), ResolverRedirectHitCount(). Novo sidecar mods/Spira Reforge/arena/spira-arena-custom-tokens.{json,schema.json} populado com 4 entries (duo 0xA0010046->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)

v2.127.0.0

v2.128.0.1REVISIONJarvis-MAGIC

Ronso Mana (6ª passada RE): RUNTIME FECHADO — o `−1` do OD do Kimahri reduz a `WalkMenuBlobIndex(blob2,43)==0`; gauge/OD-ready DESCARTADOS de vez (log RT2 do `hudSafe=24` prova)

(RE/doc + comentários na .i64 real; NENHUMA mudança de comportamento, DLL intocada — a outra sala continua usando). Li o log RT2 do hudSafe=24 (%TEMP%\ffx-hooks.log) que o próprio detour B0-resolve já capturava — fecha a cadeia causal do bug #1. Evidência: B0 resolve a1=2 a2=1 treeId=43 a4=1 ->-1 (em ringKind=1 E ringKind=12) com P0 dispatch charge=100 max=100 590=0x0D (OD-ready FORÇADO: o hook já seta bits 0x590, 79AF70 retorna 1, 6C8, e pina max:=charge) — e o OD continuou oculto. ⇒ OD-ready/charge==max NÃO é o gate (encerra hudSafe 17–24). Ainda: blob2=0x1B5C8D70 = ponteiro de HEAP VIVO (não o system_00 vazio do offline) → o gate é o índice do blob, dado de runtime. BREAKTHROUGH estrutural (aritmética de símbolos, sem runtime): dword_1134564[N] ≡ unk_C8F8D0[N+1217317] ((0x1134564−0xC8F8D0)/4=1217317 exato) ⇒ dword_1134564[0] (count que o Resolve lê) É o count que o PushMenuTreeEntry(797B80) incrementa, e dword_1134564[2*v8+1537] É a entrada empurrada → o Push alimenta exatamente o loop de node-def do ResolveMenuTreeNode(797D60); case 2 subtype=1 → unk_112A994[8]=0x112A9B4=blob2. Logo o −1 reduz a WalkMenuBlobIndex(blob2,43)==0 ⇒ blob2[2+43]==0xFF (treeId 43 não registrado) OU 43>=blob2[1] (count≤43). Como kind=1 (sel=1) E kind=12 (sel=12) AMBOS deram −1, é o GATE PRIMÁRIO (não o seletor secundário). 79BB70 (BuildActorCommandMenu) decompilado e DESCARTADO como writer do gate: ele monta só o ring buffer layer-A (ringBase+1144*slot+catOffset, roteamento byte24 1→+120/2→+72/3→+168/4→+296/0xE→+232; header dword28 &0x1000→+40/&0x800→+56/senão→+0), não escreve o blob de resolução nem actor+0xF7C. Falta 1 medição (blob2[1] count + blob2[2+43] idx) — deixei o patch DIAG turnkey (≤6 linhas, read-only) pronto pra colar no shim B0-resolve em §12.4 do doc, com os 3 candidatos de fix afinados (B=escrever blob2[2+43], C=redirect pro caminho a2=0 como os Aeons, A=sintetizar o nó) decididos pelo dump em 1 RT2. Comentários .i64 (REGRA DE OURO, salvos): 0x797D60/0x797B80/0x797420/0x7985A0/0x112A9B4. Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §12

v2.128.0.0