SeymourBETAAtualização 2.23
07/06/2026
v2.23.0BETA
Seymour
SeymourSPELL NAME nos viewers de magia (PS3 Magic HD): join best-effort (owner-authorized)
- O dono mandou mostrar o nome mesmo sem o join byte-proven ("agora é pra fazer caralho", 2026-06-07 — um override explícito da regra no-fabricate). Novo
MagicSpellNameResolver(FfxLib/Dictionaries): magic_#### (id 0..1023, 12-bit) → tentaCommandCharacter→CommandMonster1→CommandMonster2→Item(todosDictionary<ushort,string>), retornaname ~source(e.g.Firaga ~char-cmd) oumagic_####quando não mapeado. Ligado em PS3 Magic (HD) (Ps3MagicBrowser):Ps3MagicEntry.SpellNameDisplayvira o título da lista + header do detalhe, e a busca casa por nome. Honesto: o~sourceo marca como hipótese NON-byte-proven (o catálogo diz "nomes não provados"); o dono verifica na tela e refinamos o offset/dict se algum nome estiver errado. Build 0 erros
v2.22.0
v2.23.1BETASeymour
SeymourFormation Editor: slots pre-filled agora SHOW o nome do monstro (fix de display no load)
- O dono flagrou que os 8 slots de formação abriam com um EMPTY ComboBox para slots que já tinham valor (10DEh/10E2h crus) — o nome só aparecia AFTER ao escolher manualmente (mesmo os slots FFFFh vazios mostravam em branco em vez de "(Vazio)"). Causa: uma pegadinha do Avalonia — o
SelectedItemsetado no load (object initializer) é aplicado antes de os per-row ComboBoxes materializarem seusItemsSource(bound via RelativeSource), então a seleção não resolve e fica em branco. Fix: após popularSlots, re-apply cadaSelectedMonster(toggle null→value) numDispatcher.UIThread.Post(..., Background)para o ComboBox re-resolves contra uma lista de Items populada. Guardado porslotsSyncingpara não marcar dirty (load fica "Changed: false" até uma edição real). Build 0 erros
v2.23.0
v2.23.2BETASeymour
SeymourAurora: "Reload battle de disk" (reflete saves de outros módulos no mapa)
- O dono editou a formação no Formation Editor e os monstros não apareceram no mapa da Aurora. Investigação: o pipeline está correto — a Aurora liga
formation slot[i] → monster-live anchor[i]comMonsterId/Model(/work/phyre_chr_anim/models/mNNN/mNNN_animated.gltf, 340 modelos HD existem, server-root URL certo). A causa era estado em cache:RefreshCatalogrecarrega só a lista de cenas, NOT os bytes da batalha aberta — então uma edição de formação feita em outro lugar não refletiria até re-selecting. Fix: novoReloadSelectedBattle()(re-fires a leitura da batalha = re-reads formação do chunk2 + âncoras do chunk3 do disco) + um botão "🔄 Reload battle de disk" ao lado de "Render". (O Battle Explorer já tinha "Refresh" + recria fresco a cada nav — A já estava lá para ele.) A causa raiz combinada de "Changed: False" + "sem monstros no mapa" era o save de formação não persistindo — corrigido em v2.23.1 (combo-blank). Build 0 erros
v2.23.1
v2.23.3BETASeymour
SeymourFormation Editor: um monstro ADDED num slot vazio agora herda a flag "live on field"
- O dono adicionou monstros aos slots 04-07 e eles não eram reconhecidos como vivos (Aurora "só 4 monstros vivos"). Prova On-screen: os slots originais (00-03) carregam
10DEh/10E2hcrus (nibble alto0x1000); os adicionados saíram0030h/0136h(nibble alto0x0000).0x1000é a flag ACTIVE-formation-monster — o writer carimbou0ao preencher um slot que estavaFFFFh. Fix (FormationSlotRow): ao preencher um slot vazio, herdar o nibble alto de um slot vivo SIBLING da mesma batalha (per-battle, sem adivinhar; default0x1000se a formação estava totalmente vazia). Ainda slot-only byte-safe (gate FormationSlotLab 858/858). Diagnóstico extra (NOT um bug save-side): save e read usam o caminho SAME (GetPathBattle); o problema era o VALUE, não o lado. Honesto: (1)0x1000=live é uma hipótese evidence-based da prova on-screen — teste in-game; (2) a MAP da Aurora só tem as âncoras de monstro que o ARENA (chunk3) define (e.g. 4) — adicionar um monstro além disso precisa de uma âncora de arena nova (autoria de arena = fora do escopo deste fix). Build 0 erros
v2.23.2