Como adicionar itens visuais (asas, sets) ao cliente de MU

Adicionar itens visuais como asas e sets ao cliente de MU Online é uma das personalizações mais gratificantes e, ao mesmo tempo, mais delicadas que um administrador pode fazer. Diferente de ajustar uma taxa de experiência ou um valor de drop, aqui você mexe diretamente no que o jogador enxerga na tela: modelos tridimensionais, texturas, efeitos de brilho e a forma como tudo isso se encaixa no personagem. O conceito central que você precisa gravar antes de qualquer coisa é que o MU Online funciona com duas metades que precisam falar a mesma língua. O servidor sabe que existe um item com determinado ID, atributos e restrições; o cliente sabe como desenhar esse item na tela. Se as duas metades não estiverem perfeitamente sincronizadas, o resultado é um item invisível, uma interrogação flutuando sobre o personagem ou, no pior caso, um cliente que trava toda vez que tenta renderizar aquele objeto. Este tutorial é voltado ao administrador de nível avançado que já domina a parte de servidor e agora quer entregar visuais novos com segurança. Como sempre no universo dos emuladores, os nomes exatos dos arquivos, as pastas e a estrutura das definições variam por season e por cliente, então trate cada exemplo aqui como ilustração de um conceito real, não como cópia literal para o seu pacote.

Pré-requisitos

Antes de tocar em qualquer arquivo, garanta que você tem o ambiente e o conhecimento mínimos para trabalhar com segurança. Adicionar itens visuais é uma tarefa de nível avançado justamente porque envolve várias camadas ao mesmo tempo, e pular etapas costuma custar horas de retrabalho.

• Backup completo do cliente: copie a pasta inteira do cliente, com atenção especial à subpasta Data. Guarde também uma cópia do arquivo de definição de itens que você vai editar.
• Backup do servidor: exporte a tabela de itens do banco e copie os arquivos de definição do GameServer que controlam o item.
• Ferramenta de edição de arquivos BMD: os modelos e algumas definições do MU ficam em formato BMD, que é criptografado ou empacotado. Você vai precisar de um editor compatível com a sua season para abrir, visualizar e salvar esses arquivos.
• Editor de texturas: as texturas costumam estar em formatos como OZJ, OZT ou OZB, que são variações de JPG, TGA e BMP com um pequeno cabeçalho. Uma ferramenta de conversão OZ é essencial.
• Um item base para clonar: a forma mais segura de começar é partir de um item visual que já funciona, entender sua estrutura e só então modificá-lo.
• Ambiente de testes: nunca faça a primeira tentativa no servidor de produção. Tenha um cliente de testes apontando para um servidor local.

Como o MU representa um item visual

Um item visual no MU não é um arquivo único, e sim um conjunto de peças que o cliente monta em tempo real. Entender essa anatomia é o que separa quem adiciona itens com confiança de quem fica tentando na tentativa e erro. De forma geral, três blocos compõem qualquer asa ou set.

O primeiro bloco é o modelo geométrico, o arquivo BMD que descreve a malha tridimensional, os ossos de animação e os pontos de encaixe. É ele que define o formato da asa ou o corte de uma armadura. O segundo bloco é a textura, a imagem que reveste esse modelo e dá cor, brilho e detalhe. O terceiro bloco é a definição de item, a entrada em uma tabela ou arquivo que diz ao cliente qual categoria e índice aquele item ocupa, qual modelo carregar e quais efeitos aplicar. O servidor mantém sua própria definição paralela, com os atributos de jogo. Quando um jogador equipa a asa, o servidor envia o ID; o cliente recebe esse ID, procura na sua definição qual modelo e textura correspondem e desenha na tela.

A regra de ouro que decorre dessa anatomia é simples: o ID do item precisa ser idêntico no servidor e no cliente, e todos os três blocos visuais precisam existir na pasta do cliente. Se qualquer peça faltar, o item quebra.

Categorias e índices: escolhendo um espaço livre

Cada item no MU é identificado por uma dupla de valores: a categoria, geralmente de 0 a 15, que separa os tipos como armas, armaduras e asas, e o índice dentro dessa categoria, tipicamente de 0 a 511. Asas costumam viver em uma categoria própria, enquanto peças de set se distribuem pelas categorias de armadura, calça, luva, bota e capacete. Antes de adicionar qualquer coisa, você precisa encontrar uma dupla categoria/índice que esteja vaga, porque reutilizar uma dupla ocupada sobrescreve o item original e provoca conflitos silenciosos que só aparecem semanas depois.

No lado do servidor, você verifica a disponibilidade consultando o banco:

-- Verifica se a dupla categoria/indice ja esta em uso
-- (nomes de tabela e coluna variam por emulador)
SELECT ItemCategory, ItemIndex, ItemName
FROM Item
WHERE ItemCategory = 12 AND ItemIndex = 40;
-- Se nao retornar linha, o espaco esta livre para uso

No lado do cliente, a verificação é feita abrindo o arquivo de definição de itens e procurando pela mesma dupla. A dupla precisa estar livre nos dois lados ao mesmo tempo. Um erro comum é escolher um índice livre no servidor que já está ocupado no cliente por um item de sistema, o que faz o novo item herdar o visual errado.

Passo a passo: adicionando um par de asas novo

Com os conceitos firmes, vamos ao processo prático. Vou usar asas como exemplo porque elas exercitam todas as camadas de uma vez, incluindo efeitos. Os passos para um set seguem a mesma lógica, com a diferença de que um set envolve várias peças, cada uma na sua categoria.

1. Escolha o modelo de origem. Selecione um arquivo BMD de asa que já funciona e que tenha uma geometria parecida com o que você quer. Reaproveitar reduz drasticamente a chance de erro em pontos de encaixe.
2. Defina a dupla categoria/índice livre. Confirme a disponibilidade no servidor e no cliente, conforme a seção anterior. Anote a dupla escolhida em um bloco de notas para não se perder.
3. Prepare a textura. Edite ou crie a imagem da asa no seu editor gráfico, respeitando as dimensões do original. Converta para o formato OZ correto e nomeie seguindo o padrão do seu cliente.
4. Ajuste o modelo BMD. Abra o modelo no editor BMD, aponte para a nova textura e, se necessário, ajuste escala e posição. Salve com o nome que corresponde à nova dupla de índice.
5. Registre a definição no cliente. Adicione a entrada que mapeia a nova dupla categoria/índice para o modelo e a textura recém-criados. É aqui que o cliente aprende a existência do item.
6. Registre a definição no servidor. Insira o item na tabela do banco e nos arquivos de definição do GameServer, com nome, atributos e restrições de classe. Sem isso, o item não pode ser dropado nem equipado.
7. Configure o efeito, se houver. Asas costumam ter brilho ou aura. Aponte a definição de efeito para a textura de partícula desejada.
8. Sincronize e teste. Copie os arquivos visuais para o cliente de testes, suba o servidor local e verifique.

; Exemplo ILUSTRATIVO de entrada de definicao de item no cliente
; A sintaxe real varia por season e cliente
[Item]
Category = 12        ; categoria de asas (exemplo)
Index    = 40        ; indice livre escolhido
Name     = "Asa da Aurora"
Model    = "Wing40.bmd"
Texture  = "Wing40.OZJ"
Effect   = 3         ; identificador de efeito de brilho

Repare que os nomes de campo acima são ilustrativos. O ponto que não muda entre emuladores é a relação: uma dupla categoria/índice apontando para um modelo, uma textura e, opcionalmente, um efeito.

Sets visuais: as particularidades das peças múltiplas

Um set é mais trabalhoso que um par de asas porque não é uma peça só. Ele é composto por armadura, calça, luva, bota e, às vezes, capacete, cada uma vivendo em sua própria categoria e índice. Para o visual ficar coeso, todas as peças precisam usar o mesmo tema de textura e, idealmente, o mesmo índice relativo dentro de suas categorias, o que facilita a manutenção. Muitos clientes esperam que as peças de um mesmo set compartilhem um índice numérico comum entre as diferentes categorias, então planejar essa numeração antes de criar os arquivos evita retrabalho.

Além das peças, sets frequentemente têm um efeito de conjunto, aquele brilho que aparece quando o jogador equipa todas as partes. Esse efeito costuma ser controlado por uma definição separada, que verifica se o personagem tem o set completo e só então aplica a aura. Se você adiciona um set novo e o brilho de conjunto não aparece, o problema quase sempre está nessa definição de bônus de set, não nos modelos individuais. Vale também prestar atenção à modelagem por raça e sexo: no MU, muitos sets têm variações de malha para personagens masculinos e femininos, e esquecer uma variação faz o set sumir apenas para um dos sexos.

Sincronizando servidor e cliente

Esta é a seção que resolve noventa por cento dos problemas relatados por quem adiciona itens visuais. A sincronização não é um passo opcional de acabamento; ela é o coração do processo. O servidor e o cliente mantêm definições independentes que precisam concordar sobre três coisas: o ID do item, ou seja, a dupla categoria e índice; a existência do item, ou seja, ele precisa estar registrado nos dois lados; e a distribuição, ou seja, todos os jogadores precisam ter os arquivos visuais.

O fluxo saudável de publicação é sempre o mesmo. Primeiro você adiciona e testa tudo em ambiente local. Depois você empacota os arquivos visuais novos em um patch de cliente, aquele conjunto de arquivos que o launcher baixa antes de o jogo abrir. Só então você aplica a mudança no servidor de produção e libera o patch para os jogadores no mesmo momento. A ordem importa: se o servidor começar a dropar um item cujo visual os jogadores ainda não têm, eles verão itens quebrados e reportarão bugs em massa. Um administrador experiente coordena as duas pontas para que a definição do servidor e o patch do cliente cheguem juntos. Para entender o outro lado dessa equação, com a preparação da infraestrutura que hospeda essas definições, vale revisar o guia de como montar um servidor de MU do zero, que contextualiza onde as definições de item se encaixam na arquitetura geral.

Testando o item antes de publicar

Testar não é equipar o item uma vez e achar bonito. Um teste sério passa por vários cenários que revelam bugs que só aparecem em situações específicas. Comece equipando e desequipando o item várias vezes, observando se o modelo carrega e descarrega sem deixar resíduo visual. Depois, teste com personagens de sexos e classes diferentes, porque muitos visuais têm variações que podem estar faltando. Verifique o item em movimento, com o personagem correndo, atacando e usando habilidades, já que asas em especial têm animação e pontos de encaixe que podem falhar durante o movimento.

Um teste que muita gente esquece é o de múltiplos jogadores. Coloque dois personagens na mesma tela, um equipando o item e outro observando, para garantir que o visual aparece corretamente para terceiros e não só para quem está usando. Por fim, monitore o consumo de memória e a estabilidade: um modelo mal otimizado pode fazer o cliente travar quando muitos jogadores com o mesmo item se juntam em uma tela, como em eventos de castle siege.

Erros comuns e soluções

A tabela abaixo reúne os problemas que mais aparecem ao adicionar itens visuais e o caminho de diagnóstico para cada um. Use-a como referência rápida quando algo der errado.

Na maioria desses casos, o diagnóstico começa perguntando se o problema é de servidor, de cliente ou de sincronização. Itens que somem só para alguns jogadores são quase sempre problema de distribuição de patch; itens que aparecem quebrados para todos são problema de arquivo visual; itens que nem podem ser equipados são problema de definição de servidor.

Otimização e boas práticas

Depois que você domina o básico de adicionar um item, vale investir em práticas que mantêm o projeto saudável a longo prazo. Mantenha uma planilha ou documento com todos os itens customizados que você adicionou, registrando categoria, índice, nome e a data em que entraram. Esse controle evita conflitos futuros e facilita a vida de qualquer pessoa que herde a administração. Padronize a nomenclatura dos arquivos visuais seguindo o índice do item, o que torna óbvio qual arquivo pertence a qual item.

Cuide também da otimização dos modelos. Um modelo de asa com contagem de polígonos exagerada pode ficar bonito em uma tela vazia e destruir o desempenho em um evento com dezenas de jogadores. Prefira modelos com geometria enxuta e texturas de resolução compatível com o que o cliente da sua season suporta. Por fim, versione seus patches: cada vez que você libera um conjunto de itens novos, guarde uma cópia daquele patch com um número de versão, para poder reverter para um estado conhecido caso um item novo cause problemas em produção.

Checklist de lançamento

Antes de liberar itens visuais novos para os jogadores, percorra esta lista. Cada item marcado é uma fonte de bug eliminada.

• Backup completo do cliente e do servidor realizado
• Dupla categoria/índice confirmada como livre nos dois lados
• Modelo BMD salvo com a ferramenta compatível e testado
• Texturas convertidas no formato OZ correto e nas dimensões certas
• Definição do item registrada no cliente
• Definição do item registrada no servidor com atributos e restrições
• Efeitos de brilho ou aura configurados, quando aplicável
• Variações por sexo e classe verificadas
• Teste de equipar, desequipar e movimento realizado
• Teste de visibilidade para outros jogadores realizado
• Patch de cliente empacotado e versionado
• Publicação coordenada entre servidor e distribuição do patch
• Documento de controle de itens customizados atualizado

Seguir esse fluxo transforma uma tarefa que assusta muita gente em um processo repetível e previsível. A primeira asa que você adicionar vai levar horas; a décima vai levar minutos, porque você terá internalizado a lógica de que servidor e cliente são duas metades que precisam sempre falar a mesma língua. Lembre-se de que tudo aqui é ilustração de conceitos reais, e que os nomes de arquivo, pastas e campos variam por season e cliente, então adapte cada passo ao seu pacote específico e teste sempre em ambiente local antes de expor à comunidade.

Perguntas frequentes