Cómo configurar niveles de permiso de staff en MU Online

Definir niveles de permiso de staff es lo que separa un servidor de MU Online administrado con profesionalismo de uno que vive al borde del desastre. Sin una jerarquía clara, o le das poder de Admin a todo el mundo — y un día alguien crea ítems perfectos y quiebra la economía — o centralizas todo en una sola persona, que se vuelve cuello de botella y punto único de falla. El camino correcto es diseñar una escala de niveles, mapear cada función del equipo a un nivel, y configurar esto tanto en la base como en el config del servidor, con log y auditoría por encima. Este tutorial muestra cómo hacer ese diseño e implementarlo, recordando que nombres de campos, valores de ctl_code y nombres de comando son ejemplos que varían según season/emulador.

Requisitos previos

• Acceso a la base de datos (SSMS para MSSQL, phpMyAdmin/HeidiSQL para MySQL) para editar el campo de nivel de las cuentas.
• Acceso al archivo de comandos y al config del GameServer, donde vive la GMList y el nivel mínimo de cada comando.
• Conocimiento del modelo de tu emulador: si usa solo ctl_code, solo GMList, o los dos combinados.
• Un equipo mapeado: saber cuántas personas hay y qué hace cada una (moderar chat, organizar evento, banear hacker, administrar economía).
• Entorno de prueba para validar la jerarquía antes de aplicarla en producción.
• Un servidor ya funcional. Si aún estás montando la base, ve primero cómo crear un servidor de MU Online.

Por qué importa la jerarquía

En una comunidad viva, las tareas administrativas tienen riesgos muy diferentes. Silenciar a un flamer es reversible y de bajo impacto. Crear un ítem perfecto o acreditar coin es irreversible y afecta la economía de todos. Si esas acciones viven en el mismo nivel de acceso, no puedes confiar en un moderador novato sin entregarle el poder de destruir el servidor. La jerarquía resuelve esto separando poder de moderación de poder de generación de valor. Cuanto más alto el riesgo de una acción, más alto el nivel exigido y menos personas lo poseen.

Paso 1 — Diseñar la escala de niveles

Antes de tocar cualquier archivo, diseña la escala en papel. Un modelo escueto y eficaz de ejemplo:

Nota que cada nivel hereda lo que el anterior puede hacer y agrega poder. Un Admin puede todo lo que un GM Sénior puede, y más. Evita crear demasiados niveles al comienzo: de tres a cinco cubren casi todos los servidores. Siempre puedes agregar un nivel intermedio después.

Paso 2 — Mapear comandos a niveles

Con la escala lista, decide qué nivel mínimo exige cada comando. Esta es la parte que más protege el servidor. Ejemplo de mapeo (los nombres de comando varían según season/emulador):

La regla de oro: ningún comando generador de valor por debajo del nivel de Admin. Crear ítem, dar zen, acreditar coin o alterar resets en masa son poderes que, en las manos equivocadas, arruinan la economía y la confianza de la comunidad.

Paso 3 — Configurar en la base de datos

El nivel de cada cuenta vive en el campo ctl_code (o equivalente). Configura a cada miembro del staff en el nivel mapeado:

USE MuOnline;

-- Definir níveis da equipe (valores de exemplo)
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';

-- Auditar a hierarquia atual
SELECT memb___id, memb_name, ctl_code
FROM MEMB_INFO
WHERE ctl_code > 0
ORDER BY ctl_code DESC;

Los valores numéricos de ctl_code que corresponden a cada rol varían según el emulador — en algunos 8 es Admin, en otros la escala es diferente. Verifica qué reconoce tu build como Admin antes de aplicar.

Paso 4 — Configurar la GMList y los niveles de comando

Muchos emuladores exigen, además del ctl_code, una GMList en el config del GameServer, y definen el nivel mínimo de cada comando en un archivo propio. Ejemplo (ini):

[GMList]
; nick = nível (varia por emulador)
helper_ana   = 1
gm_carlos    = 2
gmsr_marina  = 3
adm_bruno    = 8

[CommandLevels]
; comando = nível mínimo de acesso
Move        = 1
Post        = 2
Mute        = 2
Disconnect  = 3
Ban         = 3
CreateItem  = 8
AddCoin     = 8

[GMConfig]
LogGMCommands = 1   ; registrar toda ação de GM

Mantén ctl_code, GMList y CommandLevels coherentes entre sí. Una inconsistencia — cuenta con nivel alto en la base pero nivel bajo en la GMList — suele ser la causa de "mi GM no puede banear aun siendo sénior".

Paso 5 — Aplicar el menor privilegio

El principio del menor privilegio es el corazón de una buena jerarquía: cada persona recibe exactamente lo que necesita, nada más. Un organizador de eventos necesita abrir Blood Castle y anunciar, no necesita crear ítems. Un moderador de Discord que ayuda en el juego necesita mover y silenciar, no necesita banear cuentas. Al aplicar esto, reduces el número de cuentas capaces de causar daño crítico — lo que disminuye la superficie de ataque y simplifica la auditoría. Siempre que dudes entre dos niveles, empieza por el más bajo y sube si es necesario.

Paso 6 — Habilitar log y auditoría

Una jerarquía sin log es solo una sugerencia. Configura el LogServer o los logs del GameServer para registrar toda acción sensible: quién baneó a quién, quién creó qué ítem, quién acreditó coin, cuándo y a quién. Además:

1. Revisa diariamente los logs de comandos de nivel 4 (generadores de valor) en los primeros meses.
2. Haz auditoría mensual de las cuentas con ctl_code > 0 para detectar accesos olvidados.
3. Cruza picos de ítems raros o zen en la economía con los logs administrativos.
4. Guarda los logs por tiempo suficiente para investigar incidentes retroactivos.

Paso 7 — Documentar la política de staff

Escribe un documento interno corto que diga, para cada nivel: qué puede, qué no puede, y a quién se reporta. Esto evita malentendidos y sirve de referencia cuando alguien pide "más acceso". Incluye el procedimiento de promoción (cómo un GM se vuelve GM Sénior) y el de revocación (qué pasa cuando alguien se va). Un equipo que conoce sus propias fronteras abusa menos y trabaja mejor.

Revocación y cambios de nivel

El permiso es dinámico. Promueve, degrada o revoca conforme cambia el equipo:

-- Rebaixar um GM Sênior de volta a GM
UPDATE MEMB_INFO SET ctl_code = 2 WHERE memb___id = 'gmsr_marina';

-- Revogar acesso de quem saiu da equipe
UPDATE MEMB_INFO SET ctl_code = 0 WHERE memb___id = 'gm_que_saiu';

Al revocar, recuerda quitar el nick de la GMList también y cambiar cualquier contraseña que se haya compartido. Hazlo el mismo día de la salida — un acceso administrativo olvidado es un riesgo silencioso.

Errores comunes y soluciones

Buenas prácticas

• Empieza con pocos niveles (3 a 5) y evoluciona conforme crece el equipo.
• Nunca dejes comandos generadores de valor por debajo del nivel de Admin.
• Aplica el menor privilegio: en la duda, el nivel más bajo.
• Mantén ctl_code, GMList y niveles de comando siempre sincronizados.
• Log obligatorio en toda acción sensible, con auditoría periódica.
• Documenta la política de cada nivel y el flujo de promoción/revocación.
• Revoca el acceso el mismo día en que alguien deja el equipo.

Lista de verificación de lanzamiento

• Escala de niveles diseñada y documentada
• Funciones del equipo mapeadas a niveles
• Cada comando con nivel mínimo definido
• Comandos generadores de valor restringidos al nivel de Admin
• ctl_code aplicado por cuenta con menor privilegio
• GMList y niveles de comando sincronizados con la base
• Log de comandos de GM habilitado y probado
• Jerarquía validada en staging, incluyendo la negación de comando por encima del nivel
• Política de staff escrita y compartida con el equipo
• Procedimiento de promoción y revocación definido
• Auditoría periódica de cuentas con acceso programada

Preguntas frecuentes