How to set up the ban/mute/kick system in MU Online

Moderating a MU Online server without a well-structured punishment system is like driving with no brakes: sooner or later you crash. Toxic players in chat, bot users, bug exploiters, and repeat offenders who create new accounts after every ban will test your server's limits every day. The answer is a clear ladder of punishments — kick for a momentary nuisance, mute for chat abuse, and ban for serious offenses — backed by reliable GM commands, database records, and a policy that withstands appeals. This guide shows how to build that complete system, from the configuration file to the audit SQL. The column names, commands, and paths are examples that vary by season/emulator, so confirm each one on your build before applying it in production.

Prerequisites

Before starting, make sure you have:

• Administrator access to the server directory (e.g., C:\MuServer\).
• SQL Server Management Studio (SSMS) connected to the MuOnline database.
• A GM account with an authority level high enough to use administrative commands.
• SQL Server Agent enabled, if you want to automate temporary bans.
• A complete backup of the database and configuration files.
• Knowledge of the exact name of your build's account tables (MEMB_INFO, MEMB_STAT, AccountCharacter, etc.).

> Never test ban commands in production with real player accounts. Create a test account and validate the whole flow (ban, verify the block, unban) before releasing the commands to the team.

Understanding the punishment ladder

Before configuring anything, it's essential that your team understands the difference between the three actions and when to apply each. The table below summarizes the severity ladder most servers adopt.

The golden rule is proportionality: start with the lightest punishment that solves the problem and escalate only in the face of repeat offenses or severity. A player who cursed once deserves a mute, not a permanent ban. A bot user caught red-handed deserves a straight ban.

Step 1 — Configure the GM commands on the server

Most emulators expose administrative chat commands that only work for accounts with an adequate authority level. These commands are enabled in a GameServer configuration file, usually in GameServer\Data\ or in GameServer.ini itself. An example block:

[GMCommands]
EnableCommands   = 1
KickCommand      = /kick        ; /kick <nick>
MuteCommand      = /mute        ; /mute <nick> <minutes>
UnmuteCommand    = /unmute      ; /unmute <nick>
BanCommand       = /ban         ; /ban <account> <hours> <reason>
BanIPCommand     = /banip       ; /banip <ip> <hours>
DisconnectCmd    = /disc        ; /disc <nick>
MinLevelKick     = 8            ; minimum GM level for kick
MinLevelMute     = 8
MinLevelBan      = 16           ; ban restricted to high level
MinLevelBanIP    = 32           ; IP ban only for admin

The level numbers (MinLevelBan, etc.) reference the account's authority field — in many builds the CtlCode column of MEMB_INFO, where values like 0 = player, 8 = regular GM, 16 = senior GM, and 32 = administrator. These values vary by season/emulator; check the mapping in your build.

After editing, restart the GameServer so it rereads the configuration. Many builds don't reload commands live.

Step 2 — Prepare the audit structure in the database

A punishment system with no records is an invitation to abuse and endless arguments with players. Create an audit table that stores every moderation action:

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,       -- duration in minutes (NULL = permanent)
    CreatedAt    DATETIME     DEFAULT GETDATE(),
    ExpireAt     DATETIME     NULL        -- when the ban/mute expires
);
GO

This table is the backbone of the whole system. Every time a GM applies a punishment, a record enters here — whether via the in-game command (if the emulator has a log hook) or via the manual query you run yourself.

Step 3 — Apply an account ban via SQL

The classic account ban consists of marking the account's block flag. In most schemas that's the bloc_code column of MEMB_INFO (0 = enabled, 1 = blocked):

USE MuOnline;
GO

-- Ban the account 'suspiciousAcc' for 72 hours
DECLARE @acc VARCHAR(10) = 'suspiciousAcc';
DECLARE @gm  VARCHAR(10) = 'AdminBruno';
DECLARE @hours INT = 72;

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

-- Disconnect immediately if online
UPDATE MEMB_STAT
SET ConnectStat = 0
WHERE memb___id = @acc;

-- Record in the audit table with an expiration date
INSERT INTO dbo.Moderation_Log
    (ActionType, TargetAcc, GMName, Reason, DurationMin, ExpireAt)
VALUES
    ('BAN', @acc, @gm, 'Bot use confirmed by log', @hours * 60,
     DATEADD(HOUR, @hours, GETDATE()));
GO

Notice that the ban deletes nothing: the character, the items, and the Zen remain intact. This is intentional. A correct punishment is reversible; deleting an account is data destruction and blocks any fair appeal.

Step 4 — Automate temporary bans with expiration

Recording the expiration date is useless if no one removes the block when it arrives. Create a stored procedure that scans the audit table and releases accounts whose ban has expired:

USE MuOnline;
GO

CREATE PROCEDURE dbo.SP_ExpireBans
AS
BEGIN
    SET NOCOUNT ON;

    -- Unban accounts whose temporary ban has already expired
    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 'Expired bans processed: ' + CAST(GETDATE() AS VARCHAR);
END;
GO

Schedule this procedure in SQL Server Agent to run every 10 minutes (SSMS → SQL Server Agent → Jobs → New Job → Steps: EXEC dbo.SP_ExpireBans; → Schedules: every 10 minutes). That way, a 72-hour ban resolves itself, with no manual intervention.

Step 5 — Implement the mute system

Mute is usually controlled by a flag or an auxiliary table that the GameServer consults when processing a chat message. On builds that support native mute via the /mute command, the emulator itself handles it. For builds that don't, you set up a table and the GameServer (or a plugin) checks it before allowing 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

-- Mute 'SpammerPlayer' for 30 minutes
INSERT INTO dbo.Chat_Mute (CharName, MutedUntil, GMName, Reason)
VALUES ('SpammerPlayer', DATEADD(MINUTE, 30, GETDATE()),
        'GMGabriel', 'Trade flood in global chat');
GO

If your emulator doesn't read that table natively, the mute has to be applied via an in-game command instead of SQL. This varies by season/emulator — check whether the build supports database-driven mute before relying on this approach.

Step 6 — IP and HWID bans

Repeat offenders who create new accounts require a layer beyond the account ban. The IP ban is usually done via a list file in the ConnectServer:

# ConnectServer\IPBanList.txt  (format varies by build)
201.10.55.32
189.44.0.0-189.44.255.255

The HWID ban, when the emulator offers it, blocks the client's hardware identifier, which is much harder to bypass than switching IPs. Not every build supports HWID — in many cases it depends on a bundled anti-cheat module. If your server has it, also record the HWID in the audit table to track repeat offenders.

> IP bans catch innocents. Families, LAN houses, and networks with NAT share the same public IP. Use IP bans only for confirmed repeat offenders and prefer narrow ranges over broad blocks. An overly broad IP ban can pull dozens of legitimate players off the server without you noticing.

Step 7 — Moderation team workflow

A tool without a process doesn't work. Define a clear flow for the team:

1. Receive the report (ticket, screenshot, automatic log).
2. Verify the evidence — never punish based on an accusation alone.
3. Choose the proportional punishment according to the severity ladder.
4. Apply it via command or SQL with a mandatory text reason.
5. Record it in the audit table (automatic or manual).
6. Notify the player of the reason and duration, when applicable.
7. Keep the evidence for at least 30 days for a possible appeal.

This process protects both the server and the player. If this foundational material isn't live yet, it's worth first reviewing the guide on how to create a MU Online server before building the moderation layer.

Step 8 — Review and unban queries

To unban an account after a successful appeal:

USE MuOnline;
GO

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

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

INSERT INTO dbo.Moderation_Log (ActionType, TargetAcc, GMName, Reason)
VALUES ('UNBAN', @acc, 'AdminBruno', 'Appeal accepted - false positive');
GO

And to review what the team has been doing — essential against abuse of power:

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

Common errors and fixes

Launch checklist

• GM commands enabled and tested on a test account
• Minimum levels (MinLevelBan, etc.) mapped to the real CtlCode
• Moderation_Log table created and receiving records
• Account ban tested: block, disconnection, and unban validated
• SP_ExpireBans procedure scheduled and Agent running
• Mute table/command working according to the build
• IPBanList.txt in place and read by the ConnectServer
• Moderation flow documented for the team
• Mandatory text reason defined on every punishment
• Weekly audit review routine scheduled
• Database backup taken before releasing in production

With this structure in place, your server stops reacting on the fly and starts moderating with method: every punishment is proportional, recorded, reversible, and auditable. It's the difference between a server players respect and one they abandon at the first injustice.

Frequently asked questions