Cómo configurar un servidor de MU Online en el emulador IGCN

Montar un servidor de MU Online en IGCN es, en la práctica, orquestar cinco piezas que deben conversar entre sí en el orden correcto: un SQL Server con las bases restauradas, el DataServer (que habla con la base de datos), el ConnectServer (la puerta de entrada del cliente), el JoinServer (autenticación de cuentas) y el GameServer (el mundo en sí). Si cualquiera de esas piezas apunta a una IP, puerto o contraseña equivocada, el stack sube a medias y el jugador se traba en la pantalla de login. Este tutorial recorre la instalación y configuración completa del IGCN —de la base de datos al primer personaje en el juego— destacando dónde cambian los valores de build en build. Antes de sumergirte, si todavía no tienes la base montada, revisa el tutorial de creación de servidor de MU Online, que cubre los conceptos generales que aquí vamos a aplicar al IGCN específicamente.

Qué es el emulador IGCN

El IGCN es uno de los emuladores (o "MuServer") más usados de la historia de los servidores privados de MU. Reimplementa la lógica de los servidores oficiales, permitiéndote correr tu propio MU sin los binarios de Webzen. Una build típica del IGCN viene organizada en carpetas por servicio — normalmente algo como ConnectServer, DataServer, JoinServer y GameServer (o MuServer\...), cada una con su ejecutable y sus archivos de configuración .dat/.txt. La season más difundida del IGCN en la comunidad es la Season 6, pero existen builds para otras versiones. La regla de oro: cliente y emulador tienen que ser de la misma season.

Requisitos previos

• Windows (Server o Desktop) con privilegios de administrador.
• SQL Server instalado (2008/2012/2014 suelen funcionar sin dolor) y el SQL Server Management Studio (SSMS).
• Visual C++ Redistributables (varias versiones — el IGCN suele exigir 2010/2013/2015 dependiendo de la build).
• La build del IGCN con las bases de datos (.bak o scripts .sql) incluidas.
• Un cliente de MU compatible con la season del emulador.
• Conocimiento básico de firewall y redireccionamiento de puertos, en caso de que vayas a abrir hacia afuera.
• Backup de todo antes de editar cualquier archivo.

Arquitectura: las piezas y el orden de inicialización

Cada servicio tiene una responsabilidad y una dependencia. Levanta siempre en este orden:

Invertir ese orden es la causa n.º 1 de "el GameServer abre y se cierra solo". Sin DataServer al aire, nadie habla con la base de datos.

Paso 1 — Preparar el SQL Server y restaurar las bases

1. Instala el SQL Server en modo mixto (SQL Server and Windows Authentication) y define una contraseña para el usuario sa. Anota esa contraseña — va en varios archivos .dat.
2. Abre el SSMS y conéctate a la instancia local (ej.: .\SQLEXPRESS o localhost).
3. Restaura las bases que vienen en la build. Normalmente son dos: la principal (frecuentemente llamada MuOnline) y una de ranking/eventos (el nombre varía por build). Usa Restore Database apuntando a los .bak, o ejecuta los scripts .sql provistos.

-- Ejemplo de restauración (el nombre del archivo y la ruta varían por build)
RESTORE DATABASE MuOnline
FROM DISK = N'C:\MuServer\DB\MuOnline.bak'
WITH REPLACE, RECOVERY;

1. Confirma que el login sa está habilitado (Security → Logins → sa → Status → Enabled) y que el TCP/IP está activo en el SQL Server Configuration Manager. Sin TCP/IP habilitado, el DataServer no conecta.

> Los nombres de las bases y la contraseña del sa son ejemplos comunes — cada build del IGCN puede usar nombres y contraseñas diferentes. Verifica el README de tu build.

Paso 2 — Instalar dependencias y verificar el ODBC/DSN

Muchas builds del IGCN conectan a la base de datos vía DSN (ODBC). Si la tuya es una de ellas:

1. Abre el ODBC Data Source Administrator (busca odbcad32). En builds de 32 bits, usa el odbcad32 de la carpeta SysWOW64.
2. Crea un System DSN (ej.: nombre MuOnline) apuntando a tu instancia SQL, con autenticación SQL Server (login sa + contraseña).
3. Prueba la conexión dentro del propio asistente. Si falla aquí, va a fallar en el emulador.

Instala también los Visual C++ Redistributables exigidos. Un síntoma clásico de VC++ faltante es que el ejecutable ni siquiera abre, o se cierra sin mensaje.

Paso 3 — Configurar el DataServer

El DataServer es quien realmente habla con la base de datos. En su archivo de configuración (los nombres varían: DataServer.dat, MuOnline.dat, IGC_DataServer.txt, etc.), defines la conexión al SQL. Un bloque típico:

[Database]
ODBC_Name   = MuOnline
DB_User     = sa
DB_Password = suaSenhaAqui
Port        = 55960

• ODBC_Name debe coincidir exactamente con el DSN creado en el paso 2 (o con el nombre de la base de datos, dependiendo de la build).
• DB_Password es la contraseña del sa.
• El Port es el que los otros servicios usan para hallar el DataServer — anótalo.

Levanta el DataServer y verifica en su consola el mensaje de conexión exitosa con la base de datos. Solo avanza cuando esté estable.

Paso 4 — Configurar el ConnectServer y la lista de servidores

El ConnectServer es la puerta de entrada: el cliente se conecta a él primero y recibe la lista de servidores. Dos puntos importan aquí:

1. Puerto de escucha — el puerto al que golpea el cliente (comúnmente algo como 44405, pero varía por build). Debe coincidir con el .dat del cliente (más sobre esto en el Paso 7).
2. Lista de servidores — un archivo (ej.: ServerList.dat) donde defines los GameServers exhibidos, cada uno con una IP y un puerto.

; ServerList.dat (ejemplo — el formato varía por build)
; ServerName  ServerCode  IP            Port
Servidor01     0           127.0.0.1     55901

Para prueba local, usa 127.0.0.1. Para abrir al público, usa la IP externa (o dominio No-IP) de la máquina. Un error clásico es dejar 127.0.0.1 en la lista y después extrañarse de que nadie de afuera consigue entrar.

Paso 5 — Configurar el JoinServer

El JoinServer se ocupa de la autenticación de cuentas — valida usuario y contraseña contra la base de datos (vía DataServer). En su configuración, lo esencial es apuntar al DataServer correcto:

[JoinServer]
DataServerIP   = 127.0.0.1
DataServerPort = 55960
JoinPort       = 55970

• DataServerIP/DataServerPort tienen que apuntar al DataServer del Paso 3.
• JoinPort es el puerto que el GameServer usa para hablar con el JoinServer.

Levanta el JoinServer y confirma, en la consola, que conectó al DataServer. Si queda reconectando en bucle, la IP/puerto del DataServer está equivocada o el DataServer está caído.

Paso 6 — Configurar el GameServer

El GameServer es el mundo jugable. Depende del DataServer y del JoinServer. En los archivos de configuración (los nombres varían: GameServerInfo.dat, IGC_GameServer.txt, GameServer.dat), los campos críticos son:

Además de las conexiones, es aquí donde comienzas a personalizar el servidor: tasas de EXP y drop, límites de reset, eventos y demás — pero eso solo después de que el stack esté de pie y logueando. Levanta el GameServer al final. Si conecta y se cae, revisa DataServer/JoinServer (orden e IP/puerto).

Paso 7 — Configurar el cliente y el main/.dat de conexión

Del lado del cliente, el jugador debe apuntar a tu ConnectServer. Dependiendo de la season, esto se hace editando un archivo de conexión (frecuentemente cifrado — ej.: un .dat leído por el main.exe) con la IP y el puerto del ConnectServer:

; Ejemplo conceptual — el formato real suele estar cifrado
IpAddress = 127.0.0.1
Port      = 44405

Reglas prácticas:

1. El puerto aquí tiene que ser el mismo del ConnectServer (Paso 4).
2. Para prueba local, 127.0.0.1; para público, la IP externa/dominio.
3. Cliente y emulador tienen que ser de la misma season, o el cliente crashea en el login.
4. Si tu build usa launcher con verificación de archivos, genera/actualiza la lista de hashes después de editar el cliente.

Paso 8 — Firewall, puertos e IP externa

Para que entren jugadores de afuera, abre los puertos usados — típicamente el del ConnectServer y el de cada GameServer — en el Firewall de Windows y, si estás detrás de un router, haz el redireccionamiento de puertos (port forwarding) hacia la IP interna de la máquina.

# Ejemplo: abrir el puerto del ConnectServer en el Firewall de Windows (ajusta el puerto)
netsh advfirewall firewall add rule name="MU ConnectServer" dir=in action=allow protocol=TCP localport=44405

Sin IP fija, usa un servicio de DNS dinámico (No-IP/DuckDNS) y coloca el dominio en la ServerList y en el cliente. Nunca expongas el puerto del SQL Server (1433) a internet — deja la base de datos accesible solo localmente.

Paso 9 — Primera prueba de login en el juego

1. Levanta el stack en orden: SQL → DataServer → ConnectServer → JoinServer → GameServer.
2. Verifica que cada consola mostró conexión exitosa (sin bucles de reconexión).
3. Abre el cliente, crea una cuenta (el registro puede ser vía web/tool o directo en la base de datos, según la build).
4. Loguéate: debes ver la lista de servidores (ConnectServer OK) y poder entrar al mundo (JoinServer + GameServer OK).
5. Crea un personaje y camina algunos pasos — si el char aparece y el mapa carga, tu stack está sano.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• SQL Server en modo mixto, sa habilitado y TCP/IP activo.
• Bases restauradas y DSN/ODBC probado con éxito.
• VC++ Redistributables instalados.
• DataServer conectado a la base de datos (consola limpia).
• ConnectServer con el puerto correcto y ServerList configurada.
• JoinServer apuntando al DataServer correcto.
• GameServer con ServerCode, IPs y puertos coincidiendo con el resto.
• Cliente de la misma season apuntando al ConnectServer.
• Firewall/router abiertos (puertos del Connect y del Game); SQL cerrado hacia afuera.
• Login, creación de cuenta y entrada al mundo probados de punta a punta.
• Backup de la base de datos y de la carpeta del MuServer antes de abrir al público.

Con el stack de pie y el primer login funcionando, el trabajo pesado de infraestructura terminó — de aquí en adelante es ajuste de proyecto: tasas de EXP y drop, eventos, resets, sistemas de ítems y la economía de tu servidor. Documenta cada puerto, IP y contraseña en un archivo interno (fuera del cliente público): cuando el servidor crezca y separes la base de datos en otra máquina, ese mapa de conexiones es lo que evita horas de dolor de cabeza.

Preguntas frecuentes