Cliente a partir do source
Além do cliente clássico com DLL, o servidor agora é compatível com o cliente reconstruído a partir do código-fonte: um port em C++ do main.exe do 0.97k, feito por engenharia reversa do binário original.
Diferente do cliente com DLL — um executável fechado no qual se injeta uma biblioteca —, aqui você tem o código. Compila, modifica e depura como qualquer projeto C++.
Em que estado está. Inicia, conecta, faz login, entra no mundo e é jogável: terreno, personagens, inventário, equipamento, chat, party, guild, loja, baú, combate e efeitos funcionam. Não é um cliente finalizado — é uma reconstrução em andamento, e diferenças continuam aparecendo conforme novos caminhos são exercitados. Para produção, o cliente com DLL continua sendo a opção estável.
Qual dos dois usar
| Cliente com DLL | Cliente a partir do source | |
|---|---|---|
| Como se configura o IP | ClientInfo.bmd (InfoEncoder) |
server.cfg, texto puro |
| Como se obtém | pasta pronta para distribuir | você mesmo compila |
| Estado | estável, testado em produção | reconstrução em andamento |
| Pode ser modificado | não, é um binário | sim, é código-fonte |
| Linux nativo | não | ainda não — veja abaixo |
Se você só quer subir um servidor e deixar o pessoal jogar, use o cliente com DLL. Este guia é para quem quiser compilar, estudar ou modificar.
Compilar
Você precisa do Visual Studio 2022 com o toolset de C++ para desktop.
- Abrir
mu97k.sln - Selecionar a configuração Debug e a plataforma Win32
- Compilar
O executável fica em bin/Client/main.exe. O projeto linka direto nessa pasta, que é onde ficam os assets e a configuração, então não há cópia intermediária nem risco de rodar um binário antigo.
A plataforma tem que ser Win32 (x86). Todo o port assume ponteiros de 32 bits: os endereços do binário original, os layouts de struct e os pools de memória. Em x64 não compila, e se compilasse não funcionaria.
As bibliotecas linkadas são todas do SDK do Windows (opengl32, glu32, winmm, ws2_32), exceto a libjpeg, que vem incluída no repositório. Nada mais para instalar.
Configurar: server.cfg
Aqui está a principal diferença em relação ao cliente clássico. Não se usa ClientInfo.bmd nem o InfoEncoder: a configuração é um arquivo de texto puro chamado server.cfg, ao lado do executável.
127.0.0.1 44405 <- ConnectServer (lista de servidores)
127.0.0.1 55901 <- GameServer (fallback)
CustomerName=MuLinux
ServerSerial=TbYehR2hFUPBKgZj
ClientVersion=0.97.11
Os endereços
Com duas linhas usa-se o fluxo ConnectServer completo: o cliente pede a lista real de servidores, o servidor responde com nomes e ocupação, e ao escolher um você é redirecionado ao GameServer. Com uma única linha conecta direto ao GameServer, que é o comportamento clássico.
Substitua 127.0.0.1 pelo IP público do seu VPS nas duas linhas.
A identidade do servidor
Os três valores abaixo precisam coincidir com os do seu servidor, em MuServer/GameServer/DATA/GameServerInfo - StartUp.dat. Se algum não coincidir, o cliente conecta mas nunca entra, e sem nenhuma mensagem útil:
| Chave | De onde sai | O que acontece se não coincidir |
|---|---|---|
CustomerName |
CustomerName= do .dat |
Conecta, descriptografa lixo e trava em “conectando ao GameServer” para sempre |
ServerSerial |
ServerSerial= do .dat |
O mesmo, e além disso o login retorna “versão incorreta” |
ClientVersion |
ServerVersion= do mesmo .dat |
Login rejeitado com “versão incorreta” |
CustomerName e ServerSerial alimentam a chave de criptografia, que o GameServer deriva da combinação dos dois. É por isso que mudar o nome do cliente quebra a conexão mesmo com todo o resto correto.
Se forem omitidos, usam-se os valores padrão do projeto (os do exemplo acima). ClientVersion aceita tanto 0.97.11 quanto 09711.
Opções do cliente
O 0.97k original lê estas opções do registro do Windows, que é onde o launcher oficial as deixa. Como aqui não há launcher, elas também são aceitas no server.cfg e, quando presentes, ganham do registro — assim dá para distribuir o cliente já configurado.
| Chave | Padrão | O que faz |
|---|---|---|
MusicOnOff |
0 |
Música de fundo. Vem desligada no binário original; o exemplo traz em 1. O cliente não decodifica o mp3, ele executa MuPlayer.exe. |
SoundOnOff |
1 |
Efeitos sonoros. |
Resolution |
0 |
Índice 0..4 ou LARGURAxALTURA, mas somente as cinco do binário: 640×480, 800×600, 1024×768, 1280×1024 e 1600×1200. Qualquer outra é ignorada e inicia em 640×480. |
WindowMode |
1 |
1 = em janela, 0 = tela cheia. |
Borderless |
0 |
Sem barra de título nem borda. Só se aplica no modo janela. |
São aceitas como 0/1 ou como on/off.
O modo janela é um acréscimo: o 0.97k original só roda em tela cheia e procura um modo de vídeo de 16 bits de cor que não existe mais no Windows 10/11, então a troca de modo falha em silêncio e a janela fica sem bordas num canto.
Diagnóstico
O cliente escreve bin/Client/debug.log a cada inicialização. A primeira linha útil é a chave de criptografia derivada:
MuEmu: InitKeys CustomerName='MuLinux' Serial='TbYehR2hFUPBKgZj' -> EncDecKey1=0xC2 EncDecKey2=0x01
server.cfg: ClientVersion='09711'
Se o cliente travar conectando, essa linha é a primeira coisa a olhar: compare o CustomerName com o do seu servidor.
Linux: ainda não
O cliente não compila no Linux por enquanto, e é o que vem a seguir.
O port é feito contra o binário original do Windows: assume ponteiros de 32 bits, usa a API Win32 para a janela e o input, e OpenGL através do wgl. Levá-lo ao Linux é uma etapa própria do projeto — abstração de plataforma e build com CMake — que começa depois de fechar a reconstrução 1:1.
Enquanto isso o cliente roda no Windows contra um servidor Linux sem problema algum: o servidor é nativo de Linux desde o começo e a comunicação é pela rede.
O repositório
O código fica em EmanuelCatania/Mu-97k-Client-Source.
É desenvolvimento ativo: a reconstrução 1:1 contra o binário original ainda não está fechada, e os avanços são mesclados via pull request. O README do repositório documenta o estado por subsistema, como compilar e as armadilhas conhecidas do port.