SeymourBETA

Update 2.28

7.6.2026

v2.28.0BETA

Seymour

AURORA: Monster HINZUFÜGEN/ENTFERNEN IN DIE UI EINGEBUNDEN (Buttons in der Aurora Chamber)

Der GROW (v2.27.0) bekam ein Frontend: reiner Orchestrator FfxLib/BattleMap/BattleArenaAuthor.cs, der chunk2 (Formation) + chunk3 (Anchors) synchron hält + 2 Buttons in der Aurora Chamber (➕ Add monster / ➖ Remove monster neben "Save positions"). Zwei-Regime-Modell: "add" verwendet einen reservierten Arena-Anker, wenn Headroom besteht (formation-live < MonsterPositionCount) = einfach den nächsten Formations-Slot füllen, nur chunk2, KEIN grow; sonst wächst chunk3 (Regime 2, BattleArenaGrowWriter). Der neue Slot klont das letzte Live-Monster (Spezies + das 0x1000-Flag); remove leert den letzten Live-Slot. Backup-once-Save (.aurora.bak) + ReloadSelectedBattle. Gate BattleArenaGrowLab erweitert (verbindet den Author): AUTHOR add 694/694 + remove 302/302 (sauberes Re-Dekodieren, Slot geklont/geleert, formation-live ±1) auf Basis von RT0 700/700 + ADD 696/696 + REMOVE 393/393. Editor kompiliert mit 0 Fehlern (gelockte exe = Editor läuft; Temp-Output-Build bestätigt). Doc aktualisiert FFX_AURORA_CHUNK3_PAYLOAD_MODEL_2026-06-07.md. Ehrlich: offline byte-sicher; dass das Spiel die neue Anzahl akzeptiert = RT2/probe (On-Screen-Banner). UX: Spezies im Formation-Editor setzen + Position im MapViewer ziehen

v2.28.1BETA

Seymour

SPHERE-GRID-CANVAS: Topologie-Bearbeitung IM SPIEL BEWIESEN (+300 HP) + Polish (Knotentyp per Name, Snap auf echtes Raster, Restore/Backup)

MEILENSTEIN: Der Eigentümer bearbeitete das Standard-Grid im Canvas (v2.25.0), speicherte, und FFX LUD → NAVIGIERTE → AKTIVIERTE einen HINZUGEFÜGTEN Knoten (+300 HP auf den Charakter angewendet) — der Vorbehalt "bearbeitete Topologie im Spiel = UNBEWIESEN" fiel auf dem Bildschirm (die bewiesene Lib → Canvas → Save → echte Engine-Schleife schloss sich in den Händen des Eigentümers). Engine-Entdeckung nebenbei: Die Engine BRIHT das Grid, wenn Knoten zu dicht beieinander liegen ODER Links sich kreuzen (offline-byte-sicher ≠ engine-sicher); die vanillane "echte Größe" gemessen = Basis-Abstand ~43u (Ø-Link ~77, dat01/02/03). Daraus wurde Tooling: (1) Snap-to-43 (ein platzierter/gezogener Knoten snappt auf das vanillane Raster; standardmäßig an, mit Toggle); (2) Proximity-Warnung in Validate (flaggt, wenn zwei Knoten < 40u auseinander liegen = Bruchrisiko; advisory, blockt den byte-sicheren Write nicht); (3) ein KNOTENTYP-Dropdown per NAME (liest panel.bin via ReadNodeTypes → "Strength +1"/"HP +200"/"Lv.1 Lock"… statt Hex; ein FFh=kein-Typ-Knoten rendert in-game als Lv.3-Lock, jetzt kann man den richtigen Typ setzen); (4) ♻️ Restore original (kopiert das vanillane Grid aus der extrahierten Referenz ins Projekt = einen Save rückgängig machen, der das Spiel crashte) + automatisches .prev.bak-Backup vor jedem "Im Projekt speichern". Build 0 Fehler; Editor startet ohne Crash. Die Spacing-Constraint-Entdeckung ist im Speicher gespeichert. Ehrlich: Topologie-BEARBEITUNG ist jetzt im Spiel bewiesen (lädt+aktiviert); die GRENZE (Proximity/Kreuzung) ist eine gemessene Heuristik, nicht die exakte Obergrenze der Engine — mit mehr Tests/RE verfeinern (Link-Kreuzungs-Erkennung ist Zukunftsarbeit). [previous: v2.28.0]

Zurück zu Updates

SeymourBETA

Update 2.28

7.6.2026

v2.28.0BETA

Seymour

AURORA: Monster HINZUFÜGEN/ENTFERNEN IN DIE UI EINGEBUNDEN (Buttons in der Aurora Chamber)

Der GROW (v2.27.0) bekam ein Frontend: reiner Orchestrator FfxLib/BattleMap/BattleArenaAuthor.cs, der chunk2 (Formation) + chunk3 (Anchors) synchron hält + 2 Buttons in der Aurora Chamber (➕ Add monster / ➖ Remove monster neben "Save positions"). Zwei-Regime-Modell: "add" verwendet einen reservierten Arena-Anker, wenn Headroom besteht (formation-live < MonsterPositionCount) = einfach den nächsten Formations-Slot füllen, nur chunk2, KEIN grow; sonst wächst chunk3 (Regime 2, BattleArenaGrowWriter). Der neue Slot klont das letzte Live-Monster (Spezies + das 0x1000-Flag); remove leert den letzten Live-Slot. Backup-once-Save (.aurora.bak) + ReloadSelectedBattle. Gate BattleArenaGrowLab erweitert (verbindet den Author): AUTHOR add 694/694 + remove 302/302 (sauberes Re-Dekodieren, Slot geklont/geleert, formation-live ±1) auf Basis von RT0 700/700 + ADD 696/696 + REMOVE 393/393. Editor kompiliert mit 0 Fehlern (gelockte exe = Editor läuft; Temp-Output-Build bestätigt). Doc aktualisiert FFX_AURORA_CHUNK3_PAYLOAD_MODEL_2026-06-07.md. Ehrlich: offline byte-sicher; dass das Spiel die neue Anzahl akzeptiert = RT2/probe (On-Screen-Banner). UX: Spezies im Formation-Editor setzen + Position im MapViewer ziehen

v2.28.1BETA

Seymour

SPHERE-GRID-CANVAS: Topologie-Bearbeitung IM SPIEL BEWIESEN (+300 HP) + Polish (Knotentyp per Name, Snap auf echtes Raster, Restore/Backup)

MEILENSTEIN: Der Eigentümer bearbeitete das Standard-Grid im Canvas (v2.25.0), speicherte, und FFX LUD → NAVIGIERTE → AKTIVIERTE einen HINZUGEFÜGTEN Knoten (+300 HP auf den Charakter angewendet) — der Vorbehalt "bearbeitete Topologie im Spiel = UNBEWIESEN" fiel auf dem Bildschirm (die bewiesene Lib → Canvas → Save → echte Engine-Schleife schloss sich in den Händen des Eigentümers). Engine-Entdeckung nebenbei: Die Engine BRIHT das Grid, wenn Knoten zu dicht beieinander liegen ODER Links sich kreuzen (offline-byte-sicher ≠ engine-sicher); die vanillane "echte Größe" gemessen = Basis-Abstand ~43u (Ø-Link ~77, dat01/02/03). Daraus wurde Tooling: (1) Snap-to-43 (ein platzierter/gezogener Knoten snappt auf das vanillane Raster; standardmäßig an, mit Toggle); (2) Proximity-Warnung in Validate (flaggt, wenn zwei Knoten < 40u auseinander liegen = Bruchrisiko; advisory, blockt den byte-sicheren Write nicht); (3) ein KNOTENTYP-Dropdown per NAME (liest panel.bin via ReadNodeTypes → "Strength +1"/"HP +200"/"Lv.1 Lock"… statt Hex; ein FFh=kein-Typ-Knoten rendert in-game als Lv.3-Lock, jetzt kann man den richtigen Typ setzen); (4) ♻️ Restore original (kopiert das vanillane Grid aus der extrahierten Referenz ins Projekt = einen Save rückgängig machen, der das Spiel crashte) + automatisches .prev.bak-Backup vor jedem "Im Projekt speichern". Build 0 Fehler; Editor startet ohne Crash. Die Spacing-Constraint-Entdeckung ist im Speicher gespeichert. Ehrlich: Topologie-BEARBEITUNG ist jetzt im Spiel bewiesen (lädt+aktiviert); die GRENZE (Proximity/Kreuzung) ist eine gemessene Heuristik, nicht die exakte Obergrenze der Engine — mit mehr Tests/RE verfeinern (Link-Kreuzungs-Erkennung ist Zukunftsarbeit). [previous: v2.28.0]