How to Configure Staff Permission Levels in MU Online

Defining staff permission levels is what separates a MU Online server run with professionalism from one that lives on the edge of disaster. Without a clear hierarchy, you either give Admin power to everyone — and one day someone creates perfect items and breaks the economy — or you centralize everything in a single person, who becomes a bottleneck and a single point of failure. The right path is to design a scale of levels, map each team role to a level, and configure it both in the database and in the server config, with logging and auditing on top. This tutorial shows how to do that design and implement it, keeping in mind that field names, ctl_code values, and command names are examples that vary by season/emulator.

Prerequisites

• Database access (SSMS for MSSQL, phpMyAdmin/HeidiSQL for MySQL) to edit the accounts' level field.
• Access to the commands file and the GameServer config, where the GMList and each command's minimum level live.
• Knowledge of your emulator's model: whether it uses only ctl_code, only the GMList, or the two combined.
• A mapped team: knowing how many people there are and what each one does (moderate chat, organize events, ban hackers, manage the economy).
• A test environment to validate the hierarchy before applying it in production.
• An already-working server. If you're still building the base, first see how to create a MU Online server.

Why hierarchy matters

In a living community, administrative tasks carry very different risks. Muting a flamer is reversible and low-impact. Creating a perfect item or crediting coin is irreversible and affects everyone's economy. If those actions live at the same access level, you can't trust a rookie moderator without handing them the power to destroy the server. The hierarchy solves this by separating moderation power from value-generation power. The higher the risk of an action, the higher the level required and the fewer people who hold it.

Step 1 — Design the level scale

Before touching any file, sketch the scale on paper. A lean and effective example model:

Notice that each level inherits what the one below can do and adds power. An Admin can do everything a Senior GM can, and more. Avoid creating too many levels at the start: three to five cover almost every server. You can always add an intermediate level later.

Step 2 — Map commands to levels

With the scale ready, decide which minimum level each command requires. This is the part that protects the server the most. Example mapping (command names vary by season/emulator):

The golden rule: no value-generating command below the Admin level. Creating items, giving zen, crediting coin, or altering resets in bulk are powers that, in the wrong hands, ruin the economy and the community's trust.

Step 3 — Configure it in the database

Each account's level lives in the ctl_code field (or its equivalent). Set every staff member to their mapped level:

USE MuOnline;

-- Set the team's levels (example values)
UPDATE MEMB_INFO SET ctl_code = 1 WHERE memb___id = 'helper_ana';
UPDATE MEMB_INFO SET ctl_code = 2 WHERE memb___id = 'gm_carlos';
UPDATE MEMB_INFO SET ctl_code = 3 WHERE memb___id = 'gmsr_marina';
UPDATE MEMB_INFO SET ctl_code = 8 WHERE memb___id = 'adm_bruno';

-- Audit the current hierarchy
SELECT memb___id, memb_name, ctl_code
FROM MEMB_INFO
WHERE ctl_code > 0
ORDER BY ctl_code DESC;

The numeric ctl_code values that correspond to each role vary by emulator — in some 8 is Admin, in others the scale is different. Check what your build recognizes as Admin before applying it.

Step 4 — Configure the GMList and the command levels

Many emulators require, in addition to ctl_code, a GMList in the GameServer config, and define each command's minimum level in a dedicated file. Example (ini):

[GMList]
; nick = level (varies by emulator)
helper_ana   = 1
gm_carlos    = 2
gmsr_marina  = 3
adm_bruno    = 8

[CommandLevels]
; command = minimum access level
Move        = 1
Post        = 2
Mute        = 2
Disconnect  = 3
Ban         = 3
CreateItem  = 8
AddCoin     = 8

[GMConfig]
LogGMCommands = 1   ; log every GM action

Keep ctl_code, the GMList, and CommandLevels consistent with each other. An inconsistency — an account with a high level in the database but a low level in the GMList — is usually the cause of "my GM can't ban even though they're senior."

Step 5 — Apply least privilege

The principle of least privilege is the heart of a good hierarchy: each person gets exactly what they need, nothing more. An event organizer needs to open Blood Castle and announce, not create items. A Discord moderator who helps in-game needs to move and mute, not ban accounts. By applying this, you reduce the number of accounts capable of causing critical damage — which shrinks the attack surface and simplifies auditing. Whenever you're in doubt between two levels, start with the lower one and move up if needed.

Step 6 — Enable logging and auditing

A hierarchy without logging is just a suggestion. Configure the LogServer or the GameServer logs to record every sensitive action: who banned whom, who created which item, who credited coin, when, and to whom. On top of that:

1. Review the logs of level-4 commands (value generators) daily during the first months.
2. Audit accounts with ctl_code > 0 monthly to catch forgotten access.
3. Cross-reference spikes of rare items or zen in the economy with the administrative logs.
4. Keep the logs long enough to investigate incidents retroactively.

Step 7 — Document the staff policy

Write a short internal document that states, for each level: what's allowed, what's not, and who they report to. This avoids misunderstandings and serves as a reference when someone asks for "more access." Include the promotion procedure (how a GM becomes a Senior GM) and the revocation one (what happens when someone leaves). A team that knows its own boundaries abuses less and works better.

Revocation and level changes

Permission is dynamic. Promote, demote, or revoke as the team changes:

-- Demote a Senior GM back to GM
UPDATE MEMB_INFO SET ctl_code = 2 WHERE memb___id = 'gmsr_marina';

-- Revoke access for someone who left the team
UPDATE MEMB_INFO SET ctl_code = 0 WHERE memb___id = 'gm_que_saiu';

When revoking, remember to remove the nick from the GMList too and to change any password that was shared. Do it the same day the person leaves — forgotten administrative access is a silent risk.

Common errors and fixes

Best practices

• Start with few levels (3 to 5) and evolve as the team grows.
• Never leave value-generating commands below the Admin level.
• Apply least privilege: when in doubt, the lower level.
• Keep ctl_code, the GMList, and command levels always in sync.
• Logging is mandatory on every sensitive action, with periodic auditing.
• Document each level's policy and the promotion/revocation flow.
• Revoke access on the same day someone leaves the team.

Launch checklist

• Level scale designed and documented
• Team roles mapped to levels
• Each command with a defined minimum level
• Value-generating commands restricted to the Admin level
• ctl_code applied per account with least privilege
• GMList and command levels synced with the database
• GM command logging enabled and tested
• Hierarchy validated in staging, including denial of an above-level command
• Staff policy written and shared with the team
• Promotion and revocation procedure defined
• Periodic audit of accounts with access scheduled

Frequently asked questions