Mise à jour 2.124

Limite de pile d'objets 99→255 : nouveau `ItemStackCapHook` dans le `FfxHooksDll` (nouvelle capacité, activée par un indicateur)

• (nouvelle capacité : nouveau hook en temps d'exécution + patch de type « writer » qui débloque la capacité de pile au-delà de la limite par défaut ; première fois que nous abordons FFX_Inventory_AddItem). La découverte (prouvée via idalib MCP dans FFX_recon.i64 le 16/06/2026) : la limite de 99 éléments par emplacement et la limitation central dans UNE fonction de FFX.exe — FFX_Inventory_AddItem@0x003905A0 (IDA flat 0x7905A0) — avec DEUX push 63h alimentant l'assistant générique FFX_Math_ClampInt(v, 0, 99)@0x0039A0D0. Les 14 appelants (steal/drop/mix/shop/treasure/event/menu) TOUS passent par cette fonction unique — il n’y a pas de copier-coller de clamp dans d’autres chemins. Pas de normalisation lors du chargement (prouvé dans FFX_Btl_PrepareSaveCommandState@0x786BC0 : elle n’initialise que des emplacements vides, elle ne récupère pas les comptes existants). Stockage (1 octet dans QuantityBase+slot dans la sauvegarde + byte[112] en RAM dans 0xD30B5C) prend déjà en charge 0..255 sans réallocation. Stratégie choisie : le patch « byte-narrow » n'atteint PAS 255 (la commande push imm8 6A FF serait étendue en signe pour donner -1) → détour de 5 octets avec trampoline + stub par emplacement (selon le modèle NovaSuperDamageHook). Chaque stub : push imm32 <cap> remplace le push 63h, rejoue les 2 ou 3 octets décalés, revient via jmp rel32 vers 0x00390622/0x00390652. Cap configurable via FFXHOOKS_ITEM_STACK_CAP env (valeur par défaut 255, limitée à 1..255). Gating : item_stack_cap_255.flag (désactivé par défaut = comportement d'origine préservé, test de régression naturel). Octets sentinelles vérifiés avant le patch : kExpectedNew[5] = {6A 63 6A 00 53} (site n° 1 / nouvel emplacement) et kExpectedExist[5] = {6A 63 8D 04 1E} (site n° 2 / emplacement existant). Restauration automatique si la deuxième écriture échoue (ne laisse pas d'installation incomplète). Compilation PolyHook réussie (11/11 cpp, y compris le nouveau ItemStackCapHook.cpp), DLL Release déployée (932352→935936 bytes, +3584 pour le nouveau hook). Renommage et commentaires .i64 appliqués (RÈGLE D'OR IDA) : 0x7905A0→FFX_Inventory_AddItem, 0x79A0D0→FFX_Math_ClampInt, 0x790500→FFX_Inventory_GetItemCount, 0x784A90→FFX_Inventory_DebugMaxAll, g_CmdAggregateAvailArrays→g_FFX_InventoryAggregate, commentaires sur 0x79061D/0x79064D (sites de clamp avec la recette du trampoline). Verdict sur l'interface utilisateur (de Spike) : safe-above-99-provavel (le getter renvoie un octet brut, sans reclamp ; risque visuel = la mise en page à 2 chiffres peut déborder au-delà de « 100 »+, mais le formateur %d accepte 3 chiffres sans plantage). Patch d'interface utilisateur de la phase 3 non appliqué de manière proactive — RT2 le confirme. Phase 4 : RT2 – recette de 6 scénarios (modification de la sauvegarde Quantity=200, vol/perte, achat en boutique, mélange, utilisation d’une potion, rendu de l’interface utilisateur) dans docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md §8. RT2 en jeu À tester (Halyson). Doc : docs/reverse/FFX_ITEM_STACK_CAP_99_RESEARCH_2026-06-16.md. Nouveaux fichiers : RuntimeTools/FfxHooksDll/hooks/ItemStackCapHook.{h,cpp}. Fichiers modifiés : shared/ffx_addresses.h (10 nouveaux RVA + constantes), dllmain.cpp (include + activateurs de drapeaux + InstallItemStackCapHook dans InstallHooks + RemoveItemStackCapHook), FfxHooksDll.vcxproj, build_hooks.ps1. [précédent : v2.123.5.1]

Ronso Mana (5e passage RE) : théorie de la « barre pleine » INVALIDE — la porte réelle est la RÉSOLUTION DU NŒUD DE L'ARBRE DE MENU (`ResolveMenuTreeNode`), pas la jauge

• (RE/doc + renommages/commentaires dans la .i64 réelle ; AUCUN changement de comportement, DLL inchangée — l’autre salle peut l’utiliser). Le RT2 de hudSafe=24 (v2.123.4.1) A ÉCHOUÉ et le journal PROUVE pourquoi toute la ligne de jauge (hudSafe 23/24) était erronée : 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 AVERTISSEMENT : en-tête OD ring NON TROUVÉ dans les commandes 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], retour à la version vanilla — dans 2 scénarios (modification de sauvegarde avec OD plein vérifiée vs notre version forcée) et d iffar les idx/cnt → révèle la valeur exacte pour la correction (écrire une valeur blob[45] valide, ou rediriger le treeId, ou remplir le case 3 par opérateur actor+0xF7C). Recommandation : inverser/neutraliser la broche de jauge du hudSafe=24 (ce n’est pas la bonne solution), en ne conservant que gateMin/drainCost (consommation déjà confirmée comme correcte). Doc : docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §11. [précédent : v2.124.0.0]

Compilation et déploiement de `ffx-hooks.dll` (DLL publiée) : met en œuvre le correctif lié au menu du Nul Ward + drapeaux d'arme Nul Ward et limite de pile d'objets pour RT2 ; pré-vérification hors ligne VERTE

• (opérationnelle : reconstruction + déploiement du code déjà versionné + création de drapeaux ; aucun NOUVEAU comportement du code source lors de ce passage — le correctif « menu-bound » provient de v2.123.4.0, l’encodage « LearnedMove » de l’éditeur provient de sa propre entrée). Halyson a publié la DLL (la lane Ronso Mana a fini de l'utiliser). Actions : (1) build_hooks.ps1 -WithPolyHook -Release → 10 hooks sur 10 compilés, y compris NulWardTeachHook.cpp avec le correctif multi-site (cmp r32,140h/cmp eax,140h→322, corrige TOUS les sites, y compris la boucle de PLACEMENT 81 FF=edi) qui n'était auparavant que codée ; (2) déploiement via install_to_modules.ps1 -EnableApply -EnableTeach — sauvegarde de la DLL précédente (ffx-hooks.dll.backup-nul-ward-20260616-071450), nouveau préfixe SHA 95E1D56A8B9269F7, indicateurs nul_ward.flag+nul_ward_apply.flag+nul_ward_teach.flag+nul_ward_teach_grant.flag ; (3) à la demande d’une autre voie, création de modules/item_stack_cap_255.flag (vide) → arme le ItemStackCapHook (limite de pile 99→255 ; hook créé par l’autre lane, déjà compilé dans la DLL partagée, valeur par défaut FFX_ITEM_STACK_CAP_EXTENDED=255). Gate --nul-ward-static maintenant VERDICT : PASS (octets de l'exe + 322 lignes + engine_lookup_resolves Radiant@0x7814/Umbral@0x7874 inRange + chaînes DLL + indicateurs de déploiement + nouvelle suppression). RT2 disponible en jeu (Nul Ward : lancer 320/321 sans se transformer en Attack, déjà testé hors ligne, il manque l’affichage dans le menu blanc + l’enseignement via la grille + la persistance ; Limite de pile d’objets : 6 scénarios du doc §8 — pile de 100 potions, Steal/Drop/Mix/Shop/Treasure, indicateur de régression désactivé). 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