Reset e Master Reset com custo progressivo e pontos por classe.
- Custo em zen que cresce por reset
- Pontos definidos por classe
- Limite diário configurável
// kezor.dev: desenvolvimento de sistemas para servidores de MuOnline
A infraestrutura que o seu projeto de MuOnline merece.
Soluções de ponta a ponta: sites premium, launchers com auto-update em tempo real, sistemas anti-cheat avançados e estabilidade garantida para o seu lançamento.
Onde o jogo acontece. Escrevo e corrijo os sistemas que rodam no servidor: comandos, eventos, drops, combate e regras customizadas, com validação em cada ação do jogador.
bool CVipSystem::ApplyBonus(LPOBJ lpObj, int64_t& exp) { const auto vip = m_Accounts.Find(lpObj->AccountID); if (!vip || vip->Expired(time(nullptr))) return false; exp += exp * vip->ExpBonus / 100; return true; }
Tudo que o jogador vê. Interfaces novas, janelas, itens, asas e efeitos visuais exigem código no cliente, sincronizado com o servidor.
// exemplo: desvio de chamadas para a interface nova void InitHooks() { SetCompleteHook(0xE8, ADDR_DRAW_INTERFACE, &DrawInterfaceEx); SetCompleteHook(0xE9, ADDR_ITEM_TOOLTIP, &ItemTooltipEx); SetByte(ADDR_MAX_LEVEL_CHECK, 0xEB); // remove limite antigo }
A porta de entrada. Baixa só o que mudou, confere a integridade de cada arquivo e libera o jogo com a proteção já carregada.
var pending = remote.Files .Where(f => !File.Exists(Path.Combine(root, f.Path)) || Hash.Sha256(Path.Combine(root, f.Path)) != f.Hash) .OrderBy(f => f.Priority) // main.exe e DLLs primeiro .ToList(); await downloader.RunAsync(pending, progress, ct);
Proteção em user-mode e kernel contra injeção de memória, speed hack e manipulação de pacotes, com banimento por HWID e trilha de evidências.
bool CGuard::ScanModules() { for (const auto& mod : EnumerateModules(GetCurrentProcess())) { if (!m_Whitelist.contains(Hash(mod.path))) return Report(Detect::InjectedModule, mod.path); } return true; }
A vitrine e o caixa do servidor. Site rápido, User CP e Admin CP completos, pagamentos com crédito automático e rankings lidos direto do banco.
app.post("/webhooks/pix", verifySignature, async (req, res) => { await db.transaction(async (trx) => { const pedido = await trx("Pedidos") .where({ txid: req.body.txid, status: "pendente" }) .forUpdate().first(); if (!pedido) return; // já processado await trx("CashShopData").where({ AccountID: pedido.conta }) .increment("WCoinC", pedido.moedas); await trx("Pedidos").where({ id: pedido.id }).update({ status: "pago" }); }); res.sendStatus(200); });
Os bancos MuOnline e Me_MuOnline guardam anos de progresso. Índices certos deixam ranking e reset instantâneos, e backup testado separa um susto de um desastre.
CREATE OR ALTER PROCEDURE dbo.KZ_RankingResets @Top INT = 100 AS SELECT TOP (@Top) Name, cLevel, ResetCount, Class FROM dbo.Character WHERE CtlCode = 0 ORDER BY ResetCount DESC, cLevel DESC; GO CREATE INDEX IX_Rank ON dbo.Character (ResetCount DESC, cLevel DESC) INCLUDE (Class) WHERE CtlCode = 0;
Servidor dimensionado para o público esperado, portas mínimas expostas, proteção contra DDoS e monitoramento com alerta antes do jogador perceber.
# exemplo de regras: só o necessário exposto allow tcp 44405 # ConnectServer allow tcp 55901-55905 # GameServers allow tcp 443 # site deny tcp 1433 # SQL Server nunca público limit conn 8 per ip # anti-flood de conexões
Onde o jogo acontece. Escrevo e corrijo os sistemas que rodam no servidor: comandos, eventos, drops, combate e regras customizadas, com validação em cada ação do jogador.
bool CVipSystem::ApplyBonus(LPOBJ lpObj, int64_t& exp) { const auto vip = m_Accounts.Find(lpObj->AccountID); if (!vip || vip->Expired(time(nullptr))) return false; exp += exp * vip->ExpBonus / 100; return true; }
Cada sistema é escrito nas camadas que ele precisa: regra no GameServer, gravação no SQL Server, interface no cliente e painel no site. É isso que impede dupe e gambiarra.
Reset e Master Reset com custo progressivo e pontos por classe.
Invasões e eventos programados por dia e horário, sem reiniciar o servidor.
Cerco automatizado com fases, registro de guilds e prêmios ao dono do castelo.
Itens, asas e sets novos com opções e efeitos, cliente e servidor sincronizados.
Loja in-game com WCoin, pacotes e VIP com expiração automática.
Missões em cadeia, NPCs customizados e janelas de diálogo no cliente.
Personagem continua upando desconectado, com regras por mapa e por VIP.
Fórmulas de dano e defesa por classe, separadas para PvP e PvE.
Trilha de trade, drop raro e comando de GM, com busca por serial no Admin CP.
Rankings de reset, guild, PvP e eventos servidos por API com cache.
Avisos de evento, status do servidor e alertas privados para a equipe de GM.
Filtro de pacotes e conexões que derruba flood antes de chegar ao GameServer.
Exemplo do método que uso em servidores com item duplicado: provar pelo log, entender pelo pacote e corrigir na origem.
O mesmo serial de Jewel of Bless aparece em dois personagens no mesmo segundo. Não é bug visual, é cópia real de item.
Na captura, o cliente manda a confirmação da troca duas vezes em 3 ms, e o servidor processa as duas sem travar a operação.
A troca passa a ser atômica: os dois personagens ficam travados, os inventários são revalidados e a gravação acontece uma única vez.
O mesmo serial de Jewel of Bless aparece em dois personagens no mesmo segundo. Não é bug visual, é cópia real de item.
Na captura, o cliente manda a confirmação da troca duas vezes em 3 ms, e o servidor processa as duas sem travar a operação.
A troca passa a ser atômica: os dois personagens ficam travados, os inventários são revalidados e a gravação acontece uma única vez.
Arquivos antigos e novos têm problemas diferentes. Antes de escrever uma linha, identifico em qual geração o seu servidor está.
| GERAÇÃO | ONDE COSTUMA QUEBRAR | O QUE EU FAÇO | RISCO SEM REVISÃO |
|---|---|---|---|
| Clássicas0.97d a Season 2 | Protocolo simples e fácil de manipular. Main.exe sem estrutura para interface nova. Arquivos base com dupes conhecidos. | Validação extra no servidor para compensar o cliente, hooks para janelas modernas e auditoria dos dupes clássicos. | alto |
| IntermediáriasSeason 3 a Season 6 | Arquivos de origem duvidosa com backdoor. Master Level e eventos pesando no GameServer. Muitas versões quebradas circulando. | Varredura de backdoor no core e nas DLLs, otimização de memória e dos loops de evento, identidade própria em site e launcher. | alto |
| ModernasSeason 8 a Season 12 | Cliente pesado, mais tabelas no banco e mais pontos de dupe. Balanceamento de classes mais delicado. | Patch diferencial para atualizações grandes, procedures e índices revisados por tabela, simulação de dano antes de cada ajuste. | médio |
| AtuaisSeason 13 a Season 20+ | Emuladores complexos e pouco documentados. Exigência alta de hardware e rede. Jogador compara com o oficial. | Diagnóstico profundo do emulador, infraestrutura dimensionada com teste de carga real e acabamento de nível oficial. | médio |
Cada fase termina com uma entrega que você valida antes da próxima começar. Os testes rodam numa branch separada e só entram em produção quando passam.
Diagnóstico técnico do projeto, escolha da season e dos arquivos base, dimensionamento da VPS e da proteção contra DDoS.
Sistemas no GameServer, site integrado ao banco, launcher e camadas de segurança no cliente e no servidor.
Carga com clientes simulados, ataque ativo ao anti-hack, auditoria do site e dos pagamentos e teste de restauração de backup.
Plantão em tempo real na inauguração, monitoramento de processos, banco e rede, e suporte dedicado depois do Go-Live.
Sim. Começo com uma auditoria do emulador, do cliente e do banco que você já tem e digo o que dá para aproveitar e o que precisa ser reescrito. Migrar não significa jogar fora o que funciona.
Dá. Mapeio as tabelas entre a estrutura antiga e a nova, converto personagens, itens e WCoin com scripts T-SQL e valido tudo numa cópia do banco antes de tocar na produção.
A proteção é adaptada ao main.exe de cada versão. Clientes antigos exigem mais validação do lado do servidor, porque o protocolo é mais simples. Clientes novos permitem verificações mais profundas no próprio cliente.
Sistemas, site e painéis feitos sob medida são entregues com código-fonte, histórico no Git e documentação. O núcleo do anti-hack é licenciado, para que a proteção não vaze e continue funcionando.
O site gera a cobrança PIX, o provedor avisa por webhook assinado e o sistema credita as moedas numa transação única. Se o aviso chegar duas vezes, o crédito não duplica.
No Go-Live eu monitoro processos, banco e rede em tempo real. Os processos têm reinício automático e o plano de contingência é definido ainda no planejamento.
Segurança, banco de dados e lançamento, explicados por quem mantém servidor em produção.
O valor depende da season, do nível de proteção e do quanto site e launcher serão personalizados. Marque o que precisa e a mensagem sai pronta para enviar.