Cómo Migrar tu Servidor MU Online de Season 6 a Season 13

Migrar un servidor MU Online de Season 6 a Season 13 es uno de los procesos de administración más complejos que puede enfrentar un operador de servidor privado. La diferencia entre ambas versiones no es solo cosmética: el motor del juego, el sistema de habilidades, la estructura de la base de datos y el formato de los archivos de configuración cambiaron de forma sustancial. Esta guía cubre el proceso técnico completo, desde la auditoría inicial hasta la validación final, con el objetivo de que la transición preserve la integridad de los datos de todos los jugadores.

Auditoría Previa: Conoce lo que Tienes Antes de Mover Cualquier Archivo

Antes de tocar un solo archivo de configuración, es fundamental documentar el estado actual del servidor. Una migración sin auditoría previa es una migración que probablemente fallará en el peor momento posible.

Comienza por relevar la versión exacta de tu instalación S6. No todas las compilaciones de Season 6 son iguales: existen variantes con parches personalizados, expansiones de clase no oficiales o modificaciones en las tablas de experiencia. Cada una de esas variaciones puede generar incompatibilidades silenciosas durante la conversión de datos.

Documenta los siguientes puntos antes de continuar:

• Version del ejecutable del GameServer y del DataServer
• Esquema de la base de datos actual (tablas personalizadas, procedimientos almacenados modificados)
• Lista de mapas habilitados, incluyendo mapas no estándar
• Configuración de eventos activos (Blood Castle, Devil Square, Chaos Castle, Kundun)
• Número total de cuentas, personajes e ítems en base de datos

> [!ATENCION] > Nunca ejecutes scripts de migración directamente sobre la base de datos de producción. Trabaja siempre sobre una copia restaurada en un entorno de pruebas aislado. Un error en un script SQL puede corromper años de datos de jugadores de forma irreversible.

Preparación del Entorno de Migración

Con la auditoría completa, el siguiente paso es construir un entorno de migración separado. Esto significa levantar una instancia paralela del motor de base de datos (generalmente Microsoft SQL Server 2008 R2 o superior, dependiendo de la compilación S13 que utilices) y restaurar un backup completo de producción en ese entorno.

La estructura de directorios recomendada para el entorno de migración es la siguiente:

D:\MU_Migration\
  ├── backup_s6\               → Backup original de producción S6
  ├── db_s13_clean\            → Base de datos limpia de S13 (esquema vacío)
  ├── scripts_conversion\      → Scripts SQL de transformación de datos
  ├── config_s6\               → Archivos de configuración originales
  ├── config_s13\              → Archivos de configuración destino
  └── logs\                    → Registros de cada etapa del proceso

Una vez que la base de datos de S6 está restaurada en el entorno de pruebas, ejecuta una validación de integridad referencial. Muchos servidores S6 acumulan registros huérfanos a lo largo del tiempo: personajes sin cuenta asociada, ítems en el inventario de personajes que ya no existen, o entradas en tablas de guild con miembros eliminados. Todos estos problemas deben resolverse antes de comenzar la conversión.

-- Detectar personajes sin cuenta asociada
SELECT c.Name, c.AccountID
FROM Character c
LEFT JOIN MemAccount a ON c.AccountID = a.memb___id
WHERE a.memb___id IS NULL;
→ Registrar resultados en logs\orphan_characters.txt

-- Detectar ítems huérfanos en inventario
SELECT i.ItemSerial, i.Name
FROM Items i
LEFT JOIN Character c ON i.CharacterName = c.Name
WHERE c.Name IS NULL;
→ Registrar resultados en logs\orphan_items.txt

-- Detectar guilds con Master eliminado
SELECT g.G_Name, g.G_Master
FROM GuildInfo g
LEFT JOIN Character c ON g.G_Master = c.Name
WHERE c.Name IS NULL;
→ Registrar resultados en logs\orphan_guilds.txt

Conversión de Esquemas y Migración de Datos

Esta es la etapa más técnica del proceso. El esquema de S13 introduce nuevas tablas para el sistema de Master Level expandido, el Majestic Level, los Wings de nivel 4, el sistema de sockets y las opciones de ítem adicionales que no existían en S6.

El proceso de conversión sigue este flujo general:

Base S6 restaurada
  → Limpieza de registros huérfanos
  → Mapeo de columnas Character (S6 → S13)
  → Conversión de tabla Items con nuevos campos de socket
  → Migración de skills al formato MasterSkillTree
  → Inserción en esquema S13 limpio
  → Validación de conteos (cuentas, personajes, ítems)
  → Prueba funcional con cliente S13

La tabla Character es la que más cambios estructurales presenta. En S6, las estadísticas de Master Level se almacenaban en columnas fijas (ml_strength, ml_agility, etc.). En S13, ese modelo fue reemplazado por una tabla relacional CharacterMasterSkill donde cada habilidad del árbol Maestro tiene su propio registro. El script de conversión debe iterar cada personaje y generar las filas correspondientes en la nueva tabla.

Para los ítems, el campo más crítico es el de opciones de socket. En S6, ese espacio de bytes era ignorado o usado de forma no estándar. En S13, cada socket tiene un formato específico de 1 byte que representa el tipo de piedra equipada. El script de conversión debe inicializar esos bytes en cero (sin piedra) para todos los ítems migrados, evitando que el cliente interprete basura de datos como opciones inválidas.

> [!CONSEJO] > Después de ejecutar los scripts de conversión, compara el conteo total de personajes, ítems y cuentas entre la base de datos original y la migrada. Si hay diferencias, revisa los logs de conversión línea por línea antes de continuar. Una diferencia de un solo personaje puede indicar un error en la lógica de mapeo que afecta a cientos de registros.

Actualización de Archivos de Configuración del Servidor

La base de datos no es lo único que cambia. Los archivos de configuración del GameServer, JoinServer y DataServer también tienen formatos distintos entre S6 y S13. En S6, muchos parámetros se definían en archivos .ini con secciones planas. En S13, parte de esa configuración migró a archivos XML y a tablas dentro de la propia base de datos.

Los archivos que requieren revisión manual obligatoria son:

GameServer\Data\
  ├── MapServerInfo.dat       → Revisar IDs de mapa (S13 agregó nuevos mapas que desplazan índices)
  ├── ItemAddOption.bmd       → Formato extendido en S13 para opciones adicionales
  ├── SkillData.bmd           → Árbol de habilidades completamente reestructurado
  └── MonsterSetBase.bmd      → Nuevos campos para monstruos de Kanturu y Nixies Lake

JoinServer\
  └── JoinServerInfo.xml      → Reemplaza al antiguo JoinServer.ini en la mayoría de builds S13

Presta especial atención al archivo MapServerInfo.dat. En Season 13, varios mapas nuevos fueron insertados en índices que en S6 estaban vacíos o usados de forma no oficial. Si tu servidor S6 tenía mapas personalizados en esos índices, habrá conflictos que deben resolverse reasignando los IDs antes de iniciar el GameServer.

Validación Final y Pruebas Funcionales

Con la base de datos migrada y los archivos de configuración actualizados, llega la etapa de validación. Esta fase no puede reducirse a iniciar el servidor y ver si conecta. Una conexión exitosa no garantiza que los datos estén correctos.

Ejecuta las siguientes pruebas de forma sistemática antes de considerar la migración completa:

Primero, conecta con un personaje de cada clase disponible en S6 y verifica que el inventario, el equipamiento, las estadísticas y las habilidades carguen correctamente. Presta atención especial a los personajes con puntos de Master Level, ya que son los más propensos a mostrar errores después de la conversión del árbol de habilidades.

Segundo, verifica los sistemas de eventos. Blood Castle, Devil Square y Chaos Castle tienen tablas de registro propias que también deben haber migrado correctamente. Un evento que falla al registrar la participación puede generar errores de duplicado que bloqueen el ingreso de jugadores.

Tercero, prueba el sistema de comercio y el mercado personal. En S13 se introdujeron restricciones adicionales sobre ítems comerciables que pueden hacer que ítems previamente intercambiables en S6 aparezcan como bloqueados para el intercambio. Revisa las tablas de configuración de ítems para ajustar esos flags según corresponda.

-- Verificar integridad referencial final: personajes sin cuenta
SELECT c.Name, c.AccountID
FROM Character c
LEFT JOIN MEMB_INFO m ON c.AccountID = m.memb___id
WHERE m.memb___id IS NULL;
→ Resultado vacío confirma migración íntegra de cuentas y personajes.

-- Verificar ítems migrados sin propietario válido
SELECT i.ItemSlot, i.ItemCode, i.Owner
FROM CharacterItems i
LEFT JOIN Character c ON i.Owner = c.Name
WHERE c.Name IS NULL;
→ Elimina o reasigna estos registros antes de abrir al público.

Una migración bien ejecutada es transparente para el jugador: sus personajes, sus ítems y su progreso deben estar intactos. El trabajo técnico que hay detrás es invisible cuando se hace bien, y devastador cuando se hace mal. Tómate el tiempo necesario en el entorno de pruebas antes de apuntar la migración hacia el servidor de producción.

Preguntas frecuentes