Actualización 2.127
16/6/2026
updatemonster-ai
Capture Cascada Cap-1 Fase C: escritor `capturable` de 1 byte (`MonsterCaptureFlagWriter`) + puerta `--monster-capture-bit-rt0` PASS 361/361 en todo el corpus básico. Carril Jarvis-CAPCAS-WRITE. MENOR (nueva capacidad: primer escritor para la característica `Capture Cascade`/`Yoke of Spira`; biblioteca + puerta, todavía NO hay UI). Implementa la Fase C del plan Cap-1 (La Fase B `v2.123.3.1` localizó el byte; la Fase C escribe en él). Escritor (`FFXProjectEditor/FfxLib/Monster/MonsterCaptureFlagWriter.cs`): nivel de bytes (sin recorrido de ida y vuelta de estructura completa `Monster_File.Read(...).Write()`), opera directamente en `bytes[StatSheetPointer + 0x78]` con `StatSheetPointer = uint32_le(bytes[0x0C])`. API: `TryGetStatSheetPointer`, `GetCaptureFlagFileOffset`, `ReadCaptureFlag`, `ReadPaddingByte`, `WriteCaptureFlag(monBin, newSlot)` (clona la matriz, invierte el byte, sigue rellenando `0x00`, rechaza monstruos con relleno distinto de cero como variante desconocida); ayudantes `IsUncapturable`/`IsVanillaArenaSlot`/`IsSidecarArenaSlot`. Constantes `Uncapturable = 0xFF`, `VanillaArenaSlotMin/Max = 0x00..0x67`, `SidecarArenaSlotMin/Max = 0x68..0xFE` (vainilla MA = 104 ranuras, archivo auxiliar = Capture Región en cascada sin colisión de bestiario). Puerta (`FFXProjectEditor/Tools/MonsterCaptureFlagRt0.cs`): invocada a través de `FFXProjectEditor.exe --monster-capture-bit-rt0 [monsterRoot]`, demuestra 3 propiedades por monstruo: (1) identidad de bytes del mismo valor — `WriteCaptureFlag(bin, current)` == `bin` (el escritor no es operativo cuando newSlot==ACTUAL); (2) diferencia de solo ranura: `WriteCaptureFlag(bin, target)` difiere de `bin` en exactamente 1 byte, en `[StatSheetPointer + 0x78]`, con relleno `0x00`, cada dos bytes son idénticos; (3) voltear y restaurar RT0 — `WriteCaptureFlag(WriteCaptureFlag(bin, target), original)` == `bin` (idempotencia total). El objetivo se elige fuera de banda por categoría: destapar (0xFF) cambia a 0x68 (archivo auxiliar), vainilla MA cambia a 0xFF, etc. Resultado contra `FFX Extracted\...\jppc\battle\mon` (vainilla): VEREDICTO PASS — 361/361 monstruos, 251 destapar (0xFF), 110 ranura MA básica, 0 archivo auxiliar, 0 relleno distinto de cero, análisis de encabezado 361/361, RT0 361/361 del mismo valor, diferenciación de solo ranura 361/361, girar y restaurar RT0 361/361. Excede 6× el corpus de evidencia de Fase B de 58 muestras. Cableado a `RuntimeTools/offline_ci.ps1` `$editorGates` (entre `monster` y `encounter`): puerta interna permanente. Nuevos archivos: `FfxLib/Monster/MonsterCaptureFlagWriter.cs`, `Tools/MonsterCaptureFlagRt0.cs`. Tocado: `Program.cs` (`--monster-capture-bit-rt0` cableado), `RuntimeTools/offline_ci.ps1` (`$editorGates`). No toca: `m###.bin` (la puerta es de solo lectura: solo lee archivos básicos, nunca escribe en el disco), DLL, tiempo de ejecución, guardar, enlace. C# Versión de compilación PASS (0 errores, 384 advertencias de referencia). Fase C UI no conectada en este entregable: todavía biblioteca + puerta, sin botón público. Siguiente paso seguro: Fase D (casilla de verificación UI `Capturable` en `MonEditor` + escritor masivo para Eones oscuros + Verdugo final) o RT2 en el juego (Halyson edita 1 monstruo desechable `0xFF→0x68` en un `m###.bin` REAL, guarda, inicia el juego, captura el monstruo para confirmar que el motor acepta ranuras fuera del rango básico 0x00..0x67). Documento: `docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_RESULT_2026-06-16.md` §5.1.
Leer notas