Como configurar o sistema de ban/mute/kick no MU Online

Moderar um servidor de MU Online sem um sistema de punições bem estruturado é como dirigir sem freio: cedo ou tarde você bate. Jogadores tóxicos no chat, usuários de bot, exploradores de bugs e reincidentes que criam contas novas a cada banimento vão testar os limites do seu servidor todos os dias. A resposta a isso é uma escada de punições clara — kick para o incômodo momentâneo, mute para o abuso de chat e ban para as infrações graves — sustentada por comandos de GM confiáveis, registros no banco de dados e uma política que resista a apelações. Este guia mostra como montar esse sistema completo, do arquivo de configuração ao SQL de auditoria. Os nomes de colunas, comandos e caminhos são exemplos que variam por season/emulador, então confirme cada um no seu build antes de aplicar em produção.

Pré-requisitos

Antes de começar, garanta que você tem:

• Acesso de administrador ao diretório do servidor (ex.: C:\MuServer\).
• SQL Server Management Studio (SSMS) conectado ao banco MuOnline.
• Uma conta de GM com nível de autoridade suficiente para usar comandos administrativos.
• SQL Server Agent habilitado, caso queira automação de bans temporários.
• Backup completo do banco de dados e dos arquivos de configuração.
• Conhecimento do nome exato das tabelas de conta do seu build (MEMB_INFO, MEMB_STAT, AccountCharacter, etc.).

> Nunca teste comandos de ban em produção com contas reais de jogadores. Crie uma conta de teste e valide todo o fluxo (banir, verificar bloqueio, desbanir) antes de liberar os comandos para a equipe.

Entendendo a escada de punições

Antes de configurar qualquer coisa, é fundamental que sua equipe entenda a diferença entre as três ações e quando aplicar cada uma. A tabela abaixo resume a escada de severidade que a maioria dos servidores adota.

A regra de ouro é proporcionalidade: comece pela punição mais leve que resolva o problema e escale apenas diante de reincidência ou gravidade. Um jogador que xingou uma vez merece mute, não ban permanente. Um usuário de bot pego em flagrante merece ban direto.

Passo 1 — Configurar os comandos de GM no servidor

A maioria dos emuladores expõe comandos de chat administrativos que só funcionam para contas com nível de autoridade adequado. Esses comandos ficam habilitados em um arquivo de configuração do GameServer, geralmente em GameServer\Data\ ou no próprio GameServer.ini. Um bloco de exemplo:

[GMCommands]
EnableCommands   = 1
KickCommand      = /kick        ; /kick <nick>
MuteCommand      = /mute        ; /mute <nick> <minutos>
UnmuteCommand    = /unmute      ; /unmute <nick>
BanCommand       = /ban         ; /ban <conta> <horas> <motivo>
BanIPCommand     = /banip       ; /banip <ip> <horas>
DisconnectCmd    = /disc        ; /disc <nick>
MinLevelKick     = 8            ; nivel minimo de GM para kick
MinLevelMute     = 8
MinLevelBan      = 16           ; ban restrito a nivel alto
MinLevelBanIP    = 32           ; ban de IP so para admin

Os números de nível (MinLevelBan, etc.) referenciam o campo de autoridade da conta — em muitos builds a coluna CtlCode da MEMB_INFO, onde valores como 0 = jogador, 8 = GM comum, 16 = GM sênior e 32 = administrador. Esses valores variam por season/emulador; confira o mapeamento no seu compilado.

Depois de editar, reinicie o GameServer para que ele releia a configuração. Muitos builds não recarregam comandos a quente.

Passo 2 — Preparar a estrutura de auditoria no banco

Um sistema de punição sem registro é um convite a abuso e a discussões intermináveis com jogadores. Crie uma tabela de auditoria que guarde toda ação de moderação:

USE MuOnline;
GO

CREATE TABLE dbo.Moderation_Log (
    LogID        INT IDENTITY(1,1) PRIMARY KEY,
    ActionType   VARCHAR(15)  NOT NULL,   -- KICK, MUTE, BAN, BANIP, UNBAN
    TargetAcc    VARCHAR(10)  NULL,
    TargetChar   VARCHAR(10)  NULL,
    TargetIP     VARCHAR(45)  NULL,
    GMName       VARCHAR(10)  NOT NULL,
    Reason       VARCHAR(255) NOT NULL,
    DurationMin  INT          NULL,       -- duracao em minutos (NULL = permanente)
    CreatedAt    DATETIME     DEFAULT GETDATE(),
    ExpireAt     DATETIME     NULL        -- quando o ban/mute expira
);
GO

Essa tabela é a espinha dorsal de todo o sistema. Toda vez que um GM aplicar uma punição, um registro entra aqui — seja pelo comando in-game (se o emulador tiver hook de log) ou pela query manual que você mesmo executa.

Passo 3 — Aplicar um ban de conta via SQL

O ban de conta clássico consiste em marcar a flag de bloqueio da conta. Na maioria dos schemas isso é a coluna bloc_code da MEMB_INFO (0 = liberada, 1 = bloqueada):

USE MuOnline;
GO

-- Banir a conta 'contaSuspeita' por 72 horas
DECLARE @acc VARCHAR(10) = 'contaSuspeita';
DECLARE @gm  VARCHAR(10) = 'AdminBruno';
DECLARE @horas INT = 72;

UPDATE MEMB_INFO
SET bloc_code = 1
WHERE memb___id = @acc;

-- Desconectar imediatamente se estiver online
UPDATE MEMB_STAT
SET ConnectStat = 0
WHERE memb___id = @acc;

-- Registrar na auditoria com data de expiracao
INSERT INTO dbo.Moderation_Log
    (ActionType, TargetAcc, GMName, Reason, DurationMin, ExpireAt)
VALUES
    ('BAN', @acc, @gm, 'Uso de bot confirmado por log', @horas * 60,
     DATEADD(HOUR, @horas, GETDATE()));
GO

Perceba que o ban não deleta nada: o personagem, os itens e o Zen continuam intactos. Isso é intencional. Punição correta é reversível; deletar conta é destruição de dados e impede qualquer apelação justa.

Passo 4 — Automatizar bans temporários com expiração

Registrar a data de expiração não serve de nada se ninguém remover o bloqueio quando ela chega. Crie uma stored procedure que varre a tabela de auditoria e libera contas cujo ban expirou:

USE MuOnline;
GO

CREATE PROCEDURE dbo.SP_ExpireBans
AS
BEGIN
    SET NOCOUNT ON;

    -- Desbanir contas cujo ban temporario ja expirou
    UPDATE m
    SET m.bloc_code = 0
    FROM MEMB_INFO m
    INNER JOIN dbo.Moderation_Log l
        ON m.memb___id = l.TargetAcc
    WHERE l.ActionType = 'BAN'
      AND l.ExpireAt IS NOT NULL
      AND l.ExpireAt <= GETDATE()
      AND m.bloc_code = 1;

    PRINT 'Bans expirados processados: ' + CAST(GETDATE() AS VARCHAR);
END;
GO

Agende essa procedure no SQL Server Agent para rodar a cada 10 minutos (SSMS → SQL Server Agent → Jobs → New Job → Steps: EXEC dbo.SP_ExpireBans; → Schedules: a cada 10 minutos). Assim, um ban de 72 horas se resolve sozinho, sem intervenção manual.

Passo 5 — Implementar o sistema de mute

O mute normalmente é controlado por uma flag ou uma tabela auxiliar que o GameServer consulta ao processar uma mensagem de chat. Em builds que suportam mute nativo via comando /mute, o próprio emulador cuida disso. Para builds que não suportam, você monta uma tabela e o GameServer (ou um plugin) verifica antes de liberar o chat:

USE MuOnline;
GO

CREATE TABLE dbo.Chat_Mute (
    CharName   VARCHAR(10) PRIMARY KEY,
    MutedUntil DATETIME    NOT NULL,
    GMName     VARCHAR(10) NOT NULL,
    Reason     VARCHAR(255) NULL
);
GO

-- Silenciar 'JogadorSpammer' por 30 minutos
INSERT INTO dbo.Chat_Mute (CharName, MutedUntil, GMName, Reason)
VALUES ('JogadorSpammer', DATEADD(MINUTE, 30, GETDATE()),
        'GMGabriel', 'Flood de comercio no chat global');
GO

Se o seu emulador não lê essa tabela nativamente, o mute precisa ser aplicado via comando in-game em vez de SQL. Isso varia por season/emulador — verifique se o build suporta mute por banco antes de depender dessa abordagem.

Passo 6 — Ban por IP e por HWID

Reincidentes que criam contas novas exigem uma camada além do ban de conta. O ban de IP costuma ser feito por um arquivo de lista no ConnectServer:

# ConnectServer\IPBanList.txt  (formato varia por build)
201.10.55.32
189.44.0.0-189.44.255.255

O ban por HWID, quando o emulador oferece, bloqueia o identificador de hardware do cliente, sendo muito mais difícil de burlar do que trocar de IP. Nem todo build tem suporte a HWID — em muitos casos ele depende de um módulo anti-cheat acoplado. Se o seu servidor tiver, registre também o HWID na tabela de auditoria para rastrear reincidentes.

> Ban de IP pega inocentes. Famílias, LAN houses e redes com NAT compartilham o mesmo IP público. Use ban de IP apenas para reincidentes confirmados e prefira faixas estreitas a bloqueios amplos. Um ban de IP largo demais pode tirar dezenas de jogadores legítimos do servidor sem você perceber.

Passo 7 — Fluxo de trabalho da equipe de moderação

Ferramenta sem processo não funciona. Defina um fluxo claro para a equipe:

1. Receber a denúncia (ticket, print, log automático).
2. Verificar a evidência — nunca puna com base só em acusação.
3. Escolher a punição proporcional conforme a escada de severidade.
4. Aplicar via comando ou SQL com motivo textual obrigatório.
5. Registrar na auditoria (automático ou manual).
6. Comunicar ao jogador o motivo e a duração, quando aplicável.
7. Guardar a evidência por pelo menos 30 dias para eventual apelação.

Esse processo protege tanto o servidor quanto o jogador. Se este material de fundação ainda não está no ar, vale revisar primeiro o guia de como criar servidor de MU Online antes de montar a camada de moderação.

Passo 8 — Consultas de revisão e desban

Para desbanir uma conta após apelação bem-sucedida:

USE MuOnline;
GO

DECLARE @acc VARCHAR(10) = 'contaInocente';

UPDATE MEMB_INFO SET bloc_code = 0 WHERE memb___id = @acc;

INSERT INTO dbo.Moderation_Log (ActionType, TargetAcc, GMName, Reason)
VALUES ('UNBAN', @acc, 'AdminBruno', 'Apelacao aceita - falso positivo');
GO

E para revisar o que a equipe andou fazendo — essencial contra abuso de poder:

SELECT ActionType, TargetAcc, GMName, Reason, CreatedAt, ExpireAt
FROM dbo.Moderation_Log
WHERE CreatedAt >= DATEADD(DAY, -7, GETDATE())
ORDER BY CreatedAt DESC;

Erros comuns e soluções

Checklist de lançamento

• Comandos de GM habilitados e testados em conta de teste
• Níveis mínimos (MinLevelBan, etc.) mapeados ao CtlCode real
• Tabela Moderation_Log criada e recebendo registros
• Ban de conta testado: bloqueio, desconexão e desban validados
• Procedure SP_ExpireBans agendada e Agent rodando
• Tabela/comando de mute funcionando conforme o build
• IPBanList.txt posicionado e lido pelo ConnectServer
• Fluxo de moderação documentado para a equipe
• Motivo textual obrigatório definido em toda punição
• Rotina de revisão semanal da auditoria agendada
• Backup do banco feito antes de liberar em produção

Com essa estrutura no lugar, seu servidor deixa de reagir no improviso e passa a moderar com método: cada punição é proporcional, registrada, reversível e auditável. É a diferença entre um servidor que os jogadores respeitam e um que abandonam à primeira injustiça.

Perguntas frequentes