Error de interacción cíclica en LOOT: solución a dependencias circulares y conflictos en el orden de carga

La naturaleza del error de interacción cíclica

En el ecosistema de modificación de juegos basados en el motor de Bethesda —como las sagas The Elder Scrolls y Fallout, gestionadas a través de Mod Organizer 2, Vortex o herramientas independientes—, LOOT (Load Order Optimisation Tool) es la utilidad fundamental para calcular una jerarquía limpia de plugins. Sin embargo, a medida que las listas de mods crecen hasta albergar cientos de archivos .esm, .esp y .esl, los jugadores se topan con frecuencia con un error crítico que bloquea por completo la ordenación:

Cyclic interaction detected between plugins: "PluginA.esp" -> "PluginB.esp" -> "PluginC.esp" -> "PluginA.esp"

Cuando esto sucede, LOOT detiene de inmediato el proceso. El orden de carga existente queda congelado en un estado indefinido, impidiendo la integración de nuevos parches de compatibilidad y desajustando las prioridades de sobreescritura. Si un usuario inicia el juego en estas condiciones, la ausencia de archivos maestros o la inversión de dependencias provocará casi con certeza un cierre inesperado al escritorio (CTD) en el menú principal o una grave corrupción de scripts y misiones en partida.

Comprender la teoría de grafos subyacente y la forma en que LOOT evalúa las dependencias permite subsanar el conflicto de forma quirúrgica sin necesidad de borrar configuraciones ni reinstalar paquetes enteros de mods.

Teoría de grafos y ordenación topológica en LOOT

LOOT no calcula el orden de los plugins mediante estimaciones arbitrarias; aplica de manera rigurosa los principios de la teoría de grafos.

El motor de ordenación modela la lista completa de plugins como un Grafo Acíclico Dirigido (DAG, por sus siglas en inglés):

• Vértices (Nodos): Cada archivo de plugin activo en la carpeta Data del juego representa un nodo independiente en el grafo.
• Aristas dirigidas (Flechas): Una regla que estipula que «el Plugin A debe cargarse antes que el Plugin B» se representa como una arista dirigida que va desde el nodo A hacia el nodo B ($A \rightarrow B$).

Para transformar esta compleja red de relaciones cruzadas en una lista secuencial lineal (del índice 00 al FE), LOOT debe ejecutar una ordenación topológica (Topological Sort). Esta ordenación organiza los vértices de manera que, para cada arista dirigida $u \rightarrow v$, el vértice $u$ aparezca obligatoriamente antes que el vértice $v$ en la secuencia final.

Un teorema fundamental de la teoría de grafos establece que una ordenación topológica es posible si y solo si el grafo no contiene ciclos dirigidos (es decir, es un grafo acíclico).

Si en el conjunto de reglas se produce una contradicción del tipo «el Plugin A va antes que el B ($A \rightarrow B$)», «el Plugin B va antes que el C ($B \rightarrow C$)» y «el Plugin C va antes que el A ($C \rightarrow A$)», se genera un bucle cerrado. En este escenario, no existe matemáticamente ninguna secuencia lineal que pueda satisfacer todas las premisas a la vez. Al detectar este bucle imposible, LOOT emite el mensaje «Cyclic interaction detected» y aborta la tarea.

Jerarquía de reglas: reglas estrictas frente a reglas flexibles

Para localizar el origen del ciclo, es crucial entender las dos categorías de reglas que maneja LOOT durante la construcción del grafo:

1. Reglas estrictas (Hard Rules, restricciones infranqueables)

Son exigencias estructurales obligatorias que LOOT jamás puede ignorar. Si dos o más reglas estrictas forman un bucle, la ordenación falla de manera irreversible:

• Indicador maestro (Master Flag): Los plugins con el indicador .esm activado deben cargarse obligatoriamente antes que los plugins normales .esp.
• Dependencias maestras en la cabecera (Header Masters): Si el archivo Plugin B contiene al Plugin A en el campo MAST (Master Files) de su cabecera interna (File Header), el motor del juego exige físicamente que Plugin A se cargue antes. Si el orden se invierte, el juego se cierra al arrancar.
• Archivos oficiales codificados por el motor: Archivos base como Skyrim.esm, Update.esm o Fallout4.esm tienen posiciones inamovibles.
• Reglas personalizadas de «cargar después» (User "Load After"): Las instrucciones añadidas manualmente por el usuario en el editor de metadatos de LOOT tienen la consideración de reglas estrictas de máxima prioridad.
• Metadatos de requisitos: Indicaciones fijadas en la lista maestra oficial como dependencias ineludibles.

2. Reglas flexibles (Soft Rules, directrices prescindibles)

Son recomendaciones para optimizar la resolución de conflictos menores, pero pueden descartarse si amenazan la estabilidad del grafo:

• Reglas de grupos (Group Rules): LOOT clasifica los plugins en grupos ordenados (Core, Bug Fixes, UI, Late Loaders, etc.). Si una asignación de grupo genera un ciclo con una regla estricta, LOOT ignora automáticamente la regla de grupo para preservar la viabilidad del orden.
• Reglas de solapamiento (Overlap Rules): Calculadas al detectar que dos plugins modifican los mismos registros o empaquetan los mismos recursos. Si colisionan con reglas estrictas, se descartan de inmediato.

Dado que LOOT descarta automáticamente los ciclos generados por reglas flexibles, prácticamente todos los errores persistentes de interacción cíclica se originan por un choque entre reglas estrictas: una contradicción directa entre las cabeceras maestras de los plugins y las reglas manuales de usuario.

Los tres escenarios habituales que generan ciclos

En la práctica, casi todos los bucles de interacción cíclica se reducen a uno de los siguientes tres casos:

Escenario 1: Dependencias maestras cruzadas en parches de compatibilidad

Suele ocurrir al instalar varios parches creados por distintos autores para enlazar los mismos mods:

• El Mod A depende de una base X.
• El Mod B depende de una base Y.
• Un autor crea Patch1.esp para coordinar A y B, pero por descuido declara Patch2.esp como maestro; a su vez, Patch2.esp incluye a Patch1.esp (o a uno de sus intermediarios) en su lista de maestros. Ambos archivos exigen que el otro se cargue primero, creando un bloqueo irresoluble en las cabeceras físicas.

Escenario 2: Reglas de usuario que contradicen las cabeceras maestras

Ocurre cuando el usuario, siguiendo guías desactualizadas o por intuición, añade reglas manuales en el editor de LOOT:

• El usuario impone la regla: Armor_Patch.esp debe cargarse después de Weather_Mod.esp.
• Sin embargo, Weather_Mod.esp (o su framework base) incluye físicamente a Armor_Patch.esp en su lista interna de archivos maestros. La regla artificial del usuario entra en conflicto frontal con la estructura interna del archivo, forzando la creación de un ciclo.

Escenario 3: Plugins con flag ESM que dependen de un ESP convencional

El motor de Bethesda exige que todos los archivos con marca ESM precedan a los archivos ESP comunes. Si un creador de mods activa el flag ESM en su archivo pero deja como maestro requerido un plugin .esp convencional sin flag:

1. La regla de dependencia maestra exige: el ESP debe cargarse antes que el ESM.
2. La regla del motor exige: el ESM debe cargarse antes que el ESP. Ambas reglas estrictas colisionan y LOOT detecta un ciclo irresoluble.

Protocolo de resolución en cinco pasos

A juicio de 365Finds, la inmensa mayoría de los errores de interacción cíclica no se deben a fallos en la lista maestra oficial de LOOT, sino a la acumulación de reglas personalizadas de "cargar después" definidas por el usuario o a parches de compatibilidad que declaran accidentalmente dependencias maestras recíprocas; limpiar los metadatos personalizados y verificar las referencias reales en xEdit resuelve más del 90 % de los bloqueos sin necesidad de reinstalar los mods.

Siga este procedimiento sistemático para despejar el bucle:

Paso 1: Identificar el bucle exacto en el informe de LOOT

Cuando aparezca la advertencia en LOOT, copie la cadena de texto indicada en el cuadro de diagnóstico o en la tarjeta de estado superior. Ejemplo: Back cycle: ModAlpha.esp, ModBeta.esp, PatchGamma.esp, ModAlpha.esp Anote todos los plugins que forman este anillo cerrado. El problema radica exclusivamente en las relaciones entre estos archivos.

Paso 2: Revisar y restablecer los metadatos de usuario

Antes de editar archivos de juego, compruebe si una regla manual está provocando la colisión:

1. En la lista de plugins de LOOT, localice los archivos señalados en el ciclo.
2. Haga clic en el icono de los tres puntos verticales (⋮) situado junto al plugin y seleccione Editar metadatos (Edit Metadata).
3. Revise las pestañas Cargar después (Load After) y Grupo (Group).
4. Si encuentra reglas añadidas por el usuario, pulse en el icono de la papelera para eliminarlas.
5. Guarde los cambios pulsando en el icono de verificación.
6. Haga clic en el botón de ordenar de LOOT. Si la ordenación concluye sin errores, el conflicto se debía únicamente a una regla manual contradictoria.

Paso 3: Inspeccionar las cabeceras físicas en xEdit

Si el error persiste tras vaciar las reglas de usuario, la contradicción reside en las cabeceras de los archivos:

1. Abra xEdit (SSEEdit, FO4Edit, etc.) a través de su gestor de mods.
2. En la ventana de selección de plugins, haga clic derecho, elija «Select None» y marque únicamente los archivos implicados en el ciclo (junto con los ESM oficiales del juego base).
3. Una vez cargados, despliegue cada uno de los plugins en el panel izquierdo y seleccione el registro principal: File Header.
4. En el panel derecho, localice el subregistro Master Files (MAST).
5. Compare los maestros de cada archivo con el resto de miembros del ciclo: compruebe qué plugin está apuntando a cuál como dependencia previa.

Paso 4: Eliminar dependencias falsas con «Clean Masters»

A menudo, el creador de un parche cargó mods adicionales en el Creation Kit por error, quedando registrados como maestros aunque el parche no modifique ninguno de sus registros:

1. En xEdit, haga clic derecho sobre el parche sospechoso de contener dependencias innecesarias.
2. Seleccione la opción Clean Masters del menú contextual.
3. xEdit analizará todos los registros del archivo. Si detecta que no se utiliza ningún FormID del maestro en cuestión, eliminará la entrada sobrante del bloque MAST de forma segura.
4. Guarde las modificaciones con Ctrl + S y cierre xEdit.

Paso 5: Descartar variantes de parches incompatibles

Si la función «Clean Masters» no elimina la dependencia porque el parche realmente modifica registros de ambos mods:

1. Significa que ha instalado simultáneamente variantes de parches que son mutuamente excluyentes (por ejemplo, haber seleccionado a la vez el parche «Standalone» y el parche «Merged» en un instalador FOMOD).
2. Desactive o reinstale el mod correspondiente desde su gestor para conservar únicamente la variante adecuada.
3. Vuelva a ejecutar LOOT. El grafo se generará libre de ciclos, completará la ordenación topológica y le permitirá aplicar el orden de carga con total seguridad.

Referencias

• LOOT: The Load Order Optimisation Tool
• How LOOT Sorts Plugins — LOOT latest documentation
• Editing Plugin Metadata — LOOT latest documentation
• Tome of xEdit | xEdit Documentation