Update 2.124

Stapelobergrenze 99→255: neu `ItemStackCapHook` in `FfxHooksDll` (neue Funktion, durch Flag gesteuert)

• (neue Funktion: neuer Hook zur Laufzeit + Writer-ähnlicher Patch, der die Stack-Obergrenze über das Vanilla-Limit hinaus aufhebt; wir spielen das zum ersten Mal FFX_Inventory_AddItem). Die Entdeckung (nachgewiesen mittels idalib MCP in FFX_recon.i64 (16.06.2026): Die Begrenzung auf 99 Elemente pro Slot und die zentrale Klemme in EINER Funktion im FFX.exe — FFX_Inventory_AddItem@0x003905A0 (IDA-Wohnung 0x7905A0) — mit ZWEI push 63h** den generischen Helper mit Daten versorgen FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. Die 14 Caller (steal/drop/mix/shop/treasure/event/menu) werden ALLE über diese einzige Funktion geleitet – es gibt kein Kopieren und Einfügen von Clamp in andere Pfade. Keine Normalisierung beim Laden (getestet in FFX_Btl_PrepareSaveCommandState@0x786BC0: Es initialisiert nur leere Slots und berücksichtigt keine vorhandenen Zählwerte. Speicher (1 Byte in QuantityBase+slot im Spielstand + byte[112] im RAM in 0xD30B5C) unterstützt bereits 0..255 ohne Neuzuweisung. Gewählte Strategie: Der „byte-narrow“-Patch erreicht NICHT 255 (push imm8 6A FF wäre sign-extended für -1) → 5-Byte-Umweg mit Trampolin + Stub pro Stelle (wie Vorlage NovaSuperDamageHook). Jeder Stub: push imm32 <cap> ersetzt das push 63h, spielt die 2..3 verschobenen Bytes ab, kehrt über jmp rel32 für 0x00390622/0x00390652. CAP konfigurierbar über FFXHOOKS_ITEM_STACK_CAP env (Standardwert 255, begrenzt auf 1..255). Gating: item_stack_cap_255.flag (standardmäßig deaktiviert = beibehaltenes Standardverhalten, natürlicher Regressionstest). Vor dem Patch überprüfte Sentinel-Bytes: kExpectedNew[5] = {6A 63 6A 00 53} (Website Nr. 1 / neuer Platz) und kExpectedExist[5] = {6A 63 8D 04 1E} (Standort Nr. 2 / vorhandener Slot). Automatisches Rollback, falls der zweite Schreibvorgang fehlschlägt (lässt keine unvollständige Installation zu). PolyHook-Build erfolgreich (11/11 cpp, einschließlich des neuen ItemStackCapHook.cpp), bereitgestellte DLL (932352→935936 bytes, +3584 des neuen Hooks). Umbenennungen + Kommentare .i64 angewendet (IDA-GOLDENE REGEL): 0x7905A0→FFX_Inventory_AddItem, 0x79A0D0→FFX_Math_ClampInt, 0x790500→FFX_Inventory_GetItemCount, 0x784A90→FFX_Inventory_DebugMaxAll, g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, Kommentare unter 0x79061D/0x79064D (Clamp-Stellen mit Trampolin-Rezept). UI-Befund (des Spikes): safe-above-99-provavel (Der Getter gibt ein rohes Byte zurück, ohne Rückklammerung; visuelles Risiko = das 2-stellige Layout kann bei „100“+ überlaufen, aber der Formatter %d akzeptiert 3 Ziffern ohne Absturz). Phase-3-UI-Patch nicht proaktiv angewendet — RT2 bestätigt. Phase 4: RT2-Rezept für 6 Szenarien (Save-Edit Quantity=200, Steal/Drop, Shop-Kauf, Mix, Trank verwenden, UI-Render) in docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 im Spiel Muss getestet werden (Halyson). Dok.: docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. Neue Dateien: RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. Abgespielte Dateien: shared/ffx_addresses.h (10 neue RVAs + Konstanten), dllmain.cpp (include + Flag-Enabler + InstallItemStackCapHook in InstallHooks + RemoveItemStackCapHook), FfxHooksDll.vcxproj, build_hooks.ps1. [vorherige Seite: v2.123.5.1]

Ronso Mana (letzte 5. Runde RE): Die „Vollbalken“-Theorie ist WEG — das eigentliche Gate ist die AUFLÖSUNG DES KNOTENS IM MENÜBAUM (`ResolveMenuTreeNode`), bitte nicht bewerten

• (RE/doc + Umbenennungen/Kommentare in der .i64 tatsächlich; KEINE Verhaltensänderung, DLL unberührt — der andere Raum kann sie nutzen). Das RT2 des hudSafe=24 (v2.123.4.1) FEHLER, und das Protokoll BELEGT, warum die gesamte Anzeigezeile (hudSafe 23/24) falsch war: 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 WARNUNG: OD-Ring-Header in den Befehlen 0–49 NICHT GEFUNDEN — 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) = Löse(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 → Lösung = −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 = Basis + *(Basis + 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], Ergebnis von Vanilla – in **2 Szenarien** (nachweislich volles OD bei „Save-Edit“ vs. unser erzwungenes) und **d iffar die idx/cnt** → gibt den genauen Wert für „fix“ an (eingeben blob[45]gültig, oder die treeId umleiten, oder diecase 3pro Bedieneractor+0xF7C). **Empfehlung:** Den Messstift des hudSafe=24(das ist nicht der richtige Weg), sondern nurgateMin/drainCost(Verbrauch bereits bestätigt). Dok.:docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md§ 11. [zuvor:v2.124.0.0`]

Build+Deploy von `ffx-hooks.dll` (Freigegebene DLL): Instanziiert das menügebundene Fix-Menü des Nul Ward + Nul Ward-Flags und Item-Stack-Cap für RT2; Offline-Preflight: GRÜN

• (operativ: Rebuild + Deployment von bereits versioniertem Code + Erstellung von Flags; kein NEUES Quellcode-Verhalten in diesem Durchlauf – der Fix für „menu-bound“ stammt aus dem v2.123.4.0, die „LearnedMove“-Kodierung des Editors stammt aus seinem eigenen Eintrag). Halyson hat die DLL veröffentlicht (Ronso Mana hat ihre Nutzung bereits eingestellt). Maßnahmen: (1) build_hooks.ps1 -WithPolyHook -Release → 10 von 10 Hooks kompiliert, darunter NulWardTeachHook.cpp mit dem Multi-Site-Fix (cmp r32,140h/cmp eax,140h→322, patcht ALLE Websites, einschließlich der PLACEMENT-Schleife 81 FF=edi), das zuvor nur verschlüsselt war; (2) Bereitstellung über install_to_modules.ps1 -EnableApply -EnableTeach — Sicherungskopie der vorherigen DLL (ffx-hooks.dll.backup-nul-ward-20260616-071450), neues SHA-Präfix 95E1D56A8B9269F7, Flaggen nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) auf Wunsch einer anderen Lane, erstellt modules/item_stack_cap_255.flag (leer) → lädt die ItemStackCapHook (Stack-Cap 99→255; Hook aus der anderen Lane, bereits in die gemeinsam genutzte DLL kompiliert, Standard FFX_ITEM_STACK_CAP_EXTENDED=255). Gate --nul-ward-static jetzt ERGEBNIS: BESTANDEN (exe-Bytes + 322 Zeilen + engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + DLL-Strings + Deploy-Flags + neues Clear). RT2 im Spiel freigegeben (Nul Ward: 320/321 nicht in Attack umwandeln – offline bereits getestet, fehlt noch die Anzeige im weißen Menü + Anzeige über Raster + Persistenz; Gegenstands-Stapel-Obergrenze: 6 Szenarien aus dem Dokument §8 – 100 Tränke stapeln, Steal/Drop/Mix/Shop/Treasure, Regressionsflag deaktiviert). Dokumente: FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16, FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 § 8

v2.124.0.1