JARVIS-MAGIC

Aggiornamento 2.124

16/06/2026

v2.124.0.0MINORJarvis-MAGIC

Limite Stack Oggetti 99→255: nuovo `ItemStackCapHook` nel `FfxHooksDll` (nuova capacità, condizionata da flag)

(nuova capacità: nuovo hook a runtime + patch tipo writer che sblocca il limite di stack oltre il limite vanilla; prima volta che modifichiamo FFX_Inventory_AddItem). La scoperta (provata via idalib MCP in FFX_recon.i64 2026-06-16): il limite di 99 oggetti per slot e il clamp centralizzato in UNA funzione nel FFX.exe — FFX_Inventory_AddItem@0x003905A0 (IDA flat 0x7905A0) — con DUE push 63h che alimentano il generico helper FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. I 14 chiamanti (steal/drop/mix/shop/treasure/event/menu) TUTTI confluiscono in questa singola funzione — non c'è copy-paste del clamp in altri percorsi. Nessuna normalizzazione al load (provato in FFX_Btl_PrepareSaveCommandState@0x786BC0: inizializza solo gli slot vuoti, non controlla i count esistenti). L'archiviazione (1 byte in QuantityBase+slot nel save + byte[112] in RAM in 0xD30B5C) supporta già 0..255 senza riallocazione. Strategia scelta: la patch a byte-narrow non raggiunge 255 (push imm8 6A FF verrebbe sign-extended a -1) → detour a 5 byte con trampoline + stub per sito (simile al modello NovaSuperDamageHook). Ogni stub: push imm32 <cap> sostituisce il push 63h, riproduce i 2..3 byte spostati, ritorna via jmp rel32 a 0x00390622/0x00390652. Limite configurabile via FFXHOOKS_ITEM_STACK_CAP env (predefinito 255, clamped 1..255). Gating: item_stack_cap_255.flag (off di default = comportamento vanilla preservato, test di regressione naturale). Byte sentinella verificati prima della patch: kExpectedNew[5] = {6A 63 6A 00 53} (sito #1 / nuovo slot) e kExpectedExist[5] = {6A 63 8D 04 1E} (sito #2 / slot esistente). Rollback automatico se la seconda scrittura fallisce (non lascia mezza installazione). Build PolyHook RIUSCITA (11/11 cpp incluso il nuovo ItemStackCapHook.cpp), DLL Release distribuita (932352→935936 bytes, +3584 del nuovo hook). Rinomine+commenti .i64 applicati (REGOLA D'ORO IDA): 0x7905A0→FFX_Inventory_AddItem, 0x79A0D0→FFX_Math_ClampInt, 0x790500→FFX_Inventory_GetItemCount, 0x784A90→FFX_Inventory_DebugMaxAll, g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, commenti in 0x79061D/0x79064D (siti clamp con ricetta del trampoline). Verdetto UI (dallo spike): safe-above-99-provavel (getter restituisce byte grezzo, senza re-clamp; rischio visuale = layout a 2 cifre può sforare su "100"+, ma il formatter %d accetta 3 cifre senza crash). Phase 3 UI patch non applicata proattivamente — RT2 conferma. Phase 4 ricetta RT2 di 6 scenari (save-edit Quantity=200, steal/drop, shop buy, mix, use Potion, UI render) in docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 in-game Da Testare (Halyson). Doc: docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. File nuovi: RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. File toccati: shared/ffx_addresses.h (10 nuove RVA+constanti), dllmain.cpp (include + flag enabler + InstallItemStackCapHook in InstallHooks + RemoveItemStackCapHook), FfxHooksDll.vcxproj, build_hooks.ps1. [precedente: v2.123.5.1]

v2.124.0.1REVISIONJarvis-MAGIC

Ronso Mana (5ª passata RE): teoria "barra piena" MORTA — il gate reale è RISOLUZIONE NODO MENU-TREE (`ResolveMenuTreeNode`), non gauge

(RE/doc + rinomine/commenti nella .i64 reale; NESSUNA modifica comportamentale, DLL intatta — l'altra sala può usarla). L'RT2 del hudSafe=24 (v2.123.4.1) È FALLITO e il log PROVA PERCHÉ l'intera riga del gauge (hudSafe 23/24) era errata: P0 dispatch #1..#48 carica=100 max=100em **TODOS os 48 frames** (o pino persistente funcionou, a barra ficou genuinamente cheia todo frame) + bits0x590=0x0D+IsOdReady ->1(atévanilla=1) + 311A no anel — **e o OD continuou oculto / "esquerda" bloqueada**. ⇒ **charge==maxNÃO é o gate.** (Bônus: o log inundaATTENZIONE: intestazione anello OD NON TROVATA nei comandi 0-49—ScanForOdRingHeaderprocura no range errado; o header de OD é cmd**282**.) **O gate REAL (provado por decompile idalib):**FFX_Btl_UI_BuildCommandRing@0x7ACEC0constrói o anel **principal** (Attack/Skill/Special) viaFFX_Btl_UI_BuildMainCommandRingTree@0x7A07D0**só quandokind<=8**; o anel **Overdrive é kind=12** → **PULA 7A07D0** e depende 100% de ResolveMenuTreeNode(2,1,slot+41)>=0(só entãosub_7979E0finaliza). 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 blobg_FFX_MenuTreeBlob_MainRing (*0x112A994) — resolve OK (user vê); OD=Resolve(2,1,slot+41)no blobg_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 ohudSafe=19errou a semântica). **Nada disso lê0x5BC/0x5BD(charge/max).** **Renames+comentários.i64aplicados e salvos (REGRA DE OURO):**0x112A9B4→g_FFX_MenuTreeBlob_OdRing, 0x112A994→g_FFX_MenuTreeBlob_MainRing, 0x112A9A8→g_FFX_MenuBlobBase_system01+ comentários em0x797420(fórmula do gate), 0x7985A0, 0x7ACEC0, 0x7A07D0, 0x783ED0. **EXPERIMENTO DECISIVO (próximo, precisa de 1 sessão DLL):** DIAG no detour de ResolveMenuTreeNodequandoa1==2&&a2==1logandotreeId, blobPtr=*0x112A9B4, cnt=blob[1], idx=blob[2+treeId], ritorno del vanilla — in **2 scenari** (save-edit OD pieno comprovato vs il nostro forzato) e **d iffar os idx/cnt** → rivela il valore esatto per il fix (scrivere blob[45]valido, o reindirizzare il treeId, o popolare ilcase 3per-actoractor+0xF7C). **Raccomandazione:** revertire/neutralizzare il pin gauge del hudSafe=24(non è la strada), mantenendo sologateMin/drainCost(consumo già confermato corretto). Doc:docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md§11. [precedente:v2.124.0.0`]

v2.124.0.2REVISIONJarvis-MAGIC

Build+deploy della `ffx-hooks.dll` (DLL rilasciata): materializza il fix del menu-bound Nul Ward + flag armi Nul Ward e Item Stack Cap per RT2; preflight offline GREEN

(operazionale: rebuild+deploy di codice già versionato + creazione di flag; NESSUN comportamento del codice sorgente NUOVO in questo passaggio — il fix menu-bound è di v2.123.4.0, l'encoding LearnedMove dell'editor è dal suo entry). Halyson ha rilasciato la DLL (la lane Ronso Mana ha terminato di usarla). Azioni: (1) build_hooks.ps1 -WithPolyHook -Release → 10/10 hook compilati, incluso NulWardTeachHook.cpp con il fix multi-site (cmp r32,140h/cmp eax,140h→322, patcha TUTTI i siti incl. il loop di PLACEMENT 81 FF=edi) che prima era solo codato; (2) deploy tramite install_to_modules.ps1 -EnableApply -EnableTeach — backup della DLL precedente (ffx-hooks.dll.backup-nul-ward-20260616-071450), nuovo SHA-prefix 95E1D56A8B9269F7, flag nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) a richiesta di un'altra lane, creata modules/item_stack_cap_255.flag (vuota) → arma ItemStackCapHook (cap di stack 99→255; hook di altra lane, già compilato nella DLL condivisa, default FFX_ITEM_STACK_CAP_EXTENDED=255). Gate --nul-ward-static ora VERDETTO: PASS (byte exe + 322 righe + engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + stringhe DLL + flag deploy + nuovo clear). RT2 in-game rilasciato (Nul Ward: lanciare 320/321 non-vira-Attack già provato offline, manca la surfaced nel menu bianco + insegnamento via grid + persistenza; Item Stack Cap: 6 scenari del doc §8 — stack 100 Pozioni, Ruba/Goccia/Mix/Negozio/Tesoro, regression flag-off). Doc: FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16, FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 §8

v2.124.0.1

Torna agli aggiornamenti

JARVIS-MAGIC

Aggiornamento 2.124

16/06/2026

v2.124.0.0MINORJarvis-MAGIC

Limite Stack Oggetti 99→255: nuovo `ItemStackCapHook` nel `FfxHooksDll` (nuova capacità, condizionata da flag)

(nuova capacità: nuovo hook a runtime + patch tipo writer che sblocca il limite di stack oltre il limite vanilla; prima volta che modifichiamo FFX_Inventory_AddItem). La scoperta (provata via idalib MCP in FFX_recon.i64 2026-06-16): il limite di 99 oggetti per slot e il clamp centralizzato in UNA funzione nel FFX.exe — FFX_Inventory_AddItem@0x003905A0 (IDA flat 0x7905A0) — con DUE push 63h che alimentano il generico helper FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. I 14 chiamanti (steal/drop/mix/shop/treasure/event/menu) TUTTI confluiscono in questa singola funzione — non c'è copy-paste del clamp in altri percorsi. Nessuna normalizzazione al load (provato in FFX_Btl_PrepareSaveCommandState@0x786BC0: inizializza solo gli slot vuoti, non controlla i count esistenti). L'archiviazione (1 byte in QuantityBase+slot nel save + byte[112] in RAM in 0xD30B5C) supporta già 0..255 senza riallocazione. Strategia scelta: la patch a byte-narrow non raggiunge 255 (push imm8 6A FF verrebbe sign-extended a -1) → detour a 5 byte con trampoline + stub per sito (simile al modello NovaSuperDamageHook). Ogni stub: push imm32 <cap> sostituisce il push 63h, riproduce i 2..3 byte spostati, ritorna via jmp rel32 a 0x00390622/0x00390652. Limite configurabile via FFXHOOKS_ITEM_STACK_CAP env (predefinito 255, clamped 1..255). Gating: item_stack_cap_255.flag (off di default = comportamento vanilla preservato, test di regressione naturale). Byte sentinella verificati prima della patch: kExpectedNew[5] = {6A 63 6A 00 53} (sito #1 / nuovo slot) e kExpectedExist[5] = {6A 63 8D 04 1E} (sito #2 / slot esistente). Rollback automatico se la seconda scrittura fallisce (non lascia mezza installazione). Build PolyHook RIUSCITA (11/11 cpp incluso il nuovo ItemStackCapHook.cpp), DLL Release distribuita (932352→935936 bytes, +3584 del nuovo hook). Rinomine+commenti .i64 applicati (REGOLA D'ORO IDA): 0x7905A0→FFX_Inventory_AddItem, 0x79A0D0→FFX_Math_ClampInt, 0x790500→FFX_Inventory_GetItemCount, 0x784A90→FFX_Inventory_DebugMaxAll, g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, commenti in 0x79061D/0x79064D (siti clamp con ricetta del trampoline). Verdetto UI (dallo spike): safe-above-99-provavel (getter restituisce byte grezzo, senza re-clamp; rischio visuale = layout a 2 cifre può sforare su "100"+, ma il formatter %d accetta 3 cifre senza crash). Phase 3 UI patch non applicata proattivamente — RT2 conferma. Phase 4 ricetta RT2 di 6 scenari (save-edit Quantity=200, steal/drop, shop buy, mix, use Potion, UI render) in docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 in-game Da Testare (Halyson). Doc: docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. File nuovi: RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. File toccati: shared/ffx_addresses.h (10 nuove RVA+constanti), dllmain.cpp (include + flag enabler + InstallItemStackCapHook in InstallHooks + RemoveItemStackCapHook), FfxHooksDll.vcxproj, build_hooks.ps1. [precedente: v2.123.5.1]

v2.124.0.1REVISIONJarvis-MAGIC

Ronso Mana (5ª passata RE): teoria "barra piena" MORTA — il gate reale è RISOLUZIONE NODO MENU-TREE (`ResolveMenuTreeNode`), non gauge

(RE/doc + rinomine/commenti nella .i64 reale; NESSUNA modifica comportamentale, DLL intatta — l'altra sala può usarla). L'RT2 del hudSafe=24 (v2.123.4.1) È FALLITO e il log PROVA PERCHÉ l'intera riga del gauge (hudSafe 23/24) era errata: P0 dispatch #1..#48 carica=100 max=100em **TODOS os 48 frames** (o pino persistente funcionou, a barra ficou genuinamente cheia todo frame) + bits0x590=0x0D+IsOdReady ->1(atévanilla=1) + 311A no anel — **e o OD continuou oculto / "esquerda" bloqueada**. ⇒ **charge==maxNÃO é o gate.** (Bônus: o log inundaATTENZIONE: intestazione anello OD NON TROVATA nei comandi 0-49—ScanForOdRingHeaderprocura no range errado; o header de OD é cmd**282**.) **O gate REAL (provado por decompile idalib):**FFX_Btl_UI_BuildCommandRing@0x7ACEC0constrói o anel **principal** (Attack/Skill/Special) viaFFX_Btl_UI_BuildMainCommandRingTree@0x7A07D0**só quandokind<=8**; o anel **Overdrive é kind=12** → **PULA 7A07D0** e depende 100% de ResolveMenuTreeNode(2,1,slot+41)>=0(só entãosub_7979E0finaliza). 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 blobg_FFX_MenuTreeBlob_MainRing (*0x112A994) — resolve OK (user vê); OD=Resolve(2,1,slot+41)no blobg_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 ohudSafe=19errou a semântica). **Nada disso lê0x5BC/0x5BD(charge/max).** **Renames+comentários.i64aplicados e salvos (REGRA DE OURO):**0x112A9B4→g_FFX_MenuTreeBlob_OdRing, 0x112A994→g_FFX_MenuTreeBlob_MainRing, 0x112A9A8→g_FFX_MenuBlobBase_system01+ comentários em0x797420(fórmula do gate), 0x7985A0, 0x7ACEC0, 0x7A07D0, 0x783ED0. **EXPERIMENTO DECISIVO (próximo, precisa de 1 sessão DLL):** DIAG no detour de ResolveMenuTreeNodequandoa1==2&&a2==1logandotreeId, blobPtr=*0x112A9B4, cnt=blob[1], idx=blob[2+treeId], ritorno del vanilla — in **2 scenari** (save-edit OD pieno comprovato vs il nostro forzato) e **d iffar os idx/cnt** → rivela il valore esatto per il fix (scrivere blob[45]valido, o reindirizzare il treeId, o popolare ilcase 3per-actoractor+0xF7C). **Raccomandazione:** revertire/neutralizzare il pin gauge del hudSafe=24(non è la strada), mantenendo sologateMin/drainCost(consumo già confermato corretto). Doc:docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md§11. [precedente:v2.124.0.0`]

v2.124.0.2REVISIONJarvis-MAGIC

Build+deploy della `ffx-hooks.dll` (DLL rilasciata): materializza il fix del menu-bound Nul Ward + flag armi Nul Ward e Item Stack Cap per RT2; preflight offline GREEN

(operazionale: rebuild+deploy di codice già versionato + creazione di flag; NESSUN comportamento del codice sorgente NUOVO in questo passaggio — il fix menu-bound è di v2.123.4.0, l'encoding LearnedMove dell'editor è dal suo entry). Halyson ha rilasciato la DLL (la lane Ronso Mana ha terminato di usarla). Azioni: (1) build_hooks.ps1 -WithPolyHook -Release → 10/10 hook compilati, incluso NulWardTeachHook.cpp con il fix multi-site (cmp r32,140h/cmp eax,140h→322, patcha TUTTI i siti incl. il loop di PLACEMENT 81 FF=edi) che prima era solo codato; (2) deploy tramite install_to_modules.ps1 -EnableApply -EnableTeach — backup della DLL precedente (ffx-hooks.dll.backup-nul-ward-20260616-071450), nuovo SHA-prefix 95E1D56A8B9269F7, flag nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) a richiesta di un'altra lane, creata modules/item_stack_cap_255.flag (vuota) → arma ItemStackCapHook (cap di stack 99→255; hook di altra lane, già compilato nella DLL condivisa, default FFX_ITEM_STACK_CAP_EXTENDED=255). Gate --nul-ward-static ora VERDETTO: PASS (byte exe + 322 righe + engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + stringhe DLL + flag deploy + nuovo clear). RT2 in-game rilasciato (Nul Ward: lanciare 320/321 non-vira-Attack già provato offline, manca la surfaced nel menu bianco + insegnamento via grid + persistenza; Item Stack Cap: 6 scenari del doc §8 — stack 100 Pozioni, Ruba/Goccia/Mix/Negozio/Tesoro, regression flag-off). Doc: FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16, FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 §8

v2.124.0.1