Tem o save dessa parte ae?

Eu acho que eu tinha esse bug fix.
Essa tradução era da BRGames?

Citação de: Dindo online Agosto 03, 2026, 16:38:15 PM

Citação de: ØX-Carnage online Agosto 03, 2026, 00:46:12 AMBoa, Dindo! Ficou muito bom, mano. Já baixei e entrou para a lista da preguiça kkk.

Uma dúvida, por que não traduziu o subtítulo também?

É um gráfico bem complexo, e eu sou péssimo com gráficos rsrs

Os dois gráficos iniciais estão no mesmo recurso comprimido uma variante de LZSS/LZ, ID 0x03F:
Eles são armazenados como um único arquivo comprimido.
[2 bytes] tamanho descomprimido, little-endian
[1 byte ] máscara inicial de controle
[dados  ] literais e referências ao conteúdo já descomprimido

• Tabela de arquivos: 0x138000
• Entrada do recurso: 0x1380BD
• Bloco comprimido: 0x14586F–0x1460D0
• Tamanho comprimido: 2.146 bytes
• Tamanho descomprimido: 6.672 bytes

Estrutura dos graficos são:

Tilemap: 32 × 28, 1.792 bytes
Gráficos: 150 tiles SNES 4bpp, 4.800 bytes
Paleta: 32 cores BGR555, 64 bytes

 

Parabéns, Dindo! Gostei muito dessa fonte, e a acentuação ficou bem alinhada.

Com certeza vai estar na minha lista da preguiça. Show!

Parabéns, mano! Eu não sou muito fã de dublagens. Não sei se a equipe é amadora ou profissional, mas essa ficou bem legal. Nos primeiros minutos de jogo, vi que a sincronização ficou muito boa, assim como as vozes escolhidas, e o narrador leu muito bem o roteiro.

Esse projeto merece uma atenção maior. Já está na minha lista da preguiça...

Boa, Dindo! Ficou muito bom, mano. Já baixei e entrou para a lista da preguiça kkk.

Uma dúvida, por que não traduziu o subtítulo também?

Show, Sólido! Ficou muito bom, baixei aqui e já estou jogando. Mesmo não gostando dessa série, a tradução me faz querer jogar...   
Já pensou em traduzir o subtitulo Battle Network?

Por isso que a galera não ajuda.
O cara pede ajuda, já tem a Tool pronta e some 

Explicação completa de como funciona essa rom.
Como o jogo escolhe e monta as perguntas e respostas

Durante a análise da ROM, descobri que as perguntas não estão armazenadas como frases completas.

O jogo utiliza três estruturas principais:

• Um dicionário contendo palavras e sinais de pontuação.
• Registros formados por índices que apontam para esse dicionário.
• Uma tabela com os offsets de cada registro de pergunta.

---

1) O dicionário de palavras

O dicionário começa em:

0x79D58C

As palavras ficam concatenadas, sem um byte de final de string entre elas.

Exemplo:

theofJesuswasTheJohnMatthewto...

Mas existe uma tabela separada que informa onde cada palavra começa e termina.

Essa tabela começa em:

0x7A328C

Cada entrada é um offset relativo de 16 bits.

Exemplo:

0x000E até 0x0011 = "the"
0x0011 até 0x0013 = "of"
0x0013 até 0x0018 = "Jesus"
0x0018 até 0x001B = "was"

A fórmula utilizada é:

Endereço da palavra = base do dicionário + offset relativo

Ou seja:

Endereço da palavra = 0x79D58C + offset


---

2) Como uma frase é armazenada

Uma pergunta como:

What is the first word of the Bible?

não aparece dessa forma no bloco principal de perguntas.

Ela é armazenada como uma sequência de índices:

18 30 0E 27 70 0F 0E 81 1E 01

Interpretando os índices:

18      = What
30      = is
0E      = the
27      = first
70      = word
0F      = of
0E      = the
81 1E  = Bible
01      = ?

Depois de consultar o dicionário, o jogo monta:

What is the first word of the Bible?

Índices menores que `0x80` utilizam um byte.

Exemplo:

What = índice 0x0018

Na frase:
18

Índices maiores utilizam dois bytes.

Exemplo:

Bible = índice 0x011E

Na frase:
81 1E

O primeiro byte recebe o bit `0x80`, indicando que existe um segundo byte.

---

3) Estrutura de cada registro

Cada registro pode conter:

• A pergunta.
• A resposta correta.
• As alternativas erradas.
• A referência bíblica.
• A explicação mostrada depois da resposta.

O formato lógico é aproximadamente:

Pergunta
Resposta correta
Alternativas erradas
Referência
Explicação

As alternativas erradas ficam agrupadas em um campo e são separadas internamente por um índice especial.

Na Tool criada, isso é apresentado de forma legível:

▶ 118 (quiz)

{question}
At the feeding of the five thousand, who had the 5 loaves of bread and 2 fish?

{answers}
A lad
Andrew
Mary Magdalene
A young woman

{reference}
John 6:9

{explanation}
At the feeding of the five thousand, it was a lad who had the 5 loaves of bread and 2 fish.

Dentro de `{answers}`:

Primeira linha  = resposta correta
Linhas seguintes = respostas erradas

Assim, quando for traduzir não precisa editar índices manualmente.

O `insert.py` transforma novamente as frases completas em sequências de índices.

---

4) Tabela de offsets das perguntas

O bloco principal dos registros começa em:

0x7A5172

A tabela de offsets começa em:

0x7CF014

Cada entrada da tabela possui quatro bytes e informa o deslocamento de uma pergunta em relação à base do bloco.

A fórmula é:

Endereço do registro =
base das perguntas + offset da tabela

Exemplo:

ID da pergunta: 118
Offset relativo: valor armazenado na tabela
Base: 0x7A5172

Endereço final:
0x7A5172 + offset relativo

A rotina responsável por localizar e montar o registro é chamada a partir da região:

0x080001F4

Ela recebe o ID da pergunta, consulta a tabela de offsets e encontra o registro correspondente.

---

5) Como o jogo escolhe qual pergunta será exibida

O jogo não lê simplesmente as 2.438 perguntas em ordem.

Também não faz um sorteio completamente novo entre todas as perguntas sempre que precisa mostrar uma.

O sistema funciona como um baralho dividido em grupos.

Existe uma tabela próxima de:

0x7A5152

Ela divide as perguntas em faixas.

Foi identificado 16 grupos.

Grupo 00: perguntas    0–150
Grupo 01: perguntas  151–386
Grupo 02: perguntas  387–621
Grupo 03: perguntas  622–872
Grupo 04: perguntas  873–1101
Grupo 05: perguntas 1102–1209
Grupo 06: perguntas 1210–1213
Grupo 07: perguntas 1214–1218

Os grupos seguintes formam uma segunda coleção com registros correspondentes aos primeiros grupos.

O jogo mantém os grupos separados. Uma pergunta pertencente a uma faixa não é misturada com as perguntas das outras faixas.

---

6) Criação da lista de IDs

Ao preparar o sistema de perguntas, uma rotina próxima de:

0x08000550

cria na RAM uma lista com os IDs:

0, 1, 2, 3, 4, 5 ... 2437

A lista fica em uma estrutura apontada na região:

0x03003C0C

Depois, cada grupo é embaralhado separadamente.

Exemplo:

Antes:

151, 152, 153, 154, 155, 156

Depois:

154, 151, 156, 153, 152, 155

O embaralhamento altera a ordem das perguntas, mas não move uma pergunta para outro grupo.

---

7) O jogo utiliza as perguntas como um baralho

Depois que uma faixa foi embaralhada, o jogo utiliza os IDs em sequência.

Exemplo:

Lista embaralhada:

118, 72, 145, 3, 94

As próximas perguntas serão:

Primeira chamada:  118
Segunda chamada:    72
Terceira chamada:  145
Quarta chamada:      3
Quinta chamada:     94

Portanto, o jogo não precisa sortear novamente todos os IDs a cada pergunta.

Ele consulta a próxima posição da lista embaralhada e avança o contador daquele grupo.

Os contadores ficam em uma estrutura próxima de:

0x03003C20

Quando o contador chega ao final da faixa, ele volta ao início correspondente.

Esse sistema diminui a possibilidade de uma pergunta se repetir imediatamente.

---

8) Como o grupo é escolhido

Quando o jogo precisa mostrar uma pergunta, ele primeiro verifica o estado atual da partida.

Duas rotinas relacionadas a essa seleção foram encontradas:

0x08000748
0x08000810

A lógica geral é:

• Identificar o grupo ativo.
• Consultar o contador atual daquele grupo.
• Obter o próximo ID na lista embaralhada.
• Avançar o contador.
• Enviar o ID escolhido para a rotina que monta o registro.

A variável exata que determina cada grupo depende do estado do jogo. Pode envolver o modo, a localização ou o progresso atual.

---

9) Montagem do texto na RAM

Depois que o ID foi escolhido, a rotina faz:

• Consulta o offset correspondente ao ID.
• Calcula o endereço do registro.
• Lê a quantidade de índices do campo.
• Lê cada índice do dicionário.
• Localiza a palavra correspondente.
• Copia os caracteres para um buffer na RAM.
• Acrescenta espaços quando necessário.
• Finaliza a string com `00`.

Isso é repetido para:

Pergunta
Resposta correta
Alternativas erradas
Referência
Explicação

A ROM só possui os índices. A frase completa é reconstruída na RAM durante a execução.

---

10) Validação da pergunta escolhida

Existe ainda um pequeno loop de validação próximo na região:

0x080017B0–0x080017E0

Depois de montar a pergunta, o jogo verifica se o texto resultante está vazio.

A lógica é aproximadamente:

Escolher ID
    |
    v
Montar pergunta
    |
    v
A pergunta está vazia?
    |
    +-- Sim --> escolher outro ID
    |
    +-- Não --> mostrar na tela

Isso impede que um registro vazio seja exibido ao jogador.

---

11) Resumo em pseudocódigo

Ao iniciar o sistema de perguntas:

    criar uma lista com IDs de 0 até 2437

    para cada grupo:
        embaralhar os IDs da faixa
        posicionar o contador no início


Quando precisar mostrar uma pergunta:

    grupo = calcular_grupo_pelo_estado_do_jogo

    posição = contador_do_grupo

    id = lista_embaralhada[posição]

    avançar contador_do_grupo

    se chegou ao final da faixa:
        voltar ao início da faixa

    offset = tabela_de_offsets[id]

    registro = base_das_perguntas + offset

    montar:
        pergunta
        respostas
        referência
        explicação

    se a pergunta estiver vazia:
        escolher outra
    senão:
        mostrar a pergunta


---

Bom foi isso. O jogo usa um sistema muito interessante, é como se fosse um cardeado a cada rodada embaralha as perguntas e respostas.

9. Outros métodos disponíveis

Nem todo projeto precisa de um Vault complexo ou de múltiplos agentes.

• Chat + arquivos anexados: suficiente para uma tarefa curta e descartável. Fraco para projetos longos.
• Um único agente com ferramentas: geralmente é o melhor começo. Menos custo e menos coordenação; pode ganhar papéis internos antes de virar multiagente real.
• RAG vetorial clássico: útil quando há muitos documentos e perguntas semânticas. Exige cuidado com chunking, metadados, atualização, reranking e avaliação.
• GraphRAG / grafo de conhecimento: interessante quando relações entre entidades importam mais que simples proximidade textual. Pode ser valioso para personagens, itens, rotinas, ponteiros e dependências, mas custa mais para indexar e manter.
• Contexto longo: bom para uma auditoria pontual de poucos arquivos. Não substitui memória persistente nem resolve conhecimento desatualizado.
• Fine-tuning: pode ensinar estilo ou comportamento recorrente, mas é inadequado como banco de offsets, decisões mutáveis e estado atual do projeto.
• Automação determinística sem agente: indispensável para hashes, ponteiros, tags, tamanhos, round-trip, compressão e comparação binária. Muitas verificações ficam melhores em Python do que em linguagem natural.
• LLM Wiki: indicada quando o conhecimento precisa acumular, ser legível por humanos, versionado e adaptado ao projeto.

A escolha foi híbrida: LLM Wiki para memória, busca/RAG para recuperar contexto, agentes para dividir responsabilidades e scripts/testes para provar o resultado.

---

10. Uma versão simplificada para começar

Quem está criando um editor ou mod, como no caso mencionado de Gantz, não precisa começar com três agentes reais nem instalar infraestrutura pesada. Uma estrutura mínima já entrega boa parte do valor:

meu-projeto/
├── AGENTS.md
├── raw/
│  ├── dumps/
│  ├── screenshots/
│  └── logs/
├── wiki/
│  ├── index.md
│  ├── visao-geral.md
│  ├── formato-texto.md
│  ├── ponteiros.md
│  ├── graficos-paletas.md
│  ├── decisoes.md
│  └── qa.md
├── tools/
│  ├── extract.py
│  └── insert.py
└── tests/

No [tt]AGENTS.md[/tt], registre poucas regras fortes:

• consultar a wiki antes de afirmar algo;
• não chutar endereços ou formatos;
• preservar [tt]raw/[/tt];
• registrar somente descobertas confirmadas;
• validar contra ROM limpa e teste reproduzível;
• pedir decisão humana antes de alterações sensíveis.

Comece com um agente operador. Crie um segundo papel de QA quando perceber que a produção precisa de uma revisão independente. Transforme os papéis em agentes reais somente quando a separação trouxer ganho mensurável.

---

11. Como decidir se essa estrutura serve para você

Vale a pena quando:

• o projeto vai durar meses ou anos;
• há muitas decisões técnicas e linguísticas;
• várias ferramentas ou plataformas precisam permanecer coerentes;
• é importante explicar por que cada decisão foi tomada;
• o trabalho precisa continuar em novas sessões sem depender da memória do chat;
• existem testes objetivos capazes de bloquear erros.

Talvez seja exagero quando:

• a tarefa é pequena e descartável;
• não existe fonte confiável para alimentar o cérebro;
• ninguém vai manter decisões e evidências atualizadas;
• o custo de orquestrar agentes supera o trabalho manual;
• o projeto espera que a IA substitua testes, conhecimento técnico ou responsabilidade humana.

CitarA melhor arquitetura não é a que possui mais agentes. É a menor arquitetura capaz de preservar conhecimento, impedir erros e produzir um resultado verificável.

---

Conclusão

Usar IA em romhacking não precisa significar entregar a tradução ou a engenharia reversa a uma caixa-preta. É possível trabalhar de forma transparente: fontes preservadas, conhecimento compilado, papéis delimitados, aprovação humana, scripts determinísticos e testes no jogo.

O Obsidian oferece uma interface confortável; o Markdown garante portabilidade; o método LLM Wiki transforma conversas em memória acumulativa; RAG recupera o contexto; agentes distribuem responsabilidades; e QA impede que uma resposta convincente seja confundida com uma descoberta comprovada.

Foi assim que o cérebro do Wild Arms passou a orientar tradução, voz, lore e estrutura, enquanto o Romhack_Brain acumulou conhecimento técnico reutilizável entre projetos. A estrutura ainda evolui, mas sua regra principal permanece estável:

---

Referências

• Andrej Karpathy — LLM Wiki
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• RAGAS — Automated Evaluation of Retrieval-Augmented Generation
• Microsoft GraphRAG
• Strands Agents — padrões multiagente
• Strands Agents — Agents as Tools
• Tópico do projeto Wild Arms

Bom espero que tenham gostado, deu um trabalho para fazer.
E agradeço a todos que mandam DM e comentaram nos posts sobre o assunto. E não esqueçam IA só vai trabalhar bem se você souber o que esta fazendo.

<<Página 1

Devido à limitação de caracteres esse artigo foi divido em duas partes.

CitarA IA não substitui o romhacker. Ela se torna realmente útil quando recebe memória persistente, fontes verificáveis, regras técnicas, ferramentas e critérios objetivos para saber quando deve parar.

Objetivo e finalidade do artigo

O objetivo deste artigo é apresentar uma estrutura prática para usar IA em projetos longos de romhacking e localização: um cérebro persistente no Obsidian, recuperação de conhecimento, agentes especializados, ferramentas determinísticas, revisão humana e QA reproduzível.

Sua finalidade é ajudar cada romhacker a decidir se essa arquitetura serve para o próprio projeto, quais partes adotar e o que pode ser simplificado. Para isso, serão usados dois projetos independentes como exemplos: o cérebro especializado da tradução de Wild Arms e o Romhack_Brain, criado para acumular conhecimento técnico de múltiplos jogos e plataformas.

Ao final, você deverá entender o que o método resolve, o que ele não resolve, como começar com uma versão mínima e quando RAG, LLM Wiki, múltiplos agentes ou automação tradicional fazem sentido.

Não é uma promessa de tradução automática perfeita nem um argumento de que programação deixou de ser necessária. É um relato sobre como transformar uma IA que apenas conversa em uma operadora assistida por conhecimento, evidências e validações reproduzíveis.

---

1. O problema: o chat não é memória de projeto

Uma conversa com uma IA pode produzir uma boa análise hoje e contradizê-la amanhã. O contexto acaba, a sessão muda e decisões importantes ficam soterradas no histórico. Em romhacking isso é especialmente perigoso: um endereço errado, uma suposição sobre ponteiros, uma tag alterada ou uma paleta recomposta incorretamente pode inutilizar horas de trabalho.

Por isso adotei uma regra simples:


Termos aprovados, descobertas técnicas, evidências de diversos idiomas, formatos de gráficos, decisões de tom, resultados de QA e falhas encontradas no emulador precisam sair da conversa e entrar em arquivos versionados.

---

2. O que eu chamdo de "cérebro"

Nos projetos atuais, o cérebro é um Vault no meu caso uso o Obsidian formado principalmente por arquivos Markdown. O Obsidian é a interface para navegar, pesquisar e visualizar as relações; a inteligência não está presa ao aplicativo. Os arquivos continuam legíveis por qualquer editor, script, Git ou agente com acesso ao sistema de arquivos.

A adaptação usa três camadas:

• Raw: fontes brutas e evidências preservadas. Dumps, logs, screenshots, referências, saídas de ferramentas e decisões ainda não consolidadas.
• Wiki: conhecimento compilado. Glossários, regras, perfis de personagens, formatos técnicos, relatórios, páginas por projeto e decisões já validadas.
• Schema: o contrato operacional. Um [tt]AGENTS.md[/tt] e notas de agentes/regras dizem o que deve ser lido, o que pode ser alterado, como validar e quando pedir aprovação humana.

O ponto importante é o retorno: uma descoberta confirmada durante a execução volta para a wiki. Assim, o projeto acumula conhecimento em vez de reconstruí-lo a cada pergunta, ou seja vira um conhecimento orgânico.

---

3. Dois projetos independentes, dois tipos de cérebro

O Romhack_Brain e o cérebro do Wild Arms não formam uma hierarquia e um não depende do outro. São dois projetos independentes que aplicam princípios parecidos de memória persistente, fontes, schema e validação, mas foram criados para finalidades diferentes.

Romhack_Brain: projeto abrangente e multiplataforma

O Romhack_Brain foi criado para reunir conhecimento reutilizável entre vários jogos e plataformas. Ele documenta ponteiros, gráficos, paletas, atlas, compressões, assembly, ferramentas, checklists, decisões e páginas próprias de projetos para NES, Mega Drive, Dreamcast e outras plataformas conforme forem incorporadas.

Ele não traduz um único jogo. Seu papel é evitar que uma descoberta feita em um projeto desapareça ou precise ser redescoberta no próximo. Uma técnica de tilemap, um formato de ponteiro ou um cuidado de round-trip pode virar conhecimento reaproveitável, sempre mantendo separadas as particularidades de cada ROM. E com isso os agentes vão pegando padrões de cada console e entendendo o que fazer e como fazer.


No Romhack_Brain: três estruturas independentes de edição da ROM

Nos projetos documentados pelo Romhack_Brain, procuro oferecer três rotas diferentes para editar e reconstruir a ROM. Elas compartilham o conhecimento técnico já mapeado, mas não são a mesma ferramenta e nenhuma deve ser tratada como uma pasta da outra.

1. BASS — projeto ASM montável

BASS é a rota de baixo nível. O projeto mantém módulos ASM para constantes, macros, ponteiros, hooks, patches e rotinas novas, além de textos, tabelas de caracteres, gráficos e um processo de build. O BASS monta essas definições sobre a ROM-base e produz uma nova ROM reproduzível.

É a rota mais transparente para quem quer estudar ou modificar profundamente a engine: o romhacker enxerga endereços, desvios, repointing e alterações binárias de forma explícita. Também exige maior domínio técnico e não depende de interface gráfica.

2. Python — extract, insert e validate

Python é a rota de automação standalone. Os scripts leem a ROM, extraem textos e gráficos para formatos editáveis, geram metadata técnica, aplicam traduções, recalculam ponteiros, recomprimem dados, validam round-trip e criam uma ROM de saída.

O fluxo Python mantém sua própria estrutura, normalmente com JSON, PNG, BIN e [tt]metadata/[/tt]. Ele pode funcionar sem BASS e sem RomNexus. É também onde o mapeamento técnico pode ser convertido em dados estruturados: offsets, encoding, ponteiros, tilemaps, paletas, limites e regras de rebuild.

3. RomNexus — edição visual por interface gráfica

RomNexus é o aplicativo GUI do ecossistema. Ele usa um plugin Python por jogo e dados estruturados em JSON/metadata. Ao abrir uma ROM compatível, o aplicativo identifica o jogo, consulta o mapeamento já criado pelo fluxo técnico e apresenta textos, gráficos e demais recursos de forma organizada para edição.

Assim, o usuário não precisa operar diretamente o ASM ou executar scripts manualmente. Ele edita pela interface e o handler/plugin aplica as regras de extração e reconstrução da ROM.


Por que manter as três rotas? Porque elas atendem perfis diferentes. O romhacker avançado pode usar BASS; quem prefere linha de comando pode usar Python; e quem deseja uma experiência visual pode usar RomNexus. O conhecimento de uma investigação é mapeado uma vez e reaproveitado nas três entregas, poupando tempo sem misturar suas estruturas.

Wild_Arms_PSX: projeto especializado em um único jogo

O cérebro do Wild Arms foi criado especificamente para a retradução e localização desse jogo. Seu conteúdo não tenta servir como manual geral de romhacking: ele conhece o contexto de Filgaia, a fonte japonesa, glossário, tons e vozes, regras técnicas dos scripts, gráficos, arquivos processados e relatórios de QA.

Essa especialização permite que os agentes saibam não apenas como preservar um cabeçalho ou uma tag, mas também como Cecilia deve soar em determinada fase da história, quando a localização inglesa diverge do japonês e quais decisões já foram aprovadas para aquele jogo.

Exemplos reais registrados nele:

• [tt]Earth Golem[/tt] foi restaurado para Asgard após confirmação no arquivo japonês local [tt]101.txt[/tt], bloco 45.
• Nos mapas [tt]048.txt[/tt] e [tt]124.txt[/tt], a estrutura foi adaptada para preservar Rudy como protagonista silencioso, conforme a fonte japonesa, em vez de repetir automaticamente uma fala atribuída a ele pela versão ocidental.
• Os mapas 031–033 receberam variações próprias para Adlehyde em reconstrução. Igreja, cura, save e lojas deixaram de usar falas genéricas e passaram a refletir uma cidade ferida, mas resiliente.
• O glossário diferencia restaurações, naturalizações PT-BR, limites do executável e decisões que ainda exigem aprovação.

---

4. Os agentes: especialização sem teatro

Na arquitetura atual, o Strands Agents coordena Aurora, Sentinela e Artífice como agentes especializados. Cada agente recebe função, ferramentas, regras e contexto compatíveis com sua responsabilidade, enquanto o Vault funciona como memória persistente compartilhada.

A separação impede que a mesma etapa produza, aprove e encerre o próprio trabalho sem critérios diferentes. O orquestrador encaminha a tarefa, os especialistas executam suas partes e a decisão humana continua obrigatória nos pontos sensíveis.

Aurora | Tradutora

Consulta o arquivo alvo, a versão EU/US, o japonês local, o glossário e os perfis de voz. Identifica o momento narrativo, propõe termos e tradução e devolve ao usuário tudo que exige decisão humana.

Ela não traduz apenas palavras. Uma fala de Cecilia no início da jornada não deve soar igual à carta íntima do epílogo; Jack precisa continuar direto e provocador; Hanpan permanece analítico; Emma é acelerada, vaidosa e mandona; os Guardiões soam antigos e julgadores, e por ai vai.

Artífice | GFX

Analisa dimensão, formato, paleta, transparência, tiles, atlas, compressão e estilo dos glifos. Não gera livremente uma nova arte "parecida". Trabalha sobre a estrutura real do jogo e entrega comparação, preview e riscos técnicos.

Sentinela | QA

Não pergunta apenas se a frase "parece boa". Compara linhas, cabeçalhos, tags, encoding, idioma residual, limites visuais e, quando necessário, bytes, offsets, ponteiros, dimensões, paletas e round-trip.

Em [tt]101.txt[/tt], por exemplo, foram preservadas 173 linhas, 46 cabeçalhos e as tags por linha, além da decisão [tt]Earth Golem -> Asgard[/tt]. Em uma varredura posterior, 131 arquivos foram escaneados para localizar resíduos e divergências de glossário.

Humano | Direção e aprovação

O humano continua responsável por termos sensíveis, nomes, voz de personagens, naturalização, prioridades e aceite final. A IA reduz o custo de procurar, cruzar, documentar e verificar; não recebe autoridade ilimitada.

---

5. RAG de qualidade não é "jogar PDFs na IA"

RAG significa Retrieval-Augmented Generation: antes de responder, o modelo recupera informação externa relevante e usa esse contexto para gerar a resposta. Isso reduz a dependência da memória interna do modelo, mas não garante qualidade sozinho.

Um RAG ruim recupera o trecho errado com muita confiança. Um RAG de qualidade precisa cuidar de quatro coisas:

• Corpus: as fontes são confiáveis, identificadas e atuais?
• Recuperação: o sistema trouxe o trecho realmente necessário, com contexto suficiente?
• Fidelidade: a resposta está apoiada nas evidências recuperadas ou inventou conexões?
• Avaliação: existe teste capaz de separar erro de busca, erro de raciocínio e erro de execução?

O sistema não é apenas um RAG vetorial clássico. Ele é um híbrido de LLM Wiki, busca textual, links, hierarquia de fontes e ferramentas determinísticas. Em vez de reler toda a documentação bruta para cada pergunta, o agente consulta primeiro conhecimento já compilado. Só volta ao [tt]raw/[/tt], à ROM limpa, ao japonês local ou à internet quando precisa confirmar uma evidência.

A hierarquia do Wild Arms, por exemplo, prioriza:

• script japonês local do mesmo arquivo/bloco;
• dump, manual ou screenshot original verificável;
• referência japonesa confiável;
• script inglês e contexto de gameplay;
• inferência baseada no glossário aprovado.

Além disso, a evidência recebe um status visível: "JP local confirmado", "JP local divergente", "referência JP online", "JP pendente" ou "inferência de lore". Isso impede que uma suposição ganhe o mesmo peso de um dump original.

O RAG fornece contexto. Scripts, comparações binárias, ROM limpa e teste no emulador fornecem prova.

---

6. O método LLM Wiki de Karpathy

A estrutura foi inspirada no padrão LLM Wiki publicado por Andrej Karpathy. A diferença central em relação ao RAG tradicional é a acumulação: a IA não apenas recupera pedaços brutos em cada pergunta; ela mantém uma wiki persistente, interligada e progressivamente refinada.

As três operações principais são:

• Ingest: uma nova fonte entra em [tt]raw/[/tt], é lida e integrada às páginas afetadas.
• Query: a IA consulta primeiro o índice e a wiki compilada; se surgir conhecimento reutilizável, ele volta para a wiki.
• Lint: o cérebro procura contradições, páginas órfãs, decisões não consolidadas, links quebrados e informações superadas.

O [tt]index.md[/tt] funciona como mapa de conteúdo; o [tt]log.md[/tt] registra a evolução cronológica; o [tt]AGENTS.md[/tt] define o comportamento. Para centenas de páginas moderadamente organizadas, isso pode funcionar sem banco vetorial. Se o volume crescer, busca BM25, embeddings, reranking ou GraphRAG podem ser adicionados sem abandonar o Markdown.

---

7. Strands Agents: a camada de orquestração

O Strands Agents SDK é o framework usado para transformar as funções documentadas de Aurora, Artífice e Sentinela em uma arquitetura multiagente. Em termos simples, cada agente combina modelo, prompt e ferramentas; o orquestrador decide qual especialista deve atuar e acompanha a passagem de contexto entre as etapas.

O cérebro continua sendo a fonte comum; o schema delimita permissões; ferramentas determinísticas produzem evidências; e nenhum agente recebe autoridade para aprovar sozinho decisões sensíveis de lore, tom, formato ou alteração binária.

Na estrutura usada:

• Agents as Tools: o orquestrador chama Aurora, Artífice ou Sentinela como especialistas de domínio.
• Workflow: organiza o fluxo repetível "analisar -> aprovar -> aplicar -> QA -> registrar", preservando dependências e resultados intermediários.
• Graph: controla ciclos de correção, permitindo que uma reprovação da Sentinela retorne ao agente responsável até satisfazer os critérios de saída.
• Swarm: fica reservado para pesquisa exploratória ou problemas em que especialistas precisam colaborar de forma menos previsível. Alterações de ROM continuam preferindo fluxos controlados e auditáveis.

O Strands resolve a orquestração, mas não substitui a qualidade do conhecimento. Sem Vault, fontes, permissões restritas, ferramentas seguras e testes, múltiplos agentes apenas multiplicariam erros.

---

8. Exemplo real de QA gráfico: DAILY BUGLE -> CLARIM DIARIO

No projeto Spider-Man vs The Kingpin (Mega Drive), o letreiro [tt]DAILY BUGLE[/tt] parecia inicialmente uma troca simples de tiles. O agente de QA mostrou algo bem mais interessante:

• o endereço observado era uma referência de tilemap, não o gráfico bruto;
• o gráfico vinha de um bloco comprimido em HuffSloane;
• o atlas correto tinha 24 colunas por 3 linhas, totalizando 192x24 pixels;
• o jogo reutilizava tiles e aplicava espelhamento horizontal;
• algumas posições que pareciam independentes no PNG apontavam para o mesmo tile na ROM;
• a arte precisava continuar indexada e usar a paleta real do jogo.

O agente não apenas sugeriu "arrumar o M". Ele relacionou o defeito visual ao tilemap, identificou aliases, paleta e espelhamento e produziu regras verificáveis. Quando os tiles compartilhados impediram desenhos independentes, cinco tiles livres foram usados no atlas editável e o runtime recebeu um remapeamento específico para a fase. Nesse caso o agente devolveu a tarefa para o Artífice, com os dados necessários para a correção.


Depois vieram as validações: modo indexado, índices permitidos, round-trip HuffSloane, equivalência entre builds Python e BASS e, por fim, teste visual no emulador.


Esse caso resume bem o método: imagem para observar, disassembly e dados para explicar, script para reproduzir e emulador para confirmar.

Página 2>>

Complementando que o Lugg disse.
O jogo tem 689 arquivos.
Sobre a imagem (que eu testei)

• CDI v3.5
• ISO9660 íntegro
• 1 sessão/1 trilha
• 689 arquivos.

Os textos estão em DCDATA/TEXTS/*.LNG; imagens em TGA/GIF/PVR/IMG e texturas dentro de *.TEX

Não ta difícil não. Só precisa arrumar umas coisas e testar se for realmente traduzir esse jogo me da um alo que eu te passo, o que eu fiz aqui.
 

Citação de: Slasher online Julho 21, 2026, 14:39:32 PM

Citação de: ØX-Carnage online Julho 21, 2026, 10:51:22 AMEntendi se tiver o save da parte que ussa essas frases manda ae.
Não sou especialista  no assunto mas posso tentar ajudar.

Claro! Mando sim! Na verdade não precisa ir muito longe para chegar nessa parte mas segue o save:
Bible Game, The (USA).sgm

Obs: é um Save state do emulador Virtual Boy Advanced

Caso consiga entender como fazer para traduzir essa parte pretendo continuar até o final...

Seria isso?
Se for isso, a melhor solução seria um dump e insert. Isso porque o jogo trabalha com valores de índice, ou seja, para cada frase há o offset de início e o offset final. Subtraindo tudo do dicionário, temos o limite de caracteres. Se você for mudar uma frase, terá que fazer isso em todas as outras.
Brincando, dei uma pesquisada na VRAM e na font. Ambas podem ser editadas e expandidas sem problemas.
Expandi a ROM até 16 MB e não travou, então dá para colocar os versículos conforme a nossa Bíblia.

 

Citação de: Slasher online Julho 21, 2026, 00:41:30 AMSim, ainda não consegui progredir à partir da parte dos quizz que fazem uso do dicionário...

Entendi se tiver o save da parte que ussa essas frases manda ae.
Não sou especialista  no assunto mas posso tentar ajudar.

Parabéns Hawksd por mais uma tradução.Acho que a galera falou tudo o que era necessário, porém acho que aquela minha postagem do Wizards & Warriors você pode ter entendido errado.
Eu sinceramente estava esperando que você replicaria o que eu mandei na sua tradução.O bom é que você está querendo aprender, e há pessoas dispostas a ajudar, sem dúvida.Então acho que você já pode tentar outras coisas, como ponteiros, gráficos, etc...
E se houver dúvidas, não hesite em perguntar.Antigamente, quando tudo era mato, se tínhamos dúvidas precisávamos perguntar para gringo, e 90% não passava nada. Acho que já poderia começar com o Mortal Kombat, sou muito fã da franquia e quero ver essa tradução o filé. 

PS: Ficou faltando você colocar os prints da tradução no post.