Beta Update

Note precedenti della fase beta, conservate come pubblicate.

Questo è l’archivio delle note precedenti della fase beta. Le nuove note sono nella pagina degli aggiornamenti.

Aggiornamento 2.69

10/06/2026

Blitzball Recruits Editor: UI per cambiare CHI viene reclutato in ogni luogo (file di gioco; writer (letterale tecnico: WHO) (letterale tecnico: game-file)`v2.67.0` provato). Nuovo modulo/tab `Blitzball Recruits 🏐` (`Modules/BlitzballRecruitEditor`) che modifica il reclutamento di agenti liberi direttamente nel file di gioco: elenca i (letterale tecnico: free-agent)~34 eventi di reclutamento sul campo (Luca/Kilika/Guadosalam/Calm Lands/Airship/Besaid/…, derivato dal corpus via la firma (letterale tecnico: corpus-derived)`AE 28 00 14 AE <id> 00 A3`), e per ogni evento mostra ogni sito di reclutamento con un menu a discesa dei 60 giocatori (nomi risolti da `macrodic.dcp` via `BlitzballPlayerNames`) per ri-puntare chi viene reclutato lì. Consuma il writer già provato (letterale tecnico: re-point) (letterale tecnico: already-proven)`BlitzballRecruit_File`/`Event_File.PatchScriptByte` (gate `--blitzball-recruit-rt0`) attraverso `ByteSnapshotEditorSession` (per-evento: salvataggio/annulla/ripristino originale/salvataggio automatico, un mirror del MacroExplorer multi-sorgente). Registrato in (letterale tecnico: restore-original) (letterale tecnico: auto-save) (letterale tecnico: multi-source)`Main_Window` (nav + `SetModule`). Onestà: "Writable (Lab)" ri-punta solo il ID giocatore del reclutato (file di gioco, (letterale tecnico: game-file) (letterale tecnico: re-points) (letterale tecnico: player-id) (letterale tecnico: only)nessuna patch EXE; isolamento RT0 provato, RT2 in gioco in sospeso); ogni giocatore di solito ha (letterale tecnico: in-game)2 siti (due rami di codice) → cambia entrambi per ri-puntare completamente; disponibilità/gating del reclutamento resta nella logica evento; le stat giocatore = tab Blitzball Roster, i nomi = Macro Explorer. (letterale tecnico: re-point)MINOR (NUOVO modulo/tab; precedente: Blitzball Roster Editor (letterale tecnico: NEW)`v2.68.0` = MINOR). Riusa il writer esistente/`Event_File`/`MacroDictionary_File`/`BlitzballPlayerNames`/`ByteSnapshotEditorSession`; non aggiunge un nuovo writer né tocca save/runtime/SIN/altre lane. Build 0 errori / 361 warning; `--blitzball-recruit-rt0` PASS. \[precedente: `v2.68.0`] — Jarvis-CHAPPU

Leggi le note

SeymourBETAMINOR

Aggiornamento 2.68

10/06/2026

updateruntime-hook

Blitzball Roster Editor: UI visiva per le stat/crescita dei 60 giocatori (file di gioco; writer (letterale tecnico: game-file)`v2.66.0` provato). Nuovo modulo/tab `Blitzball Roster 🏐` (`Modules/BlitzballRosterEditor`) che modifica visivamente le curve stat-crescita dei 60 giocatori dentro (letterale tecnico: stat-growth)`bltz0002.ebp`: una lista giocatori (con nomi read-only risolti da `macrodic.dcp` via `BlitzballPlayerNames`) + un editor per le 8 stat (HP/SP/AT/EN/PA/SH/BL/CA), ognuna con i 4 float modificabili `a/b/c/growthType`, un anteprima valore live a Lv 1/50/99 e la formula. Consuma il writer già provato (letterale tecnico: already-proven)`BlitzballRoster_File` (gate `--blitzball-roster-rt0`) attraverso `ByteSnapshotEditorSession` (save/undo/restore-original/auto-save, un mirror esatto di `TreasureEditor`). Registrato in `Main_Window` (nav + `SetModule`). Onestà: badge "Writable (Lab)" — scrive solo le tabelle stat-crescita (identità byte RT0 provata, RT2 in-game pending); (letterale tecnico: stat-growth) (letterale tecnico: byte-identity)i nomi sono read-only qui (modificali in Macro Explorer); techs/level/EXP/cost sono save-side; il motore partita / gli effetti tecnica sono EXE-native (vedi la mappa indirizzi). MINOR (NUOVO modulo/tab; precedente: Blitzball Prize Explorer (letterale tecnico: NEW)`v2.62.0` = MINOR). Riusa il writer/`Event_File`/`MacroDictionary_File`/`BlitzballPlayerNames`; non aggiunge un nuovo writer né tocca altre lane/runtime/save/SIN. Build 0 errori / 361 warning; `--blitzball-roster-rt0` PASS. [precedente: `v2.67.0`] — Jarvis-CHAPPU

Leggi le note

SeymourBETAMINOR

Aggiornamento 2.67

10/06/2026

updateruntime-hook

Blitzball: RECRUITMENT modificabile nel FILE DI GIOCO — patcher immediato ATEL nel (letterale tecnico: GAME FILE)`.ebp` (RT0 provato). Chi viene reclutato in ogni posizione è un immediato 1-byte nel bytecode ATEL dell'evento campo: la firma `AE 28 00 14 AE <playerId> 00 A3` (`PUSHII 40 · ADD · PUSHII <playerId> · write-array`) aggiunge alla TUA squadra ( (letterale tecnico: YOUR)`BlitzballTeamPlayers[count+40]`). Nuovo primitivo `Event_File.PatchScriptByte` (patch 1-byte del chunk ATEL, length-preserving via `ScriptChunkOverride`) + `FfxLib/Blitzball/BlitzballRecruit_File.cs` (`FindSites`/`SetRecruit`/`SetRecruitAt`) + gate `Tools/BlitzballRecruitRt0.cs` (`--blitzball-recruit-rt0`). PROVEN su `guad0000.ebp`: 6 siti (Giera `0x1F`/Auda `0x22`/Nav `0x21` × 2 branch), no-edit Read→Write byte-identical (189,696 B), ri-puntare Giera→Wakka ( (letterale tecnico: re-pointing)`0x1F`→`0x33`) isolato a 2 byte agli offset previsti, ri-lettura conferma il nuovo reclutato. Firma validata vs (letterale tecnico: re-read)`guad0000`/`lchb0000`/`hiku0500` (full Al Bhed Psyches). Onestà: cambia CHI viene reclutato dove (file di gioco, (letterale tecnico: WHO) (letterale tecnico: game-file)nessuna patch EXE); disponibilità/gating del reclutamento resta nella logica evento. MINOR (NUOVO writer di reclutamento; il primo del suo genere). Solo AGGIUNGE file + 1 dispatch (letterale tecnico: NEW) (letterale tecnico: ADDS)`Program.cs`; non tocca il save/runtime/SIN/altre lane. Build 0 errori / 361 warning; `--blitzball-recruit-rt0` PASS. Doc: `docs/reverse/FFX_BLITZBALL_ENGINE_IDA_SCOUT_2026-06-10.md`. [precedente: `v2.66.0.1`] — Jarvis-CHAPPU

Leggi le note

SeymourBETAREVISION

Aggiornamento 2.66

10/06/2026

updateruntime-hook

Blitzball ROSTER (stat/crescita dei 60 giocatori) ORA MODIFICABILE nel FILE DI GIOCO — writer variabile ATEL (letterale tecnico: NOW EDITABLE) (letterale tecnico: GAME FILE)`.ebp` PROVATO (RT0 byte-identical + mutazione isolata). (letterale tecnico: ATEL-variable) (letterale tecnico: mutation-isolated) Il primo writer che modifica la base blitzball in un FILE DI GIOCO, non il save. (letterale tecnico: GAME FILE) Le stat base + curve di crescita dei 60 giocatori vivono DENTRO (letterale tecnico: INSIDE)`bltz0002.ebp` come variabili ATEL `0x126..0x12E` (8 stat × 60 giocatori × 4 float `a,b,c,growthType`; formula di crescita decodificata: `gt -1`→1, `0`→a+b·Lv, `1`→a+b·Lv^c, `2`→a+b·Lv−c·Lv², `3`→a+b·Lv+c·Lv²). Nuovo primitivo `Event_File.PatchEventDataElement(varId, idx, bytes)` (`FfxLib/Event/Event_File.AtelVar.cs`): un patcher variabile eventData ATEL in-place, (letterale tecnico: eventData-variable)length-preserving via l'hook `ScriptChunkOverride` esistente → `Write()` ri-pacchetta byte-identico tranne la slice modificata. Nuova classe file read/write (letterale tecnico: re-packs) (letterale tecnico: file-class)`FfxLib/Blitzball/BlitzballRoster_File.cs` (decodifica/modifica la crescita 60×8) + gate `Tools/BlitzballRosterRt0.cs` (`--blitzball-roster-rt0`). PROVEN: (letterale tecnico: PROVEN) lettura byte-exact vs il dump FFXDataParser (player0 HP = `70 + 30·Lv + 0.711·Lv²`); no-edit Read→Write byte-identical (5,445,248 B); 480/480 growthType validi; una patch single-float isolata ai 4 byte dell'elemento target (letterale tecnico: target-element) all'offset previsto (`@0x491680`). RE (il pezzo mancante): la value-base delle variabili = `worker0_header + 0x30` (risolta robustamente, nessun hardcode). Onestà: SOLO stat/crescita sono dati di file; i nomi = macro stringa (letterale tecnico: ONLY) (letterale tecnico: file-data)`0x700+idx` (writer esiste, wiring pending), posizioni/definizioni-tecnica/motore-partita = EXE (IDA-pending) (letterale tecnico: technique-definitions) (letterale tecnico: match-engine), techs-apprese/costo/contratto/level/EXP = (letterale tecnico: learned-techs)save (fuori dallo scope file di gioco). (letterale tecnico: game-file)Nessuna UI ancora (prossimo = `BlitzballRosterEditor`). MINOR (NUOVA capability: primo writer roster blitzball in un file di gioco). Non tocca il save (CHAPPU/checksum), il runtime, SIN o altre lane; solo AGGIUNGE nuovi file + 1 dispatch (letterale tecnico: NEW) (letterale tecnico: ADDS)`Program.cs`. Build 0 errori / 361 warning; `--blitzball-roster-rt0` PASS (no-edit byte-identical + mutazione isolata). Docs: (letterale tecnico: byte-identical)`docs/reverse/FFX_BLITZBALL_ROSTER_BASE_RE_2026-06-10.md` + `docs/ai/BLITZBALL_100PCT_EDITOR_CHECKLIST_2026-06-10.md`. [precedente: `v2.65.3`] — Jarvis-CHAPPU

Leggi le note

SeymourBETAPATCH

Aggiornamento 2.65

10/06/2026

updatemonster-ai

PC/Player Growth nello Spira Data Atlas (read-only, `proved-candidate`, byte-grounded, work/-independent). Collega la VERA fonte di crescita/stat PC nel provider: nuovo (letterale tecnico: REAL)`SpiraDataAtlasDetailKind.PlayerGrowthStat` + accessor value-guarded `SpiraDataAtlasCatalog.TryGetPlayerGrowthStat(source, characterIndex, field, currentRawValue)`. Fonte = `ply_save.bin` (stat base/current) + `ply_rom.bin` (ROM crescita: curva AP-requirement `ApReq A/B/C/Max` + coefficienti auto-growth per-stat `CoefA/B`), le STESSE tabelle che il (letterale tecnico: SAME)`PlayerGrowthEditor` modifica (parser `PlayerKernel_File`, RT0-proved da `--player-rt0`). Gli 20 slot (0–6 PC, 7 guest=Seymour, 8–17 Aeon, 18–19 non mappati) vengono da una tabella compilata byte-grounded (`FfxLib/SpiraDataAtlas/PlayerGrowthData.cs`, generata da `tools/ffxdataparser_bridge/build_player_growth_index.ps1 -EmitCSharp` dai file `.bin`), quindi esistono in QUALSIASI build SENZA (letterale tecnico: ANY) (letterale tecnico: WITHOUT)`work/` (a differenza di `PcAeonFineStat`, che dipende da `work/pc_save_stats_catalog.csv` ed è solo uno snapshot). Le etichette si risolvono a runtime via `Character_Enum` (single source of truth). Onestà (non ovvio): (letterale tecnico: non-obvious) i coefficienti di crescita stat sono (letterale tecnico: stat-growth)Aeon-only — gli slot PC/guest portano ZERO coefficienti (i PC crescono le stat via lo Sphere Grid); l'unica manopola di crescita PC in questa ROM è la curva AP-requirement. Questo è un asse DIVERSO da (letterale tecnico: DIFFERENT)`sum_grow.bin` di BRASKA (auto-level ≠ ricetta customizzazione). REGION-SPECIFIC: `ply_save`/`ply_rom` NON sono locale-invariant (letterale tecnico: NOT) (la sezione dati `new_uspc` differisce da jppc/inpc; tabella compilata = `new_uspc`, la regione che l'editor carica). La formula in-game AP-per-level / guadagno per-coefficiente è `RT2-pending` (byte/campi provati, aritmetica runtime non invertita). Value-guard = stesso value-space che l'editor modifica → modificare il campo (raw mismatch), o uno slot/source/field sconosciuto → accessor `false` → badge nascosto (mirror di Aeon/Shop/Cocktail). Gate `--spiraatlas-rt0` `21296 → 21316` (+20; tutti unici) + 18 nuovi assert (count 20/8/10/2; PC coef zero; Aeon coef non-zero; region uspc; lookup Tidus BaseHp 520 / ply_rom AP max 22000 / Valefor HpCoef 6; value-guard `9999` nasconde; slot/source/field out-of-range miss; domain search; BIBLE domain player-growth). Read-only: no writer/UI/runtime/SIN; non tocca `WriteSave`/`WriteRom`, la UI `PlayerGrowthEditor`, il motore `Common` di ANIMA (solo consumato), o BRASKA/AURON/JECHT/RIKKU/WAKKA/VALEFOR/AURORA/SIN. Build 0 errori / 361 warning; `--player-rt0` + `--spiraatlas-rt0` + `--aicmdmeta-rt0` PASS. Docs: `docs/ai/ATLAS_TIDUS_PC_GROWTH_PROVIDER_RESULT_2026-06-10.md` + scout `docs/ai/ATLAS_TIDUS_PC_GROWTH_SCOUT_RESULT_2026-06-10.md`. [precedente: `v2.64.3`] — Jarvis-TIDUS

Leggi le note

SeymourBETA

Aggiornamento 2.64

10/06/2026

updateruntime-hook

Aeon growth/customization in the Spira Data Atlas (read-only, `proved-candidate`, Aeon-only, compiled). Plugs `sum_grow.bin` (FFX's Aeon customization table) into the provider as a read-only detail kind: new `SpiraDataAtlasDetailKind.AeonGrowthRecipe` + value-guarded accessor `SpiraDataAtlasCatalog.TryGetAeonGrowthRecipe(entryIndex, currentResultRaw, currentItemRaw)`. Aeon-ONLY: `sum_grow.bin` is 636 bytes (`0x14` header + 77 × 8B entries, `Target` always `0x007F`=Aeon, `jppc`==`inpc` byte-identical) → 67 ability recipes (Result cat 3 → Commands) + 10 stat recipes (Result cat 0 → StatOptions, Secondary=1). No PC rows and no Sphere-Grid rows (`PcAeonFineStat` is a separate corpus; grid topology lives in `sphere.bin`/`panel.bin`). Non-`work/` source: the 77 rows come from a byte-grounded compiled table (`FfxLib/SpiraDataAtlas/SumGrowAeonRecipeData.cs`, generated by `build_sum_grow_aeon_fine_index.ps1 -EmitCSharp` from `sum_grow.bin`), so they exist in ANY build without `work/` (unlike Mix/Sphere/Shop). Names/labels are resolved at runtime by the editor's own `AeonCustomizationEntry`+dictionaries (single source of truth, RT0-proved by `--customization-rt0`), never re-invented. Stat-recipe cost = `partial` (the editor renders `Primary× item`; in-game cost is 1 item/application and `Primary` is the increment) — surfaced in the `evidence` column (`;cost-semantics-partial`), not just prose. Gate `--spiraatlas-rt0` `21219 → 21296` details (+77 Aeon; all unique) + 13 new asserts (count 77/67/10; Aeon-only; no PC; no Sphere; ability lookup 66→Ultima/Supreme Gem; stat lookup 67→HP+100/Power Sphere/cost-partial; value-guard `0x9999` hides; out-of-range index miss; domain search; BIBLE domain aeon-growth). Read-only: no writer/UI/runtime/SIN; does not touch RIKKU/WAKKA/JECHT/BAHAMUT/AURORA, ANIMA's `Common` badge engine, or `WriteAeon`/save paths. Unblocks YUNA backlog Q1 (was `blocked`). Verified by a 4-lens adversarial workflow in the scout. Build 0 errors / 361 warnings; `--customization-rt0` + `--spiraatlas-rt0` + `--aicmdmeta-rt0` PASS. Docs: `docs/ai/ATLAS_BRASKA_SUM_GROW_FINE_SCOUT_RESULT_2026-06-10.md` + `docs/ai/HANDOFF_BRASKA_SUM_GROW_FINE_INDEXER_NEXT_2026-06-10.md`.

Leggi le note

SeymourBETA

Aggiornamento 2.63

10/06/2026

updateruntime-hook

Cocktail detail kind nello Spira Data Atlas (read-only, `proved-candidate`, value-guarded). Il primo ancoraggio Cocktail onesto nell'Atlas: nuovo `SpiraDataAtlasDetailKind.MixCombination` + accessor `SpiraDataAtlasCatalog.TryGetMixCombination(originIndex, partnerIndex, currentRawResult)` che collega il dataset parser-canonical `work/step0_consolidated_v5/mix_combinations.csv` (6,328 righe = 112×113/2, 0 chiavi duplicate) nel provider. `prepare.bin` è una matrice 112×112 lower-triangular (l'origine `O` porta risultati non-zero solo negli slot partner `0..O`), quindi ogni coppia non ordinata `{a,b}` vive in esattamente una cella canonica origin=max, partner=min; la chiave `mix:0x{0x2000+max}+0x{0x2000+min}` è ricostruibile dagli indici `(origin, partner)` dell'editor senza indovinare. `result_hex` è la STESSA word little-endian che l'editor legge come (letterale tecnico: SAME)`MixResultRow.RawResult` (reader editor byte-identical per `--mixtable-rt0`; parser stessa endianness) → value-guard = compare intero stesso-spazio: modificare l'esito rompe il match e nasconde il badge (nessuno stantio); una cella vuota (raw 0, incluso ogni mirror upper-triangle) fa short-circuit. (letterale tecnico: same-space) (letterale tecnico: short-circuits)SINGLE SOURCE: value-dict + dettaglio vengono dallo stesso CSV. Gate `--spiraatlas-rt0` `14891 → 21219` dettagli (+6,328 Cocktail; tutti unici) + 8 nuovi assert (count 6328; lookup 0+0→Ultrapozione `0x30AC`; ordine canonico `(3,1)==(1,3)`; value-guard `0x9999` nasconde; empty raw-0 miss; index out-of-range miss; domain search; BIBLE domain mix). Read-only: no writer/UI/runtime/SIN; non tocca l'editor Cocktail (writer), Treasure/Shop (RIKKU), il motore badge `Common` di ANIMA (consumato solo via search), o Aurora/Bahamut/native-menu. Sblocca backlog YUNA Q2 (era `blocked`). Il wiring badge UI = prossimo handoff (`docs/ai/HANDOFF_JECHT_MIX_ATLAS_PROVIDER_NEXT_2026-06-10.md`). Build 0 errori / 361 warning; `--spiraatlas-rt0` + `--aicmdmeta-rt0` PASS. Doc: `docs/ai/ATLAS_JECHT_MIX_DETAIL_KIND_SCOUT_RESULT_2026-06-10.md`. [precedente: `v2.62.1.1`] — Jarvis-JECHT

Leggi le note

SeymourBETA

Aggiornamento 2.62

09/06/2026

updateruntime-hook

Blitzball Prize Explorer: UI Atlas read-only dedicata. Nuovo modulo `Modules/BlitzballPrizeExplorer` (tab Blitzball Prizes 🏐 nel gruppo Reference/RE, nessun project gate) che consuma il catalogo già chiuso (letterale tecnico: already-closed)`SpiraDataAtlasCatalog.BlitzballPrizeDetails` (dominio `blitzball-prize`): una DataGrid ricercabile con colonne prize id · takara index · ricompensa risolta · kind · evidence, filtri status/evidence e kind, un banner con la REGOLA (letterale tecnico: RULE)`prize 0..100 -> takara 220..320 -> reward` (proved-candidate offline), e un pannello dettaglio con origin/rule/"where it appears"/limitations + `<common:AtlasEvidenceBadgeStrip>` (badge Atlas/BIBLE). Onestà preservata: treasure = `proved-candidate` (mai RT2); i 64 siti script league/tournament/evento mostrano esplicitamente (letterale tecnico: script-sites)`blocked` (il premio per-evento è runtime/save); tech = `partial`; overdrive = `metadata-only` — nulla diventa verde oltre l'etichetta corrente. Nuovo piccolo accessor read-only `SpiraDataAtlasCatalog.BlitzballPrizeDetails` (lazy, dev `work/` only) + 2 assert `--spiraatlas-rt0` (229 righe = 164 catalogo + 64 siti + 1 guardrail; domain check). Nessun writer, nessun runtime; non tocca RIKKU/Shop/Treasure/Cocktail, il motore `Common` di ANIMA (solo consumato), o Aurora/Bahamut/SIN. Build 0 errori / 361 warning; `--spiraatlas-rt0` + `--aicmdmeta-rt0` PASS. Doc: `docs/ai/ATLAS_WAKKA_BLITZBALL_UI_RESULT_2026-06-09.md`. [precedente: `v2.61.5`] — Jarvis-WAKKA

Leggi le note