Actualización 2.124

Límite de apilamiento de objetos 99→255: nuevo `ItemStackCapHook` en `FfxHooksDll` (nueva capacidad, activada por flag)

• (nueva capacidad: nuevo hook en tiempo de ejecución + parche tipo «writer» que libera el límite de la pila más allá del límite predeterminado; es la primera vez que lo utilizamos FFX_Inventory_AddItem). El descubrimiento (demostrado mediante idalib MCP en FFX_recon.i64 (16 de junio de 2026): el límite de 99 elementos por ranura y el «clamp» central en UNA función en el FFX.exe — FFX_Inventory_AddItem@0x003905A0 (IDA flat 0x7905A0) — con DOS push 63h Pasando parámetros al helper genérico FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. Los 14 «callers» (steal/drop/mix/shop/treasure/event/menu) TODOS se canalizan a través de esta única función; no hay «copiar y pegar» de «clamp» en otras rutas. Sin normalización en la carga (probado en FFX_Btl_PrepareSaveCommandState@0x786BC0: solo inicializa los slots vacíos, no comprueba los recuentos existentes). Almacenamiento (1 byte en QuantityBase+slot en «guardar +» byte[112] en RAM en 0xD30B5C) ya admite valores de 0 a 255 sin reasignación. Estrategia elegida: el parche «byte-narrow» NO alcanza el 255 (push imm8 6A FF sería una extensión de signo para -1) → desvío de 5 bytes con trampolín + stub por sitio (igual que la plantilla NovaSuperDamageHook). Cada stub: push imm32 <cap> sustituye al push 63h, reproduce los 2 o 3 bytes desplazados y vuelve a través de jmp rel32 para 0x00390622/0x00390652. Cap configurable a través de FFXHOOKS_ITEM_STACK_CAP env (por defecto 255, limitado a 1..255). Gating: item_stack_cap_255.flag (desactivado por defecto = comportamiento predeterminado conservado, prueba de regresión natural). Bytes centinela verificados antes del parche: kExpectedNew[5] = {6A 63 6A 00 53} (página web n.º 1 / nueva ranura) y kExpectedExist[5] = {6A 63 8D 04 1E} (sitio n.º 2 / ranura existente). Rollback automático si falla la segunda escritura (no lo dejes a medias). Compilación de PolyHook superada (11/11 cpp, incluido el nuevo ItemStackCapHook.cpp), DLL de versión de lanzamiento implementada (932352→935936 bytes, +3584 del nuevo hook). Cambios de nombre y comentarios .i64 aplicados (REGLA DE ORO IDA): 0x7905A0→FFX_Inventory_AddItem, 0x79A0D0→FFX_Math_ClampInt, 0x790500→FFX_Inventory_GetItemCount, 0x784A90→FFX_Inventory_DebugMaxAll, g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, comentarios en 0x79061D/0x79064D (sitios de sujeción con la receta del trampolín). Veredicto UI (del pico): safe-above-99-provavel (el getter devuelve un byte sin procesar, sin reclamp; riesgo visual = el formato de 2 dígitos puede desbordarse en «100» o más, pero el formateador %d (admite 3 dígitos sin que se cuelgue el juego). El parche de la interfaz de usuario de la Fase 3 no se ha aplicado de forma proactiva — RT2 lo confirma. Fase 4: RT2, receta de 6 escenarios (edición de partida: Cantidad=200, robar/soltar, compra en tienda, mezclar, usar poción, renderización de la interfaz de usuario) en docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 en el juego Hay que probarlo (Halyson). Doc: docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. Archivos nuevos: RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. Archivos reproducidos: shared/ffx_addresses.h (10 nuevos RVA + constantes), dllmain.cpp (incluye + activadores de indicadores + InstallItemStackCapHook en InstallHooks + RemoveItemStackCapHook), FfxHooksDll.vcxproj, build_hooks.ps1. [anterior: v2.123.5.1]

Ronso Mana (5.ª pasada RE): la teoría de la «barra llena» HA FALLADO — la puerta real es la RESOLUCIÓN DEL NUDO DEL ÁRBOL DE MENÚ (`ResolveMenuTreeNode`), no gauge

• (RE/doc + cambios de nombre/comentarios en la .i64 real; NINGÚN cambio de comportamiento, DLL intacta — la otra sala puede utilizarla). El RT2 del hudSafe=24 (v2.123.4.1) HA FALLADO y el registro DEMUESTRA por qué toda la línea del indicador (hudSafe 23/24) era incorrecta: P0 envío n.º 1..48 carga=100 máx=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 ADVERTENCIA: No se ha encontrado el encabezado «OD ring» en los comandos 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) = Resuelve(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 → Resuelve=−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], resultado de Vanilla — en **2 escenarios** (save-edit con OD completo comprobado frente a nuestro forzado) y **d distinguir a los idx/cnt** → muestra el valor exacto de «fix» (escribir blob[45]válido, o redirigir el treeId, o rellenar elcase 3por operadoractor+0xF7C). **Recomendación:** revertir/neutralizar el pin de calibración del hudSafe=24(no es el camino), conservando sologateMin/drainCost(consumo ya confirmado). Doc.:docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md§11. [anterior:v2.124.0.0`]

Build+deploy de `ffx-hooks.dll` (DLL liberada): materializa el menú fijo vinculado al Nul Ward + indicadores de arma Nul Ward y límite de pila de objetos para RT2; comprobación previa sin conexión VERDE

• (operativa: reconstrucción + implementación de código ya versionado + creación de flags; ningún comportamiento de código fuente NUEVO en esta pasada — la corrección del menú vinculado es del v2.123.4.0, la codificación «LearnedMove» del editor corresponde a su propia entrada). Halyson ha publicado la DLL (Ronso Mana ya ha dejado de usarla). Acciones: (1) build_hooks.ps1 -WithPolyHook -Release → 10 de 10 hooks compilados, incluidos NulWardTeachHook.cpp con el parche multisitio (cmp r32,140h/cmp eax,140h→322, aplica el parche a TODAS las páginas web, incluido el bucle de PLACEMENT 81 FF=edi) que antes solo estaba codificado; (2) implementación a través de install_to_modules.ps1 -EnableApply -EnableTeach — copia de seguridad de la DLL anterior (ffx-hooks.dll.backup-nul-ward-20260616-071450), nuevo prefijo SHA 95E1D56A8B9269F7, banderas nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag; (3) a petición de otra lane, creada modules/item_stack_cap_255.flag (vacía) → carga el ItemStackCapHook (límite de la pila 99→255; hook creado por la otra línea, ya compilado en la DLL compartida, por defecto FFX_ITEM_STACK_CAP_EXTENDED=255). Gate --nul-ward-static ahora VEREDICTO: APROBADO (bytes del archivo exe + 322 filas + engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + cadenas DLL + indicadores de implementación + nueva opción «clear»). RT2 disponible en el juego (Nul Ward: lanzar 320/321 sin que se convierta en «Attack», ya probado fuera de línea; falta que aparezca en el menú blanco + enseñanza mediante cuadrícula + persistencia; Límite de apilamiento de objetos: 6 escenarios del documento, apartado 8 — apilar 100 pociones, Steal/Drop/Mix/Shop/Treasure, indicador de regresión desactivado). Documentación: FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16, FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16 §8

v2.124.0.1