JARVIS-MAGIC

Atualização 2.124

16/06/2026

v2.124.0.0MINORJarvis-MAGIC

Item Stack Cap 99→255: novo `ItemStackCapHook` no `FfxHooksDll` (capacidade nova, gated por flag)

(capacidade nova: novo hook em runtime + writer-like patch que destrava cap de stack alem do limite vanilla; primeira vez que tocamos FFX_Inventory_AddItem). A descoberta (provada via idalib MCP em FFX_recon.i64 2026-06-16): o limite de 99 itens por slot e clamp central em UMA funcao no FFX.exe — FFX_Inventory_AddItem@0x003905A0 (IDA flat 0x7905A0) — com DOIS push 63h alimentando o helper generico FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. Os 14 callers (steal/drop/mix/shop/treasure/event/menu) TODOS funilizam por essa unica funcao — nao ha copy-paste de clamp em outros paths. Sem normalizacao no load (provado em FFX_Btl_PrepareSaveCommandState@0x786BC0: so inicializa slots vazios, nao reclama counts existentes). Storage (1 byte em QuantityBase+slot no save + byte[112] em RAM em 0xD30B5C) ja suporta 0..255 sem realocacao. Strategy escolhida: byte-narrow patch NAO alcanca 255 (push imm8 6A FF seria sign-extended pra -1) → detour 5-byte com trampoline + stub por sitio (igual molde NovaSuperDamageHook). Cada stub: push imm32 <cap> substitui o push 63h, replays os 2..3 bytes deslocados, retorna via jmp rel32 pra 0x00390622/0x00390652. Cap configuravel via FFXHOOKS_ITEM_STACK_CAP env (default 255, clampado 1..255). Gating: item_stack_cap_255.flag (off por default = comportamento vanilla preservado, regression test natural). Bytes sentinel verificados antes do patch: kExpectedNew[5] = {6A 63 6A 00 53} (site #1 / novo slot) e kExpectedExist[5] = {6A 63 8D 04 1E} (site #2 / slot existente). Rollback automatico se a 2a escrita falhar (nao deixa half-installed). Build PolyHook PASS (11/11 cpp incluindo o novo ItemStackCapHook.cpp), DLL Release deployada (932352→935936 bytes, +3584 do novo hook). Renames+comentarios .i64 aplicados (REGRA DE OURO IDA): 0x7905A0→FFX_Inventory_AddItem, 0x79A0D0→FFX_Math_ClampInt, 0x790500→FFX_Inventory_GetItemCount, 0x784A90→FFX_Inventory_DebugMaxAll, g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, comentarios em 0x79061D/0x79064D (clamp sites com receita do trampoline). Veredito UI (do spike): safe-above-99-provavel (getter retorna byte raw, sem reclamp; risco visual = layout 2-digit pode overflowar em "100"+, mas formatter %d aceita 3 digitos sem crash). Phase 3 UI patch nao aplicado proativamente — RT2 confirma. Phase 4 RT2 receita de 6 cenarios (save-edit Quantity=200, steal/drop, shop buy, mix, use Potion, UI render) em docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 in-game Precisa Testar (Halyson). Doc: docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. Arquivos novos: RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. Arquivos tocados: shared/ffx_addresses.h (10 novos RVAs+constants), dllmain.cpp (include + flag enablers + InstallItemStackCapHook em InstallHooks + RemoveItemStackCapHook), FfxHooksDll.vcxproj, build_hooks.ps1

v2.123.5.1

v2.124.0.1REVISIONJarvis-MAGIC

Ronso Mana (5ª passada RE): teoria "barra cheia" MORTA — o gate real é RESOLUÇÃO DE NÓ DA MENU-TREE (`ResolveMenuTreeNode`), não gauge

(RE/doc + renames/comentários na .i64 real; NENHUMA mudança de comportamento, DLL intocada — a outra sala pode usá-la). O RT2 do hudSafe=24 (v2.123.4.1) FALHOU e o log PROVA por quê a linha de gauge inteira (hudSafe 23/24) estava errada: P0 dispatch #1..#48 charge=100 max=100 em TODOS os 48 frames (o pino persistente funcionou, a barra ficou genuinamente cheia todo frame) + bits 0x590=0x0D + IsOdReady ->1 (até vanilla=1) + 311A no anel — e o OD continuou oculto / "esquerda" bloqueada. ⇒ charge==max NÃO é o gate. (Bônus: o log inunda WARN: OD ring header NOT FOUND in commands 0-49 — ScanForOdRingHeader procura no range errado; o header de OD é cmd282.) O gate REAL (provado por decompile idalib): FFX_Btl_UI_BuildCommandRing@0x7ACEC0 constrói o anel principal (Attack/Skill/Special) via FFX_Btl_UI_BuildMainCommandRingTree@0x7A07D0 só quando kind<=8; o anel Overdrive é kind=12 → PULA 7A07D0 e depende 100% de ResolveMenuTreeNode(2,1,slot+41)>=0 (só então sub_7979E0 finaliza). Para Kimahri (slot 2) = Resolve(2,1,43), que retorna −1. A causa exata está em FFX_Btl_UI_WalkMenuBlobIndex@0x797420: idx=blob[2+treeId]; cnt=blob[1]; if(idx==0xFF || treeId>=cnt) return 0 → LookupMenuBlob=0 → Resolve=−1 → anel OD nunca exibe. Mapeamento das duas vias: principal=Resolve(2,**0**,slot+109) no blob g_FFX_MenuTreeBlob_MainRing (*0x112A994) — resolve OK (user vê); OD=Resolve(2,**1**,slot+41) no blob g_FFX_MenuTreeBlob_OdRing (*0x112A9B4) — Kimahri testa blob[45]. Ambos blobs são DADO ESTÁTICO do recurso system_01 (via FFX_Btl_UI_InitMenuBlobPointers@0x783ED0: blob = base + *(base+N)), idênticos com/sem OD → blob[2+treeId] é índice de nó, não bool (por isso o hudSafe=19 errou a semântica). Nada disso lê 0x5BC/0x5BD (charge/max). Renames+comentários .i64 aplicados e salvos (REGRA DE OURO): 0x112A9B4→g_FFX_MenuTreeBlob_OdRing, 0x112A994→g_FFX_MenuTreeBlob_MainRing, 0x112A9A8→g_FFX_MenuBlobBase_system01 + comentários em 0x797420(fórmula do gate), 0x7985A0, 0x7ACEC0, 0x7A07D0, 0x783ED0. EXPERIMENTO DECISIVO (próximo, precisa de 1 sessão DLL): DIAG no detour de ResolveMenuTreeNode quando a1==2&&a2==1 logando treeId, blobPtr=*0x112A9B4, cnt=blob[1], idx=blob[2+treeId], retorno do vanilla — em 2 cenários (save-edit OD-cheio comprovado vs nosso forçado) e diffar os idx/cnt → revela o valor exato pro fix (escrever blob[45] válido, ou redirecionar o treeId, ou popular o case 3 per-ator actor+0xF7C). Recomendação: reverter/neutralizar o pino de gauge do hudSafe=24 (não é o caminho), mantendo só gateMin/drainCost (consumo já confirmado certo). Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §11

v2.124.0.0

v2.124.0.2REVISIONJarvis-MAGIC

Build+deploy da `ffx-hooks.dll` (DLL liberada): materializa o fix menu-bound do Nul Ward + arma flags Nul Ward e Item Stack Cap pro RT2; preflight offline GREEN

(operacional: rebuild+deploy de código já versionado + criação de flags; nenhum comportamento de código-fonte NOVO nesta passada — o fix menu-bound é do v2.123.4.0, o encoding LearnedMove do editor é do seu próprio entry). Halyson liberou a DLL (a lane Ronso Mana terminou de usá-la). Ações: (1) build_hooks.ps1 -WithPolyHook -Release → 10/10 hooks compilados, incluindo NulWardTeachHook.cpp com o fix multi-site (cmp r32,140h/cmp eax,140h→322, patcha TODOS os sites incl. o loop de PLACEMENT 81 FF=edi) que antes só estava codado; (2) deploy via install_to_modules.ps1 -EnableApply -EnableTeach — backup do DLL anterior (ffx-hooks.dll.backup-nul-ward-20260616-071450), novo SHA-prefix 95E1D56A8B9269F7, flags nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) a pedido de outra lane, criada modules/item_stack_cap_255.flag (vazia) → arma o ItemStackCapHook (cap de stack 99→255; hook autoria da outra lane, já compilado no DLL compartilhado, default FFX_ITEM_STACK_CAP_EXTENDED=255). Gate --nul-ward-static agora VERDICT: PASS (exe bytes + 322 rows + engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + DLL strings + deploy flags + nova clear). RT2 in-game liberado (Nul Ward: castar 320/321 não-vira-Attack já provado offline, falta surfacing no menu branco + ensino via grid + persist; Item Stack Cap: 6 cenários do doc §8 — stack 100 Potions, Steal/Drop/Mix/Shop/Treasure, regression flag-off). Docs: FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16, FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 §8

v2.124.0.1

Voltar para atualizações

JARVIS-MAGIC

Atualização 2.124

16/06/2026

v2.124.0.0MINORJarvis-MAGIC

Item Stack Cap 99→255: novo `ItemStackCapHook` no `FfxHooksDll` (capacidade nova, gated por flag)

(capacidade nova: novo hook em runtime + writer-like patch que destrava cap de stack alem do limite vanilla; primeira vez que tocamos FFX_Inventory_AddItem). A descoberta (provada via idalib MCP em FFX_recon.i64 2026-06-16): o limite de 99 itens por slot e clamp central em UMA funcao no FFX.exe — FFX_Inventory_AddItem@0x003905A0 (IDA flat 0x7905A0) — com DOIS push 63h alimentando o helper generico FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. Os 14 callers (steal/drop/mix/shop/treasure/event/menu) TODOS funilizam por essa unica funcao — nao ha copy-paste de clamp em outros paths. Sem normalizacao no load (provado em FFX_Btl_PrepareSaveCommandState@0x786BC0: so inicializa slots vazios, nao reclama counts existentes). Storage (1 byte em QuantityBase+slot no save + byte[112] em RAM em 0xD30B5C) ja suporta 0..255 sem realocacao. Strategy escolhida: byte-narrow patch NAO alcanca 255 (push imm8 6A FF seria sign-extended pra -1) → detour 5-byte com trampoline + stub por sitio (igual molde NovaSuperDamageHook). Cada stub: push imm32 <cap> substitui o push 63h, replays os 2..3 bytes deslocados, retorna via jmp rel32 pra 0x00390622/0x00390652. Cap configuravel via FFXHOOKS_ITEM_STACK_CAP env (default 255, clampado 1..255). Gating: item_stack_cap_255.flag (off por default = comportamento vanilla preservado, regression test natural). Bytes sentinel verificados antes do patch: kExpectedNew[5] = {6A 63 6A 00 53} (site #1 / novo slot) e kExpectedExist[5] = {6A 63 8D 04 1E} (site #2 / slot existente). Rollback automatico se a 2a escrita falhar (nao deixa half-installed). Build PolyHook PASS (11/11 cpp incluindo o novo ItemStackCapHook.cpp), DLL Release deployada (932352→935936 bytes, +3584 do novo hook). Renames+comentarios .i64 aplicados (REGRA DE OURO IDA): 0x7905A0→FFX_Inventory_AddItem, 0x79A0D0→FFX_Math_ClampInt, 0x790500→FFX_Inventory_GetItemCount, 0x784A90→FFX_Inventory_DebugMaxAll, g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, comentarios em 0x79061D/0x79064D (clamp sites com receita do trampoline). Veredito UI (do spike): safe-above-99-provavel (getter retorna byte raw, sem reclamp; risco visual = layout 2-digit pode overflowar em "100"+, mas formatter %d aceita 3 digitos sem crash). Phase 3 UI patch nao aplicado proativamente — RT2 confirma. Phase 4 RT2 receita de 6 cenarios (save-edit Quantity=200, steal/drop, shop buy, mix, use Potion, UI render) em docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 in-game Precisa Testar (Halyson). Doc: docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. Arquivos novos: RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. Arquivos tocados: shared/ffx_addresses.h (10 novos RVAs+constants), dllmain.cpp (include + flag enablers + InstallItemStackCapHook em InstallHooks + RemoveItemStackCapHook), FfxHooksDll.vcxproj, build_hooks.ps1

v2.123.5.1

v2.124.0.1REVISIONJarvis-MAGIC

Ronso Mana (5ª passada RE): teoria "barra cheia" MORTA — o gate real é RESOLUÇÃO DE NÓ DA MENU-TREE (`ResolveMenuTreeNode`), não gauge

(RE/doc + renames/comentários na .i64 real; NENHUMA mudança de comportamento, DLL intocada — a outra sala pode usá-la). O RT2 do hudSafe=24 (v2.123.4.1) FALHOU e o log PROVA por quê a linha de gauge inteira (hudSafe 23/24) estava errada: P0 dispatch #1..#48 charge=100 max=100 em TODOS os 48 frames (o pino persistente funcionou, a barra ficou genuinamente cheia todo frame) + bits 0x590=0x0D + IsOdReady ->1 (até vanilla=1) + 311A no anel — e o OD continuou oculto / "esquerda" bloqueada. ⇒ charge==max NÃO é o gate. (Bônus: o log inunda WARN: OD ring header NOT FOUND in commands 0-49 — ScanForOdRingHeader procura no range errado; o header de OD é cmd282.) O gate REAL (provado por decompile idalib): FFX_Btl_UI_BuildCommandRing@0x7ACEC0 constrói o anel principal (Attack/Skill/Special) via FFX_Btl_UI_BuildMainCommandRingTree@0x7A07D0 só quando kind<=8; o anel Overdrive é kind=12 → PULA 7A07D0 e depende 100% de ResolveMenuTreeNode(2,1,slot+41)>=0 (só então sub_7979E0 finaliza). Para Kimahri (slot 2) = Resolve(2,1,43), que retorna −1. A causa exata está em FFX_Btl_UI_WalkMenuBlobIndex@0x797420: idx=blob[2+treeId]; cnt=blob[1]; if(idx==0xFF || treeId>=cnt) return 0 → LookupMenuBlob=0 → Resolve=−1 → anel OD nunca exibe. Mapeamento das duas vias: principal=Resolve(2,**0**,slot+109) no blob g_FFX_MenuTreeBlob_MainRing (*0x112A994) — resolve OK (user vê); OD=Resolve(2,**1**,slot+41) no blob g_FFX_MenuTreeBlob_OdRing (*0x112A9B4) — Kimahri testa blob[45]. Ambos blobs são DADO ESTÁTICO do recurso system_01 (via FFX_Btl_UI_InitMenuBlobPointers@0x783ED0: blob = base + *(base+N)), idênticos com/sem OD → blob[2+treeId] é índice de nó, não bool (por isso o hudSafe=19 errou a semântica). Nada disso lê 0x5BC/0x5BD (charge/max). Renames+comentários .i64 aplicados e salvos (REGRA DE OURO): 0x112A9B4→g_FFX_MenuTreeBlob_OdRing, 0x112A994→g_FFX_MenuTreeBlob_MainRing, 0x112A9A8→g_FFX_MenuBlobBase_system01 + comentários em 0x797420(fórmula do gate), 0x7985A0, 0x7ACEC0, 0x7A07D0, 0x783ED0. EXPERIMENTO DECISIVO (próximo, precisa de 1 sessão DLL): DIAG no detour de ResolveMenuTreeNode quando a1==2&&a2==1 logando treeId, blobPtr=*0x112A9B4, cnt=blob[1], idx=blob[2+treeId], retorno do vanilla — em 2 cenários (save-edit OD-cheio comprovado vs nosso forçado) e diffar os idx/cnt → revela o valor exato pro fix (escrever blob[45] válido, ou redirecionar o treeId, ou popular o case 3 per-ator actor+0xF7C). Recomendação: reverter/neutralizar o pino de gauge do hudSafe=24 (não é o caminho), mantendo só gateMin/drainCost (consumo já confirmado certo). Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §11

v2.124.0.0

v2.124.0.2REVISIONJarvis-MAGIC

Build+deploy da `ffx-hooks.dll` (DLL liberada): materializa o fix menu-bound do Nul Ward + arma flags Nul Ward e Item Stack Cap pro RT2; preflight offline GREEN

(operacional: rebuild+deploy de código já versionado + criação de flags; nenhum comportamento de código-fonte NOVO nesta passada — o fix menu-bound é do v2.123.4.0, o encoding LearnedMove do editor é do seu próprio entry). Halyson liberou a DLL (a lane Ronso Mana terminou de usá-la). Ações: (1) build_hooks.ps1 -WithPolyHook -Release → 10/10 hooks compilados, incluindo NulWardTeachHook.cpp com o fix multi-site (cmp r32,140h/cmp eax,140h→322, patcha TODOS os sites incl. o loop de PLACEMENT 81 FF=edi) que antes só estava codado; (2) deploy via install_to_modules.ps1 -EnableApply -EnableTeach — backup do DLL anterior (ffx-hooks.dll.backup-nul-ward-20260616-071450), novo SHA-prefix 95E1D56A8B9269F7, flags nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) a pedido de outra lane, criada modules/item_stack_cap_255.flag (vazia) → arma o ItemStackCapHook (cap de stack 99→255; hook autoria da outra lane, já compilado no DLL compartilhado, default FFX_ITEM_STACK_CAP_EXTENDED=255). Gate --nul-ward-static agora VERDICT: PASS (exe bytes + 322 rows + engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + DLL strings + deploy flags + nova clear). RT2 in-game liberado (Nul Ward: castar 320/321 não-vira-Attack já provado offline, falta surfacing no menu branco + ensino via grid + persist; Item Stack Cap: 6 cenários do doc §8 — stack 100 Potions, Steal/Drop/Mix/Shop/Treasure, regression flag-off). Docs: FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16, FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 §8

v2.124.0.1