Cómo configurar el sistema de ban/mute/kick en MU Online

Moderar un servidor de MU Online sin un sistema de castigos bien estructurado es como manejar sin freno: tarde o temprano chocas. Jugadores tóxicos en el chat, usuarios de bot, explotadores de bugs y reincidentes que crean cuentas nuevas con cada baneo van a poner a prueba los límites de tu servidor todos los días. La respuesta a eso es una escalera de castigos clara —kick para la molestia momentánea, mute para el abuso de chat y ban para las infracciones graves— sostenida por comandos de GM confiables, registros en la base de datos y una política que resista apelaciones. Esta guía muestra cómo montar ese sistema completo, desde el archivo de configuración hasta el SQL de auditoría. Los nombres de columnas, comandos y rutas son ejemplos que varían por season/emulador, así que confirma cada uno en tu build antes de aplicarlo en producción.

Requisitos previos

Antes de empezar, asegúrate de tener:

• Acceso de administrador al directorio del servidor (ej.: C:\MuServer\).
• SQL Server Management Studio (SSMS) conectado a la base de datos MuOnline.
• Una cuenta de GM con nivel de autoridad suficiente para usar comandos administrativos.
• SQL Server Agent habilitado, en caso de que quieras automatización de bans temporales.
• Backup completo de la base de datos y de los archivos de configuración.
• Conocimiento del nombre exacto de las tablas de cuenta de tu build (MEMB_INFO, MEMB_STAT, AccountCharacter, etc.).

> Nunca pruebes comandos de ban en producción con cuentas reales de jugadores. Crea una cuenta de prueba y valida todo el flujo (banear, verificar bloqueo, desbanear) antes de liberar los comandos para el equipo.

Entendiendo la escalera de castigos

Antes de configurar cualquier cosa, es fundamental que tu equipo entienda la diferencia entre las tres acciones y cuándo aplicar cada una. La tabla siguiente resume la escalera de severidad que la mayoría de los servidores adopta.

La regla de oro es la proporcionalidad: empieza por el castigo más leve que resuelva el problema y escala solo ante reincidencia o gravedad. Un jugador que insultó una vez merece mute, no ban permanente. Un usuario de bot pillado en flagrante merece ban directo.

Paso 1 — Configurar los comandos de GM en el servidor

La mayoría de los emuladores expone comandos de chat administrativos que solo funcionan para cuentas con nivel de autoridad adecuado. Esos comandos quedan habilitados en un archivo de configuración del GameServer, generalmente en GameServer\Data\ o en el propio GameServer.ini. Un bloque de ejemplo:

[GMCommands]
EnableCommands   = 1
KickCommand      = /kick        ; /kick <nick>
MuteCommand      = /mute        ; /mute <nick> <minutos>
UnmuteCommand    = /unmute      ; /unmute <nick>
BanCommand       = /ban         ; /ban <cuenta> <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

Los números de nivel (MinLevelBan, etc.) referencian el campo de autoridad de la cuenta: en muchos builds la columna CtlCode de MEMB_INFO, donde valores como 0 = jugador, 8 = GM común, 16 = GM sénior y 32 = administrador. Esos valores varían por season/emulador; verifica el mapeo en tu compilado.

Después de editar, reinicia el GameServer para que relea la configuración. Muchos builds no recargan comandos en caliente.

Paso 2 — Preparar la estructura de auditoría en la base de datos

Un sistema de castigo sin registro es una invitación al abuso y a discusiones interminables con jugadores. Crea una tabla de auditoría que guarde toda acción de moderación:

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,       -- duracion en minutos (NULL = permanente)
    CreatedAt    DATETIME     DEFAULT GETDATE(),
    ExpireAt     DATETIME     NULL        -- cuando expira el ban/mute
);
GO

Esa tabla es la columna vertebral de todo el sistema. Cada vez que un GM aplique un castigo, entra un registro aquí, sea por el comando in-game (si el emulador tiene hook de log) o por la query manual que tú mismo ejecutas.

Paso 3 — Aplicar un ban de cuenta vía SQL

El ban de cuenta clásico consiste en marcar la flag de bloqueo de la cuenta. En la mayoría de los schemas eso es la columna bloc_code de MEMB_INFO (0 = liberada, 1 = bloqueada):

USE MuOnline;
GO

-- Banear la cuenta '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 inmediatamente si esta en linea
UPDATE MEMB_STAT
SET ConnectStat = 0
WHERE memb___id = @acc;

-- Registrar en la auditoria con fecha de expiracion
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

Fíjate en que el ban no elimina nada: el personaje, los ítems y el Zen siguen intactos. Eso es intencional. Un castigo correcto es reversible; eliminar la cuenta es destrucción de datos e impide cualquier apelación justa.

Paso 4 — Automatizar bans temporales con expiración

Registrar la fecha de expiración no sirve de nada si nadie quita el bloqueo cuando llega. Crea un stored procedure que recorra la tabla de auditoría y libere las cuentas cuyo ban expiró:

USE MuOnline;
GO

CREATE PROCEDURE dbo.SP_ExpireBans
AS
BEGIN
    SET NOCOUNT ON;

    -- Desbanear cuentas cuyo ban temporal ya expiro
    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 procesados: ' + CAST(GETDATE() AS VARCHAR);
END;
GO

Agenda ese procedure en el SQL Server Agent para que corra cada 10 minutos (SSMS → SQL Server Agent → Jobs → New Job → Steps: EXEC dbo.SP_ExpireBans; → Schedules: cada 10 minutos). Así, un ban de 72 horas se resuelve solo, sin intervención manual.

Paso 5 — Implementar el sistema de mute

El mute normalmente se controla por una flag o una tabla auxiliar que el GameServer consulta al procesar un mensaje de chat. En builds que soportan mute nativo vía comando /mute, el propio emulador se encarga. Para builds que no lo soportan, montas una tabla y el GameServer (o un plugin) verifica antes de liberar el 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 en el chat global');
GO

Si tu emulador no lee esa tabla nativamente, el mute necesita aplicarse vía comando in-game en lugar de SQL. Esto varía por season/emulador: verifica si el build soporta mute por base de datos antes de depender de ese enfoque.

Paso 6 — Ban por IP y por HWID

Los reincidentes que crean cuentas nuevas exigen una capa más allá del ban de cuenta. El ban de IP suele hacerse por un archivo de lista en el ConnectServer:

# ConnectServer\IPBanList.txt  (el formato varía por build)
201.10.55.32
189.44.0.0-189.44.255.255

El ban por HWID, cuando el emulador lo ofrece, bloquea el identificador de hardware del cliente, siendo mucho más difícil de burlar que cambiar de IP. No todo build tiene soporte a HWID; en muchos casos depende de un módulo anti-cheat acoplado. Si tu servidor lo tiene, registra también el HWID en la tabla de auditoría para rastrear reincidentes.

> El ban de IP atrapa inocentes. Familias, cibercafés y redes con NAT comparten el mismo IP público. Usa el ban de IP solo para reincidentes confirmados y prefiere rangos estrechos a bloqueos amplios. Un ban de IP demasiado amplio puede sacar a decenas de jugadores legítimos del servidor sin que te des cuenta.

Paso 7 — Flujo de trabajo del equipo de moderación

Herramienta sin proceso no funciona. Define un flujo claro para el equipo:

1. Recibir la denuncia (ticket, captura, log automático).
2. Verificar la evidencia — nunca castigues basándote solo en una acusación.
3. Elegir el castigo proporcional según la escalera de severidad.
4. Aplicar vía comando o SQL con motivo textual obligatorio.
5. Registrar en la auditoría (automático o manual).
6. Comunicar al jugador el motivo y la duración, cuando aplique.
7. Guardar la evidencia por al menos 30 días para una eventual apelación.

Ese proceso protege tanto al servidor como al jugador. Si este material de fundación aún no está publicado, vale la pena revisar primero la guía de cómo crear servidor de MU Online antes de montar la capa de moderación.

Paso 8 — Consultas de revisión y desban

Para desbanear una cuenta tras una apelación exitosa:

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', 'Apelacion aceptada - falso positivo');
GO

Y para revisar lo que el equipo estuvo haciendo — esencial contra el abuso de poder:

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

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Comandos de GM habilitados y probados en cuenta de prueba
• Niveles mínimos (MinLevelBan, etc.) mapeados al CtlCode real
• Tabla Moderation_Log creada y recibiendo registros
• Ban de cuenta probado: bloqueo, desconexión y desban validados
• Procedure SP_ExpireBans agendado y Agent corriendo
• Tabla/comando de mute funcionando según el build
• IPBanList.txt posicionado y leído por el ConnectServer
• Flujo de moderación documentado para el equipo
• Motivo textual obligatorio definido en todo castigo
• Rutina de revisión semanal de la auditoría agendada
• Backup de la base de datos hecho antes de liberar en producción

Con esta estructura en su lugar, tu servidor deja de reaccionar improvisando y pasa a moderar con método: cada castigo es proporcional, registrado, reversible y auditable. Es la diferencia entre un servidor que los jugadores respetan y uno que abandonan a la primera injusticia.

Preguntas frecuentes