JARVIS-MAGIC

更新 2.124

2026/6/16

v2.124.0.0MINORJarvis-MAGIC

物品堆疊上限 99→255：新增`ItemStackCapHook` 在`FfxHooksDll` （新功能，由旗標觸發）

（新功能：運行時新增 hook + 類似寫入器的修補程式，可解除棧容量限制，使其超越原生極限；這是我們首次實作此功能）FFX_Inventory_AddItem). 這項發現（經由 idalib MCP 在FFX_recon.i64 (2026-06-16)：每個插槽限99項，且中央夾具在單一功能中FFX.exe —FFX_Inventory_AddItem@0x003905A0 (IDA 公寓0x7905A0) — 共有 兩push 63h 傳入通用輔助函式參數 **FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. 這 14 個呼叫器（steal/drop/mix/shop/treasure/event/menu）全部都透過這個單一函數進行處理——其他路徑中並未出現 clamp 的複製貼上。載入時不進行歸一化（已於FFX_Btl_PrepareSaveCommandState@0x786BC0：僅初始化空的槽位，不會對現有的計數提出異議）。儲存空間（1 位元組在QuantityBase+slot 在「儲存 +」中byte[112] 在 RAM 中0xD30B5C) 現已支援 0..255，無需重新分配。選用的策略： byte-narrow 修補程式無法達到 255（push imm86A FF 原本應為 -1 的符號延伸 → 透過 trampoline + stub 進行 5 位元組的繞道（如同範本NovaSuperDamageHook). 每個存根：push imm32 <cap> 取代push 63h, 重播偏移的 2..3 位元組，並透過jmp rel32 為了0x00390622/0x00390652. 可透過以下方式設定 Cap：FFXHOOKS_ITEM_STACK_CAP env（預設值 255，限制範圍 1..255）。閘控：item_stack_cap_255.flag （預設為關閉 = 保留原始行為，進行自然回歸測試）。修補程式套用前已驗證的哨兵位元組：kExpectedNew[5] = {6A 63 6A 00 53} (網站 #1 / 新增欄位) 以及kExpectedExist[5] = {6A 63 8D 04 1E} (網站 #2 / 現有槽位)。若第二次寫入失敗，則自動回滾（不要讓它處於半安裝狀態）。PolyHook 編譯通過（11/11 個 C++ 檔案，包含新的ItemStackCapHook.cpp)，已部署的 DLL Release 版本 (932352→935936 bytes, 新掛鉤的 +3584)。重新命名與註解.i64 適用規則（IDA黃金法則）：0x7905A0→FFX_Inventory_AddItem,0x79A0D0→FFX_Math_ClampInt,0x790500→FFX_Inventory_GetItemCount,0x784A90→FFX_Inventory_DebugMaxAll,g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, 留言請至0x79061D/0x79064D （使用 trampoline 配方製作的 clamp sites）。UI 判定（來自 spike）：safe-above-99-provavel (getter 返回原始位元組，未重新限制範圍；視覺風險 = 2 位數的佈局在「100」以上可能發生溢出，但格式化器%d 可接受 3 位數且不會當機）。第 3 階段 UI 修補程式未主動套用 — RT2 已確認。 Phase 4 RT2 包含 6 種情境（存檔編輯 Quantity=200、偷取/掉落、商店購買、混合、使用藥水、UI 渲染）於docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 遊戲內 需測試（Halyson）。文件：docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. 新增檔案：RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. 播放過的檔案：shared/ffx_addresses.h (10 個新的 RVAs+常數)，dllmain.cpp (包含 + 旗標啟用程式 + InstallItemStackCapHook 在InstallHooks + RemoveItemStackCapHook)，FfxHooksDll.vcxproj,build_hooks.ps1. [上一頁：v2.123.5.1]

v2.124.0.1REVISIONJarvis-MAGIC

羅恩索·馬納（上週五 RE）："滿格"理論已不成立 — 真正的關鍵在於解決選單樹的結點（`ResolveMenuTreeNode`)，請勿進行估算

（文件審閱 + 重新命名/註解於.i64 真實；完全沒有行為上的改變，DLL 未被修改 — 另一間房間可以使用它）。RT2 的hudSafe=24 (v2.123.4.1) 發生錯誤，且日誌顯示整個儀表列（hudSafe 23/24）為何出錯： P0 調度 #1..#48 電荷=100 最大值=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 警告：在指令 0-49 中未找到 OD ring 標頭 — 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 → 解＝−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 = 基數 + *(基數+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]，vanilla 的回報 — 在 **2 種情境** 下（經證實的 OD 滿載儲存-編輯 vs 我們的強制情境）以及 **d 區分這些idx/cnt** → 顯示固定值的確切數值（輸入blob[45] 有效，或重新導向 treeId，或填入case 3 每台設備actor+0xF7C). **建議：** 將的量規銷恢復原狀／消除其作用hudSafe=24 （這不是正確的方法），僅保留gateMin/drainCost （用量已確認無誤）。文件：docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §11. [前文：v2.124.0.0`]

v2.124.0.2Jarvis-MAGIC

Build+deploy 來自`ffx-hooks.dll` (已釋放的 DLL)：實作與固定選單綁定的 Nul Ward + 武器標記 Nul Ward 及 RT2 的物品堆疊上限；離線預檢結果為 GREEN

審查（運作層面：已版本化的程式碼重新建置與部署，以及旗標建立；本次無任何新原始碼行為 — 菜單綁定問題的修正來自v2.123.4.0，編輯器的 LearnedMove 編碼來自其自身的條目）。Halyson 已釋出該 DLL（Ronso Mana 已停止使用它）。待辦事項：(1)build_hooks.ps1 -WithPolyHook -Release → 已編譯 10/10 個鉤子，包括NulWardTeachHook.cpp 使用多站點修復程式 (cmp r32,140h/cmp eax,140h→322，修補所有網站，包括 PLACEMENT 迴圈81 FF=edi) 先前僅以程式碼形式存在；(2) 透過install_to_modules.ps1 -EnableApply -EnableTeach — 先前 DLL 的備份（ffx-hooks.dll.backup-nul-ward-20260616-071450)，新的 SHA 前綴95E1D56A8B9269F7, 旗幟nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) 應另一條車道的請求，設立modules/item_stack_cap_255.flag (空) → 裝填ItemStackCapHook (堆疊上限 99→255；由另一條路徑撰寫的鉤子，已編譯至共用 DLL 中，預設值FFX_ITEM_STACK_CAP_EXTENDED=255)。閘門--nul-ward-static 目前 評定結果：通過 (exe 位元組 + 322 行 +engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + DLL 字串 + 部署標誌 + 新增清除功能）。RT2 遊戲內版本已釋出（Nul Ward：施放 320/321 非攻擊型法術已在離線環境驗證成功，尚待在白色選單中顯示 + 網格教學 + 效果持久化；物品堆疊上限：文件第 8 節的 6 種情境 — 堆疊 100 瓶藥水、Steal/Drop/Mix/Shop/Treasure，回歸測試標誌關閉）。文件：FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16,FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 §8

v2.124.0.1

返回更新列表

JARVIS-MAGIC

更新 2.124

2026/6/16

v2.124.0.0MINORJarvis-MAGIC

物品堆疊上限 99→255：新增`ItemStackCapHook` 在`FfxHooksDll` （新功能，由旗標觸發）

（新功能：運行時新增 hook + 類似寫入器的修補程式，可解除棧容量限制，使其超越原生極限；這是我們首次實作此功能）FFX_Inventory_AddItem). 這項發現（經由 idalib MCP 在FFX_recon.i64 (2026-06-16)：每個插槽限99項，且中央夾具在單一功能中FFX.exe —FFX_Inventory_AddItem@0x003905A0 (IDA 公寓0x7905A0) — 共有 兩push 63h 傳入通用輔助函式參數 **FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. 這 14 個呼叫器（steal/drop/mix/shop/treasure/event/menu）全部都透過這個單一函數進行處理——其他路徑中並未出現 clamp 的複製貼上。載入時不進行歸一化（已於FFX_Btl_PrepareSaveCommandState@0x786BC0：僅初始化空的槽位，不會對現有的計數提出異議）。儲存空間（1 位元組在QuantityBase+slot 在「儲存 +」中byte[112] 在 RAM 中0xD30B5C) 現已支援 0..255，無需重新分配。選用的策略： byte-narrow 修補程式無法達到 255（push imm86A FF 原本應為 -1 的符號延伸 → 透過 trampoline + stub 進行 5 位元組的繞道（如同範本NovaSuperDamageHook). 每個存根：push imm32 <cap> 取代push 63h, 重播偏移的 2..3 位元組，並透過jmp rel32 為了0x00390622/0x00390652. 可透過以下方式設定 Cap：FFXHOOKS_ITEM_STACK_CAP env（預設值 255，限制範圍 1..255）。閘控：item_stack_cap_255.flag （預設為關閉 = 保留原始行為，進行自然回歸測試）。修補程式套用前已驗證的哨兵位元組：kExpectedNew[5] = {6A 63 6A 00 53} (網站 #1 / 新增欄位) 以及kExpectedExist[5] = {6A 63 8D 04 1E} (網站 #2 / 現有槽位)。若第二次寫入失敗，則自動回滾（不要讓它處於半安裝狀態）。PolyHook 編譯通過（11/11 個 C++ 檔案，包含新的ItemStackCapHook.cpp)，已部署的 DLL Release 版本 (932352→935936 bytes, 新掛鉤的 +3584)。重新命名與註解.i64 適用規則（IDA黃金法則）：0x7905A0→FFX_Inventory_AddItem,0x79A0D0→FFX_Math_ClampInt,0x790500→FFX_Inventory_GetItemCount,0x784A90→FFX_Inventory_DebugMaxAll,g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, 留言請至0x79061D/0x79064D （使用 trampoline 配方製作的 clamp sites）。UI 判定（來自 spike）：safe-above-99-provavel (getter 返回原始位元組，未重新限制範圍；視覺風險 = 2 位數的佈局在「100」以上可能發生溢出，但格式化器%d 可接受 3 位數且不會當機）。第 3 階段 UI 修補程式未主動套用 — RT2 已確認。 Phase 4 RT2 包含 6 種情境（存檔編輯 Quantity=200、偷取/掉落、商店購買、混合、使用藥水、UI 渲染）於docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 遊戲內 需測試（Halyson）。文件：docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. 新增檔案：RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. 播放過的檔案：shared/ffx_addresses.h (10 個新的 RVAs+常數)，dllmain.cpp (包含 + 旗標啟用程式 + InstallItemStackCapHook 在InstallHooks + RemoveItemStackCapHook)，FfxHooksDll.vcxproj,build_hooks.ps1. [上一頁：v2.123.5.1]

v2.124.0.1REVISIONJarvis-MAGIC

羅恩索·馬納（上週五 RE）："滿格"理論已不成立 — 真正的關鍵在於解決選單樹的結點（`ResolveMenuTreeNode`)，請勿進行估算

（文件審閱 + 重新命名/註解於.i64 真實；完全沒有行為上的改變，DLL 未被修改 — 另一間房間可以使用它）。RT2 的hudSafe=24 (v2.123.4.1) 發生錯誤，且日誌顯示整個儀表列（hudSafe 23/24）為何出錯： P0 調度 #1..#48 電荷=100 最大值=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 警告：在指令 0-49 中未找到 OD ring 標頭 — 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 → 解＝−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 = 基數 + *(基數+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]，vanilla 的回報 — 在 **2 種情境** 下（經證實的 OD 滿載儲存-編輯 vs 我們的強制情境）以及 **d 區分這些idx/cnt** → 顯示固定值的確切數值（輸入blob[45] 有效，或重新導向 treeId，或填入case 3 每台設備actor+0xF7C). **建議：** 將的量規銷恢復原狀／消除其作用hudSafe=24 （這不是正確的方法），僅保留gateMin/drainCost （用量已確認無誤）。文件：docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §11. [前文：v2.124.0.0`]

v2.124.0.2Jarvis-MAGIC

Build+deploy 來自`ffx-hooks.dll` (已釋放的 DLL)：實作與固定選單綁定的 Nul Ward + 武器標記 Nul Ward 及 RT2 的物品堆疊上限；離線預檢結果為 GREEN

審查（運作層面：已版本化的程式碼重新建置與部署，以及旗標建立；本次無任何新原始碼行為 — 菜單綁定問題的修正來自v2.123.4.0，編輯器的 LearnedMove 編碼來自其自身的條目）。Halyson 已釋出該 DLL（Ronso Mana 已停止使用它）。待辦事項：(1)build_hooks.ps1 -WithPolyHook -Release → 已編譯 10/10 個鉤子，包括NulWardTeachHook.cpp 使用多站點修復程式 (cmp r32,140h/cmp eax,140h→322，修補所有網站，包括 PLACEMENT 迴圈81 FF=edi) 先前僅以程式碼形式存在；(2) 透過install_to_modules.ps1 -EnableApply -EnableTeach — 先前 DLL 的備份（ffx-hooks.dll.backup-nul-ward-20260616-071450)，新的 SHA 前綴95E1D56A8B9269F7, 旗幟nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) 應另一條車道的請求，設立modules/item_stack_cap_255.flag (空) → 裝填ItemStackCapHook (堆疊上限 99→255；由另一條路徑撰寫的鉤子，已編譯至共用 DLL 中，預設值FFX_ITEM_STACK_CAP_EXTENDED=255)。閘門--nul-ward-static 目前 評定結果：通過 (exe 位元組 + 322 行 +engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + DLL 字串 + 部署標誌 + 新增清除功能）。RT2 遊戲內版本已釋出（Nul Ward：施放 320/321 非攻擊型法術已在離線環境驗證成功，尚待在白色選單中顯示 + 網格教學 + 效果持久化；物品堆疊上限：文件第 8 節的 6 種情境 — 堆疊 100 瓶藥水、Steal/Drop/Mix/Shop/Treasure，回歸測試標誌關閉）。文件：FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16,FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 §8

v2.124.0.1