SeymourBETA

Atualização 2.28

07/06/2026

v2.28.0BETA

Seymour

AURORA: ADD/REMOVE monstro WIRED INTO THE UI (botões na Aurora Chamber)

O GROW (v2.27.0) ganhou um front-end: orquestrador puro FfxLib/BattleMap/BattleArenaAuthor.cs que mantém chunk2 (formação) + chunk3 (âncoras) em lock-step + 2 botões na Aurora Chamber (➕ Add monster / ➖ Remove monster ao lado de "Save positions"). Modelo Two-regime: "add" usa uma âncora de arena reservada quando há headroom (formation-live < MonsterPositionCount) = só preencher o próximo slot de formação, chunk2-only, NO grow; senão cresce o chunk3 (regime 2, BattleArenaGrowWriter). O novo slot clona o último monstro vivo (espécie + a flag 0x1000); remove limpa o último slot vivo. Save Backup-once (.aurora.bak) + ReloadSelectedBattle. Gate BattleArenaGrowLab estendido (liga o autor): AUTHOR add 694/694 + remove 302/302 (re-decode limpo, slot clonado/limpo, formation-live ±1) em cima de RT0 700/700 + ADD 696/696 + REMOVE 393/393. O editor compila 0 erros (exe travado = editor rodando; build temp-output confirma). Doc atualizado FFX_AURORA_CHUNK3_PAYLOAD_MODEL_2026-06-07.md. Honesto: byte-safe offline; o jogo aceitar a nova contagem = RT2/probe (banner on-screen). UX: defina a espécie no Formation Editor + arraste a posição no MapViewer

v2.28.1BETA

Seymour

SPHERE GRID CANVAS: edição de topologia PROVADA NO JOGO (+300 HP) + polimento (tipo de nó por nome, ajuste ao espaçamento real, restauração/backup)

MARCO: o dono editou o grid Standard no Canvas (v2.25.0), salvou, e o FFX CARREGOU → NAVEGOU → ATIVOU um nó ADICIONADO (+300 HP aplicado ao personagem) — a ressalva "topologia editada no jogo = NÃO PROVADA" CAIU por terra na tela (o ciclo biblioteca comprovada → canvas → salvamento → engine real se fechou nas mãos do dono). Descoberta do engine em paralelo: o engine QUEBRA o grid se os nós ficarem próximos demais OU se os links se cruzarem (seguro offline em bytes ≠ seguro para o engine); o "tamanho real" do jogo original foi medido = espaçamento base ~43u (link médio ~77, dat01/02/03). Isso virou ferramenta: (1) snap-to-43 (um nó colocado/arrastado se ajusta à grade do jogo original; ativado por padrão, com um alternador); (2) aviso de proximidade em Validar (sinaliza se dois nós estiverem separados por < 40u = risco de quebra; é consultivo e não bloqueia a gravação segura em bytes); (3) um dropdown de TIPO DE NÓ por NOME (lê panel.bin via ReadNodeTypes → "Strength +1"/"HP +200"/"Lv.1 Lock"… em vez de hex; um nó FFh=sem tipo é renderizado como um bloqueio Lv.3 no jogo; agora é possível definir o tipo correto); (4) ♻️ Restaurar original (copia o grid do jogo original da referência extraída para o projeto = desfaz um salvamento que travou o jogo) + um backup automático .prev.bak antes de cada "Salvar no projeto". Compilação com 0 erros; o editor inicia sem travar. A descoberta da restrição de espaçamento foi salva na memória. Honestidade: a EDIÇÃO da topologia agora é PROVADA NO JOGO (carrega+ativa); o LIMITE (proximidade/cruzamento) é uma heurística medida, não o teto exato do engine — refinar com mais testes/RE (a detecção de cruzamento de links é trabalho futuro)

v2.28.0

Voltar para atualizações

SeymourBETA

Atualização 2.28

07/06/2026

v2.28.0BETA

Seymour

AURORA: ADD/REMOVE monstro WIRED INTO THE UI (botões na Aurora Chamber)

O GROW (v2.27.0) ganhou um front-end: orquestrador puro FfxLib/BattleMap/BattleArenaAuthor.cs que mantém chunk2 (formação) + chunk3 (âncoras) em lock-step + 2 botões na Aurora Chamber (➕ Add monster / ➖ Remove monster ao lado de "Save positions"). Modelo Two-regime: "add" usa uma âncora de arena reservada quando há headroom (formation-live < MonsterPositionCount) = só preencher o próximo slot de formação, chunk2-only, NO grow; senão cresce o chunk3 (regime 2, BattleArenaGrowWriter). O novo slot clona o último monstro vivo (espécie + a flag 0x1000); remove limpa o último slot vivo. Save Backup-once (.aurora.bak) + ReloadSelectedBattle. Gate BattleArenaGrowLab estendido (liga o autor): AUTHOR add 694/694 + remove 302/302 (re-decode limpo, slot clonado/limpo, formation-live ±1) em cima de RT0 700/700 + ADD 696/696 + REMOVE 393/393. O editor compila 0 erros (exe travado = editor rodando; build temp-output confirma). Doc atualizado FFX_AURORA_CHUNK3_PAYLOAD_MODEL_2026-06-07.md. Honesto: byte-safe offline; o jogo aceitar a nova contagem = RT2/probe (banner on-screen). UX: defina a espécie no Formation Editor + arraste a posição no MapViewer

v2.28.1BETA

Seymour

SPHERE GRID CANVAS: edição de topologia PROVADA NO JOGO (+300 HP) + polimento (tipo de nó por nome, ajuste ao espaçamento real, restauração/backup)

MARCO: o dono editou o grid Standard no Canvas (v2.25.0), salvou, e o FFX CARREGOU → NAVEGOU → ATIVOU um nó ADICIONADO (+300 HP aplicado ao personagem) — a ressalva "topologia editada no jogo = NÃO PROVADA" CAIU por terra na tela (o ciclo biblioteca comprovada → canvas → salvamento → engine real se fechou nas mãos do dono). Descoberta do engine em paralelo: o engine QUEBRA o grid se os nós ficarem próximos demais OU se os links se cruzarem (seguro offline em bytes ≠ seguro para o engine); o "tamanho real" do jogo original foi medido = espaçamento base ~43u (link médio ~77, dat01/02/03). Isso virou ferramenta: (1) snap-to-43 (um nó colocado/arrastado se ajusta à grade do jogo original; ativado por padrão, com um alternador); (2) aviso de proximidade em Validar (sinaliza se dois nós estiverem separados por < 40u = risco de quebra; é consultivo e não bloqueia a gravação segura em bytes); (3) um dropdown de TIPO DE NÓ por NOME (lê panel.bin via ReadNodeTypes → "Strength +1"/"HP +200"/"Lv.1 Lock"… em vez de hex; um nó FFh=sem tipo é renderizado como um bloqueio Lv.3 no jogo; agora é possível definir o tipo correto); (4) ♻️ Restaurar original (copia o grid do jogo original da referência extraída para o projeto = desfaz um salvamento que travou o jogo) + um backup automático .prev.bak antes de cada "Salvar no projeto". Compilação com 0 erros; o editor inicia sem travar. A descoberta da restrição de espaçamento foi salva na memória. Honestidade: a EDIÇÃO da topologia agora é PROVADA NO JOGO (carrega+ativa); o LIMITE (proximidade/cruzamento) é uma heurística medida, não o teto exato do engine — refinar com mais testes/RE (a detecção de cruzamento de links é trabalho futuro)

v2.28.0