El Capítulo I, «Out of the Breach», llegó el 12 de octubre de 2026 con la Update 7, y muchos administradores se encontraron con lo mismo al reiniciar: un servidor que no arranca o mods que ya no se cargan. Esta guía no repite cómo instalar mods: te da un método de diagnóstico completo, desde el primer mensaje de error hasta la reparación, protegiendo tu mundo en cada paso.

Por qué el Capítulo I rompe algunos mods

La Update 7 no es una simple actualización de contenido. Afecta a tres capas de las que dependen los mods:

• El protocolo de red ha cambiado de versión. Cliente y servidor tienen que estar en la misma: un servidor que se quedó en la Update 6 rechaza a los jugadores actualizados, y al revés. Ningún mod se salta esta regla.
• La API del servidor se ha reorganizado a fondo. Las notas para desarrolladores citan, por ejemplo, TickProcedure.onTick, cuya firma ha cambiado, WorldChunk, que ya no contiene un World, o DurabilityOperator, que pasa a llamarse ComparisonOperator. Un mod Java (archivo .jar) compilado para la Update 6 que use estos elementos puede negarse a cargar o fallar en plena partida.
• Los assets del juego también han cambiado. Las notas de la pre-release de la Update 7 mencionan claves renombradas (ChargeAcceleration pasa a ser ChargeAccelerationDistance), campos del planeador trasladados a Template_Glider, identificadores que ya no se resuelven (Spectre_Void) e incluso archivos PNG renombrados, como Spiwer_Web_Full.png, ahora Spider_Web_Full.png. Un pack que apunta a un elemento desaparecido puede fallar en la validación.

Otro detalle clave: el formato de guardado ha cambiado. Un mundo se convierte automáticamente la primera vez que lo carga un servidor con el Capítulo I, y un mundo convertido ya no se puede abrir con una versión anterior. La conversión es de ida, sin vuelta.

Antes de tocar nada: haz una copia de seguridad

Detén el servidor y copia como mínimo:

• la carpeta universe/ (tus mundos);
• la carpeta mods/ completa, con las carpetas de configuración de los mods;
• los archivos config.json, permissions.json, whitelist.json y bans.json.

Apunta también la lista exacta de tus mods con su versión: te servirá para compararla con las páginas de los autores. Si ya arrancaste con el Capítulo I, guarda igualmente una copia del estado actual antes de cambiar nada, y no reinicies el servidor una y otra vez esperando que el error desaparezca solo.

Paso 1: leer los logs en el sitio correcto

La consola y los logs casi siempre dicen qué mod está fallando. Eso sí, hay que mirar donde toca:

Situación	Dónde mirar
Servidor dedicado o alojado	La consola del panel y después la carpeta logs/ del servidor (un archivo por arranque, con fecha y hora en el nombre)
Mundo en solitario o compartido desde el juego	UserData/Saves/<mundo>/logs
Problema en el cliente (el juego)	UserData/logs

Abre el log del último arranque y sube hasta el primer error: los siguientes suelen ser solo consecuencias. Busca las palabras Error, Exception y Failed, además del nombre de cada uno de tus mods. En Linux basta con un comando para filtrar:

grep -inE "error|exception|failed" logs/*.log | head -n 40

En Windows, PowerShell hace lo mismo:

Select-String -Path .\logs\*.log -Pattern "error","exception","failed" | Select-Object -First 40

Un mensaje como Failed to load manifest file! señala un mod cuyo manifest.json falta, está mal colocado o no se puede leer. Una traza de Java que menciona una clase o un método que no se encuentra (por ejemplo, NoSuchMethodError) indica casi siempre un mod Java compilado para la API antigua.

Paso 2: clasificar el tipo de error

Cuando tengas la línea culpable, clasifícala. La solución depende de la categoría.

Síntoma	Causa probable	Qué hacer
El servidor se detiene al arrancar y nombra un mod	Mod Java incompatible con la nueva API	Instalar la versión del mod para el Capítulo I o retirarlo temporalmente
Error de validación de un asset (clave desconocida, identificador no encontrado)	Pack que hace referencia a un elemento renombrado o eliminado	Esperar o instalar la actualización del pack
El mod carga, pero algún efecto ya no funciona	Clave renombrada que solo genera un aviso	Avisar al autor y revisar las advertencias del log
Mod ignorado por una dependencia	Dependencia ausente o en una versión demasiado antigua	Instalar o actualizar la dependencia
Comportamientos raros, objetos duplicados	Dos versiones del mismo mod en mods/	Dejar un solo archivo
Los jugadores no pueden conectarse	Versiones distintas de cliente y servidor	Igualar la versión y el canal de actualización (patchline)

Paso 3: eliminar los duplicados

Es la causa más tonta y la que más se pasa por alto. Al actualizar un mod, se sube el archivo nuevo sin borrar el antiguo y la carpeta mods/ acaba con dos versiones del mismo mod. Lista la carpeta y busca nombres parecidos:

ls -1 mods/ | sort

Si ves, por ejemplo, MiMod-1.4.2.jar y MiMod-1.5.0.jar, deja solo la versión preparada para el Capítulo I. Ojo también con los mods que tienes a la vez como pack .zip y como carpeta descomprimida: solo debe quedar uno de los dos.

Paso 4: revisar las dependencias

Cada mod declara lo que necesita en su manifest.json, en la raíz del .jar, del .zip o de la carpeta del pack. Hay dos campos que nos interesan:

• Dependencies: los mods obligatorios, en formato Grupo:Nombre con un rango de versiones. Si falta alguno o no cumple el rango, el mod no se carga.
• OptionalDependencies: los mods opcionales. Si faltan, el mod se carga igualmente.

{
  "Group": "Ejemplo",
  "Name": "MiMod",
  "Version": "1.5.0",
  "ServerVersion": "...",
  "Dependencies": {
    "Ejemplo:LibComun": ">=2.0.0"
  },
  "OptionalDependencies": {}
}

La trampa típica tras una gran actualización: el mod principal ya tiene su versión para el Capítulo I, pero su librería todavía no. En ese caso, el mod principal no te sirve de nada hasta que la dependencia se actualice. En las páginas de descarga, la pestaña de relaciones indica qué dependencias son obligatorias. El campo ServerVersion, cuando está relleno, también indica para qué versión del servidor se publicó el mod: compáralo con lo que devuelve el comando /version.

Paso 5: retirar temporalmente el mod culpable

Si no existe ninguna versión compatible, toca decidir. Hay dos casos muy distintos:

El mod no añade bloques ni objetos

Interfaz, minimapa, comandos de administración, herramientas de gestión: puedes retirarlo sin riesgo. Detén el servidor, mueve el archivo a una carpeta aparte (por ejemplo mods-desactivados/) en lugar de borrarlo y vuelve a arrancar. También puedes desactivarlo en la sección Mods del config.json del servidor, siempre con el servidor parado: el servidor reescribe sus archivos de configuración mientras funciona y un cambio hecho en caliente puede perderse.

El mod añade bloques, objetos o criaturas

Aquí, con cuidado. Si lo quitas, los bloques que colocó pueden aparecer como desconocidos o desaparecer, y los objetos afectados pueden perderse de los inventarios. Además, cada mundo guarda en su propia configuración la lista de mods que necesita: si falta uno, el mundo puede negarse a cargar. Prueba siempre la retirada en una copia del mundo antes de tocar el principal. Muchas veces, lo más sensato es dejar el servidor parado, o abrir un mundo provisional, mientras esperas la actualización del mod.

Para dar rápido con el mod culpable en una lista larga, el método de las mitades es el más eficaz: retira la mitad de los mods, arranca y repite con la mitad que contiene el error. Con 30 mods, cinco arranques bastan para aislarlo. La documentación de la comunidad menciona también una opción de arranque, --ignore-broken-mods, que deja arrancar el servidor pese a un mod con errores para poder identificarlo; comprueba que existe en tu versión con --help antes de fiarte de ella, y no la uses nunca en tu mundo principal sin copia de seguridad.

Paso 6: esperar (y seguir) la actualización del mod

En los mods Java, el arreglo casi siempre depende del autor, que tiene que recompilar su mod para la nueva API. Algunos consejos:

• revisa la página de cada mod y busca expresamente «Chapter 1» o «Update 7» en el registro de cambios;
• el navegador de mods integrado en el juego te permite ver de un vistazo qué mods de tu biblioteca han recibido actualización;
• no descargues una «versión arreglada» publicada por un desconocido: un archivo .jar ejecuta código en tu servidor;
• si un mod está abandonado, busca una alternativa mantenida en lugar de quedarte con una versión rota.

Tabla de compatibilidad por tipo de mod

No todos los mods corren el mismo riesgo tras el Capítulo I. Esta tabla te ayuda a decidir por dónde empezar a revisar:

Tipo de mod	Riesgo tras la Update 7	Qué comprobar
Pack solo visual (texturas, sonidos)	Bajo	Archivos renombrados en el juego base
Pack de contenido (bloques, objetos, PNJ, planeadores)	Medio	Claves e identificadores renombrados o eliminados
Mod Java de servidor (.jar)	Alto	Versión compilada para el Capítulo I
Librería compartida por otros mods	Alto	Versión actualizada antes que los mods que dependen de ella
Mod que genera estructuras o mundos	Medio a alto	Prueba en una copia del mundo y compatibilidad con el nuevo formato de guardado

Y una buena noticia de paso: con la Update 7, un mod ya puede incluir mundos enteros, y un mundo creado a partir de un mod sobrevive aunque retires ese mod.

Errores que no vienen de los mods

Antes de culpar a tus mods, descarta estas causas, también relacionadas con el Capítulo I:

• Código de salida 11 en un servidor instalado por tu cuenta: los datos del servidor están dentro de la carpeta de instalación del launcher. Mueve el servidor a su propia carpeta.
• Aviso sobre MaxViewRadius: la distancia de visión tiene ahora un tope de 32 chunks. El servidor arranca igualmente, pero corrige el valor en config.json.
• Jugadores rechazados: cliente y servidor no están en la misma versión o en el mismo canal de actualización.

Lista de comprobación rápida

1. Detener el servidor y copiar universe/, mods/ y los archivos de configuración.
2. Leer el primer error del último log.
3. Eliminar los duplicados de mods/.
4. Actualizar las dependencias antes que los mods que las usan.
5. Retirar temporalmente los mods sin versión para el Capítulo I, probando antes en una copia los que añaden bloques.
6. Reiniciar, comprobar que el servidor llega al estado «en línea» y probar con un solo jugador antes de abrirlo a todos.

Preguntas frecuentes

¿Puedo volver a la Update 6 si mis mods dejan de funcionar?

Solo con una copia de seguridad hecha antes de actualizar. Un mundo abierto por un servidor con el Capítulo I queda convertido y una versión anterior ya no puede leerlo.

Mi mod está actualizado, pero el servidor sigue sin arrancar. ¿Por qué?

Revisa sus dependencias y comprueba que no quede una copia antigua del mismo mod en mods/. Basta con una librería que siga en la versión de la Update 6 para bloquear la carga.

¿Afecta a los packs de texturas?

Rara vez, pero algunos archivos del juego base han cambiado de nombre. Si un pack visual sustituye un archivo que se ha renombrado, esa sustitución dejará de aplicarse.

¿Cuánto hay que esperar a que se actualice un mod?

Depende por completo de su autor y no hay un plazo fijo. Sigue su página o su registro de cambios y, si el mod no muestra actividad, ve buscando una alternativa.