Cómo resolver la duplicidad de personaje tras un crash en el servidor de MU Online

La duplicidad de personaje —cuando el mismo personaje, con el mismo nombre y cuenta, aparece en dos estados diferentes en la base de datos tras un crash del GameServer o una caída abrupta de conexión— es uno de los incidentes más delicados que un administrador de servidor de MU Online puede enfrentar. Toca directamente la confianza del jugador (después de todo, es su personaje y sus ítems los que están en riesgo) y, si se resuelve mal, puede generar acusaciones de dupe intencional de ítems. Este tutorial muestra cómo diagnosticar la causa raíz, investigar la base de datos con seguridad, decidir qué registro conservar e implementar prevención para no repetir el incidente.

Cómo ocurre técnicamente la duplicidad

El flujo normal de un personaje en MU es: el cliente se conecta, el GameServer carga los datos de la base a la memoria, el jugador juega, y periódicamente (o al hacer logout) el GameServer guarda el estado de vuelta en la base. La duplicidad surge cuando ese ciclo se interrumpe de forma inconsistente:

1. El jugador está en línea, con el personaje cargado en la memoria del proceso del GameServer.
2. El GameServer se traba (crash) o la conexión cae abruptamente, sin completar el guardado final.
3. El jugador se reconecta demasiado rápido (o el watchdog reinicia el proceso automáticamente) antes de que la base tenga la certeza de que la sesión anterior terminó.
4. Pasan a existir dos estados del mismo personaje: el guardado antes del crash y el que estaba en memoria en el momento de la caída — y, según la implementación, ambos pueden generar registros conflictivos.

Síntomas que indican duplicidad

Paso 1 — Aislar la cuenta y suspender el login temporalmente

Antes de tocar la base, impide que el jugador (o cualquier sesión) inicie sesión en la cuenta afectada. Esto evita que una nueva sesión sobrescriba datos mientras investigas. La mayoría de los emuladores tiene una flag de bloqueo de cuenta:

UPDATE MEMB_INFO SET ctlCode = 1 WHERE memb___id = 'nombreDeLaCuenta';

Documenta la hora exacta de la suspensión — eso ayuda a delimitar la ventana de tiempo de la investigación.

Paso 2 — Consultar la base para confirmar duplicidad real

Ejecuta una consulta directa en la tabla de personajes filtrando por cuenta y nombre, para ver si realmente existen registros conflictivos (y no solo un error de caché del cliente):

SELECT Name, AccountID, cLevel, Resets, LastSave
FROM Character
WHERE AccountID = 'nombreDeLaCuenta'
ORDER BY LastSave DESC;

Si aparece más de un registro con el mismo nombre/cuenta, o dos Character.Guid diferentes referenciando ítems con el mismo ItemSerial, tienes duplicidad confirmada — no es un problema de visualización del cliente.

Paso 3 — Comparar los registros y elegir el estado correcto

Nunca asumas que el registro más reciente es el correcto por defecto. Compara:

En la mayoría de los casos, el registro correcto es el que tiene el estado más avanzado y consistente con el relato del jugador, no necesariamente el cronológicamente más reciente en la base (que puede ser un guardado incompleto).

Paso 4 — Hacer el rollback/merge con seguridad

Con el registro correcto identificado, haz siempre un backup de la tabla antes de cualquier alteración:

SELECT * INTO Character_backup_20260731 FROM Character WHERE AccountID = 'nombreDeLaCuenta';

Después, elimina o fusiona el registro incorrecto. Si es una duplicidad simple (dos registros, uno obsoleto), elimina el obsoleto tras confirmar al 100% que no tiene datos que falten en el correcto:

DELETE FROM Character WHERE Guid = 'guid-del-registro-obsoleto';

Si hay ítems legítimos repartidos entre los dos registros (ej.: uno tiene el personaje correcto, el otro tiene un ítem que el jugador realmente consiguió antes del crash), haz un merge manual, moviendo el ítem al inventario del registro correcto antes de eliminar el obsoleto.

Paso 5 — Verificar duplicidad de ítems (dupe de Zen/ítems)

La duplicidad de personaje a veces viene acompañada de duplicidad de ítems específicos — el mismo ItemSerial apareciendo en dos lugares. Esto es más grave porque puede ser explotado deliberadamente. Ejecuta un barrido:

SELECT ItemSerial, COUNT(*) as ocurrencias
FROM Inventory
GROUP BY ItemSerial
HAVING COUNT(*) > 1;

Cualquier ItemSerial con más de una ocurrencia necesita ser investigado individualmente — puede ser el mismo incidente de crash o una explotación de dupe que merece baneo y una reversión más amplia.

Paso 6 — Restaurar la cuenta y comunicar al jugador

Después de corregir el registro, libera la cuenta:

UPDATE MEMB_INFO SET ctlCode = 0 WHERE memb___id = 'nombreDeLaCuenta';

Contacta al jugador explicando qué pasó, qué se restauró y, si aplica, una compensación por el inconveniente (ítems de evento, tiempo de VIP). La transparencia aquí es lo que separa a un servidor confiable de uno que "siempre se traba y pierde ítems".

Prevención — guardado asíncrono y transacciones atómicas

La corrección puntual resuelve el caso, pero no evita la recurrencia. Los cambios estructurales más eficaces:

• Transacciones atómicas para cualquier operación que involucre Zen o ítems (intercambio, compra, uso de NPC) — si la transacción no se completa al 100%, se revierte, no queda "a medias".
• Guardado asíncrono con confirmación: el GameServer solo libera la sesión/lock de la cuenta después de recibir confirmación de escritura de la base, no solo de enviar el comando.
• Lock de sesión por AccountID: impide que la misma cuenta se cargue en dos procesos simultáneamente, escenario clásico tras un reinicio rápido post-crash.
• Watchdog con retraso de reinicio: en vez de reiniciar el GameServer instantáneamente después de un crash, esperar algunos segundos garantiza que las conexiones pendientes de guardado tengan la oportunidad de finalizar o fallar de forma limpia.

Registro y auditoría continua

Mantén un log específico de incidentes de duplicidad, con fecha, cuenta afectada, causa identificada y acción tomada. Esto ayuda a identificar patrones (ej.: siempre ocurre en cierto horario pico, o después de un tipo específico de crash) y a justificar cambios de infraestructura ante la comunidad, si es necesario.

Errores comunes y soluciones

Lista de verificación de respuesta a la duplicidad de personaje

• Cuenta suspendida temporalmente antes de cualquier investigación en la base.
• Consulta a la base confirmando duplicidad real (no error de cliente).
• Registros comparados por timestamp, nivel, inventario y logs del GameServer.
• Backup de la tabla realizado antes de cualquier DELETE/UPDATE.
• Barrido de ItemSerial duplicado realizado.
• Cuenta restaurada y jugador comunicado con transparencia.
• Causa raíz documentada y prevención estructural evaluada (guardado asíncrono, lock, transacciones atómicas).

Los incidentes de duplicidad son un recordatorio de que la estabilidad de la base de datos es tan importante como el balance del juego. Si tu infraestructura aún no tiene una rutina de backup y monitoreo sólida, vale la pena revisar los fundamentos en la guía de creación de servidor de MU Online.

Preguntas frecuentes