Cómo configurar anti-dupe (duplicación de ítems) en MU Online

Duplicación de ítems — el famoso dupe — es el problema de seguridad que más destruye servidores de MU Online. A diferencia de un simple cheat de daño o velocidad, que afecta a un jugador, el dupe ataca el corazón del servidor: la economía. Un único ítem raro duplicado en masa se convierte en decenas de Excellent en manos de unos pocos, los precios en Jewel y Zen colapsan, el mercado pierde referencia y los jugadores honestos, sintiendo que el esfuerzo no vale nada, simplemente abandonan el juego. Configurar anti-dupe no es activar una opción mágica en el archivo de configuración; es montar una defensa por capas que vuelve la duplicación imposible o, como mínimo, inmediatamente detectable. Este tutorial avanzado muestra cómo pensar e implementar cada capa.

Antes de cualquier configuración, hay que entender la causa raíz. Prácticamente todo dupe nace del mismo fallo conceptual: una operación que mueve un ítem se trata como dos operaciones independientes — "añadir al destino" y "eliminar del origen" — en lugar de una operación única e indivisible. Si el servidor añade el ítem al baúl, envía la confirmación, y solo después graba la eliminación del inventario, existe una ventana de milisegundos en la que el ítem vive en los dos lugares. Un jugador malintencionado fuerza una desconexión exactamente en esa ventana (tirando del cable de red, usando un lag switch o explotando un timeout) y el servidor persiste solo el estado parcial: el ítem en el baúl permanece, y el inventario se restaura del último save, donde el ítem seguía estando. Dos copias. El anti-dupe, en el fondo, es la disciplina de eliminar todas esas ventanas.

Requisitos previos

• Acceso administrativo al GameServer y a sus archivos de configuración (GameServerInfo, .ini, .dat o equivalentes de tu emulador).
• Acceso a la base de datos (SQL Server o MySQL, según el emulador) con permiso para crear tablas, índices, triggers y stored procedures.
• Conocimiento del esquema de tu emulador: cómo se almacenan los ítems (blob hexadecimal en el inventario/warehouse, o tabla normalizada con serial).
• Entorno de prueba aislado — nunca calibres el anti-dupe directamente en producción. Restaura una copia de seguridad en una máquina separada.
• Herramienta de consulta SQL (SSMS, HeidiSQL, DBeaver) e, idealmente, acceso al código fuente del emulador si es open-source.

> Aviso: todos los nombres de tabla, columna y configuración citados (warehouse, Serial, T_ItemSerial, TradeLock, Money) son ejemplos de emuladores de la línea Season 6 y derivados. Los nombres reales varían por season y por emulador. Confirma el mapeo en tu entorno antes de ejecutar cualquier comando que altere datos.

Si todavía estás montando la base del servidor, la guía de cómo crear un servidor de MU Online cubre la instalación del GameServer y del SGBD antes de que llegues a la capa de seguridad.

Las capas de defensa anti-dupe

No existe una bala de plata. Un anti-dupe robusto apila defensas independientes, de modo que, si una falla, la siguiente aguanta el golpe. Piensa en cinco capas.

Las tres primeras capas previenen; las dos últimas detectan. Un servidor maduro tiene todas. Vamos a configurar cada una.

Capa 1: serial único por ítem

La defensa más fuerte contra el dupe es dar a cada ítem una identidad irrepetible. Si todo ítem Excellent lleva un número de serie único en la base de datos, dos copias con el mismo serial son prueba matemática de duplicación — no hay cómo argumentar. Muchos emuladores modernos ya lo soportan; si el tuyo no lo soporta de forma nativa, se puede añadir una tabla de rastreo.

El concepto es mantener una tabla central de seriales emitidos:

-- Ejemplo (los nombres varían por emulador)
CREATE TABLE T_ItemSerial (
    Serial      BIGINT       NOT NULL PRIMARY KEY,
    ItemCode    INT          NOT NULL,   -- tipo del item (ej.: Espada, Set)
    OwnerChar   VARCHAR(10)  NULL,       -- personaje dueno actual
    OriginType  TINYINT      NOT NULL,   -- 1=drop, 2=craft, 3=evento, 4=GM
    CreatedAt   DATETIME     NOT NULL DEFAULT GETDATE(),
    Active      BIT          NOT NULL DEFAULT 1
);

CREATE UNIQUE INDEX IX_ItemSerial_Serial ON T_ItemSerial(Serial);

Cada vez que el servidor crea un ítem raro (drop de boss, craft, entrega de evento), reserva un serial nuevo en esa tabla. La clave primaria y el índice único garantizan que la base de datos rechaza la inserción de un serial repetido. Si, a causa de un bug de dupe, el servidor intenta persistir dos ítems con el mismo serial, el segundo INSERT falla y el error se convierte en alerta inmediata. Este es el pilar: transforma la unicidad en una restricción de la base de datos, no en una verificación opcional del código.

Cuando el ítem se destruye (fallo de refinamiento, venta a NPC, expiración), marca Active = 0 en lugar de borrar la fila — así preservas el rastro histórico para auditoría.

Capa 2: transacciones atómicas

Esta es la capa que ataca la causa raíz. Toda operación que mueve un ítem entre dos lugares (inventario ↔ warehouse, trade entre jugadores, drop en el suelo ↔ inventario) necesita ser atómica: o sucede por completo, o no sucede en absoluto. Nada de estados intermedios persistidos.

A nivel de base de datos, esto significa envolver la operación en una transacción con bloqueo adecuado:

BEGIN TRANSACTION;

-- Bloquea las filas involucradas para que nadie mas las toque
SELECT * FROM warehouse WITH (UPDLOCK, ROWLOCK)
WHERE AccountID = @acc;

-- Elimina del origen
UPDATE Inventory SET ItemSlot = NULL
WHERE CharID = @char AND Slot = @slotOrigem AND Serial = @serial;

-- Anade al destino
UPDATE warehouse SET Items = @novoBlob
WHERE AccountID = @acc;

-- Si cualquier paso falla, todo se deshace
COMMIT TRANSACTION;

El punto crucial es que el GameServer también coopere: no puede enviar la confirmación al cliente antes del COMMIT. El orden correcto es siempre: eliminar del origen, añadir al destino, confirmar en la base de datos y solo entonces avisar al cliente. Si la conexión se cae a mitad de camino, la transacción sufre rollback y el ítem vuelve a existir en un único lugar — el origen. No se crea ninguna copia. En emuladores open-source, busca en el código las funciones de MoveItem, WarehouseSave y TradeComplete y garantiza que sigan esa secuencia.

Capa 3: cooldowns y locks

Muchos dupes explotan la velocidad: el jugador ejecuta la misma acción decenas de veces por segundo, o combina dos acciones en el mismo instante, esperando pillar al servidor en un estado inconsistente. Los cooldowns y locks cierran esas ventanas.

Configura, en el GameServer:

1. Trade lock — mientras una ventana de intercambio está abierta y siendo confirmada, los ítems involucrados quedan bloqueados para cualquier otra operación. El jugador no puede, al mismo tiempo, poner el ítem en el intercambio y moverlo al baúl.
2. Warehouse lock — abrir el baúl bloquea los movimientos de inventario por una fracción de segundo hasta que termine la sincronización. Esto impide el clásico "abrir baúl y desconectar".
3. Cooldown de drop/pickup — un intervalo mínimo entre soltar y recoger el mismo ítem, para evitar el dupe de "tirar al suelo y desconectar".
4. Límite de operaciones por segundo — un techo de trades, movimientos de baúl o drops por ventana de tiempo. Un humano legítimo no hace 40 trades en un segundo; un script de dupe sí.

Ejemplo de configuración (nombres ilustrativos):

[AntiDupe]
TradeLockMs = 800
WarehouseSyncLockMs = 500
DropPickupCooldownMs = 1500
MaxTradesPerMinute = 20
MaxWarehouseOpsPerMinute = 60

Empieza con valores holgados para no castigar a jugadores legítimos y aprieta gradualmente observando los logs de rechazo. Cooldowns demasiado agresivos generan falso positivo y quejas; demasiado holgados dejan la ventana abierta. El punto de equilibrio varía por season y por perfil de servidor.

Capa 4: validación de origen

Todo ítem que aparece en la base de datos debería tener una procedencia explicable: cayó de un monstruo, fue crafteado, vino de un evento o lo dio un GM. Un ítem sin origen registrado es sospechoso por definición. Con la tabla T_ItemSerial de la Capa 1, puedes cruzar cada ítem activo con su origen y señalar los huérfanos.

La validación de origen también protege contra la inyección vía cliente modificado. Un cliente hackeado puede intentar mandar al servidor "yo tengo este ítem Excellent" que nunca existió. Si el GameServer valida que todo ítem recibido del cliente tiene serial conocido en la tabla de emisión, rechaza el ítem forjado. La regla es dura y simple: el servidor nunca confía en lo que el cliente dice tener — lo verifica contra su propia fuente de verdad.

Capa 5: detección y alerta

Ninguna prevención es perfecta. La última capa asume que algo pasó y busca activamente. Una query programada que corre cada hora puede cazar seriales duplicados:

-- Detecta items activos con serial repetido = dupe
SELECT Serial, COUNT(*) AS Copias
FROM T_ItemSerial
WHERE Active = 1
GROUP BY Serial
HAVING COUNT(*) > 1;

Si tu emulador no usa serial, la detección se vuelve estadística: volumen de un ítem raro por encima del total ya dropeado, el mismo ítem Excellent surgiendo en varias cuentas en el mismo intervalo, picos anómalos de Jewel en cuentas específicas. Configura un job (SQL Agent, cron o Task Scheduler) que corra esas queries y dispare una alerta — email, webhook de Discord — cuando cualquier indicador supere el umbral. Detectar en una hora, y no en una semana, es la diferencia entre eliminar tres ítems y tener que revertir la economía entera.

Paso a paso de implementación

1. Restaura una copia de seguridad en un entorno de prueba aislado. Nunca calibres en producción.
2. Mapea el esquema: descubre cómo tu emulador guarda los ítems y si hay serial nativo.
3. Crea la tabla de seriales (T_ItemSerial o equivalente) y el índice único.
4. Instrumenta la creación de ítems para emitir serial en todo drop raro, craft y evento.
5. Audita las funciones de movimiento en el GameServer y garantiza la atomicidad (eliminar → añadir → commit → avisar al cliente).
6. Configura cooldowns y locks con valores holgados en el [AntiDupe].
7. Activa la validación de origen rechazando ítems sin serial conocido.
8. Programa las queries de detección y conéctalas a un canal de alerta.
9. Prueba los escenarios de ataque: simula desconexión durante trade, spam de operaciones, inyección de ítem forjado.
10. Sube a producción con monitoreo reforzado en las primeras 48 horas.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Copia de seguridad restaurada en un entorno de prueba aislado
• Esquema de ítems del emulador mapeado (con o sin serial nativo)
• Tabla de seriales creada con índice único
• Emisión de serial activa en drop, craft y evento
• Funciones de movimiento auditadas y atómicas
• Cooldowns y locks configurados con valores holgados
• Validación de origen rechazando ítems sin serial
• Queries de detección programadas y conectadas a alerta
• Escenarios de ataque simulados y bloqueados
• Monitoreo reforzado en las primeras 48h en producción

El anti-dupe no es un producto que se instala, es una postura de arquitectura: toda operación con ítem se trata como potencialmente hostil hasta prueba de atomicidad y procedencia. Apila las cinco capas, calibra con paciencia y tu economía resistirá los ataques que derriban servidores mal preparados. </parameter>

Preguntas frecuentes