LOOT-Fehler „Cyclic Interaction Detected“: Behebung von zirkulären Abhängigkeiten und Ladereihenfolge-Konflikten

Das Wesen von Fehlern durch zirkuläre Interaktionen

Im Modding-Ökosystem von Spielen auf Basis der Bethesda-Engine – wie den Reihen The Elder Scrolls und Fallout, verwaltet über Mod Organizer 2, Vortex oder eigenständige Tools – ist LOOT (Load Order Optimisation Tool) das unverzichtbare Standardwerkzeug zur automatischen Berechnung einer sauberen Plugin-Hierarchie. Wächst eine Mod-Liste jedoch auf Hunderte aktiver .esm-, .esp- und .esl-Dateien an, stoßen Spieler nicht selten auf eine blockierende Fehlermeldung:

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

Sobald dieser Fehler auftritt, bricht LOOT den Sortiervorgang unverzüglich ab. Die bestehende Ladereihenfolge verharrt in einem undefinierten Zustand, neu hinzugefügte Patches können nicht eingeordnet werden und Vorrangregeln bleiben wirkungslos. Startet ein Spieler das Spiel in diesem blockierten Zustand, führen fehlende Master-Dateien oder invertierte Patch-Hierarchien fast unweigerlich zu einem sofortigen Absturz auf den Desktop (CTD) im Hauptmenü oder zu schweren Fehlern im Quest- und Skriptablauf.

Das Verständnis der graphentheoretischen Hintergründe und der Regelhierarchie von LOOT ermöglicht es, den Konfliktknoten gezielt aufzulösen, ohne Konfigurationen zurückzusetzen oder umfangreiche Mod-Pakete neu zu installieren.

Graphentheorie und topologische Sortierung in LOOT

LOOT ordnet Plugins nicht nach willkürlichen Heuristiken an, sondern wendet strikte Prinzipien der mathematischen Graphentheorie an.

Der Sortieralgorithmus modelliert die Gesamtheit der aktiven Plugins als gerichteten azyklischen Graphen (Directed Acyclic Graph, DAG):

• Knoten (Vertices): Jede im Data-Ordner aktivierte Plugin-Datei fungiert als eigenständiger Knoten im Graphen.
• Gerichtete Kanten (Pfeile): Eine Regel, die besagt, dass „Plugin A vor Plugin B geladen werden muss“, wird als gerichtete Kante von Knoten A zu Knoten B dargestellt ($A \rightarrow B$).

Um dieses komplexe Geflecht von Querbeziehungen in eine eindimensionale, lineare Abfolge (eine Ladereihenfolge von Index 00 bis FE) zu überführen, führt LOOT eine topologische Sortierung (Topological Sort) durch. Diese sortiert die Knoten so an, dass für jede gerichtete Kante $u \rightarrow v$ der Knoten $u$ in der finalen Liste ausnahmslos vor dem Knoten $v$ steht.

Ein fundamentaler Lehrsatz der Graphentheorie besagt, dass eine topologische Sortierung genau dann möglich ist, wenn der Graph frei von gerichteten Zyklen (geschlossenen Schleifen) ist.

Enthält das Regelsystem jedoch Widersprüche wie „A muss vor B laden ($A \rightarrow B$)“, „B muss vor C laden ($B \rightarrow C$)“ und „C muss vor A laden ($C \rightarrow A$)“, schließt sich eine endlose Schleife. In diesem Zustand existiert mathematisch keine lineare Reihenfolge, die alle Bedingungen gleichzeitig erfüllen könnte. LOOT erkennt diese logische Unmöglichkeit, gibt die Warnung „Cyclic interaction detected“ aus und bricht den Vorgang ab.

Regelhierarchie: Harte Regeln vs. weiche Regeln

Um die Ursache des Zirkelschlusses zu lokalisieren, muss man zwischen den zwei Regelschichten unterscheiden, die LOOT beim Aufbau des Graphen anwendet:

1. Harte Regeln (Hard Rules, unverletzliche Bedingungen)

Harte Regeln sind zwingende Vorgaben der Engine und Dateistruktur, die LOOT unter keinen Umständen übergehen kann. Schließen sich harte Regeln zu einem Zyklus zusammen, schlägt die Sortierung unweigerlich fehl:

• Master-Flags: Plugins mit gesetztem .esm-Flag müssen zwingend vor regulären .esp-Dateien ohne dieses Flag geladen werden.
• Header-Master-Abhängigkeiten (Header Masters): Ist Plugin A im Datei-Header (File Header) von Plugin B unter MAST (Master Files) eingetragen, verlangt die Engine zwingend, dass Plugin A zuerst geladen wird. Bei Umkehrung stürzt das Spiel beim Booten ab.
• Fest hinterlegte Engine-Reihenfolgen: Offizielle Basisdateien wie Skyrim.esm oder Fallout4.esm haben fest verankerte Prioritäten.
• Benutzerdefinierte „Nach ... laden“-Regeln (User "Load After"): Manuell vom Spieler im LOOT-Metadaten-Editor hinterlegte Regeln gelten als harte Regeln höchster Priorität.
• Anforderungs-Metadaten: In der offiziellen Masterliste festgehaltene Pflicht-Abhängigkeiten.

2. Weiche Regeln (Soft Rules, flexible Richtlinien)

Weiche Regeln steuern die Feinabstimmung bei Überschreibungen, können jedoch verworfen werden, falls sie die Sortierbarkeit des Graphen gefährden:

• Gruppenregeln (Group Rules): LOOT unterteilt Plugins in hierarchische Gruppen (Core, Bug Fixes, UI, Late Loaders usw.). Droht eine Gruppenregel einen Zyklus mit einer harten Regel zu bilden, ignoriert LOOT die Gruppenregel automatisch.
• Überlappungsregeln (Overlap Rules): Regeln, die greifen, wenn zwei Plugins dieselben Datensätze oder Archive modifizieren. Sie werden bei Konflikten mit harten Regeln sofort fallen gelassen.

Da LOOT zirkuläre weiche Regeln automatisch herausfiltert, gehen praktisch alle ungelösten Fehlermeldungen auf einen Konflikt zwischen harten Regeln zurück – insbesondere auf Widersprüche zwischen Header-Mastern und benutzerdefinierten manuellen Regeln.

Die drei Hauptursachen für zirkuläre Schleifen

In der Praxis lassen sich fast alle gemeldeten Zyklen auf eines der folgenden drei Szenarien zurückführen:

Szenario 1: Überkreuzte Master-Abhängigkeiten in Patches

Tritt häufig auf, wenn mehrere von unterschiedlichen Autoren stammende Kompatibilitätspatches kombiniert werden:

• Mod A benötigt Basis X.
• Mod B benötigt Basis Y.
• Ein Autor erstellt Patch1.esp für A und B, trägt dabei aber versehentlich Patch2.esp als Master ein; Patch2.esp wiederum führt Patch1.esp (oder eine Zwischenabhängigkeit) in seinem eigenen Header. Beide Dateien verlangen physikalisch den Vorrang der jeweils anderen, wodurch eine unauflösbare Blockade im Datei-Header entsteht.

Szenario 2: Benutzerregeln im Widerspruch zu Header-Mastern

Entsteht, wenn der Spieler nach veralteten Forenanleitungen manuell Regeln in LOOT einträgt:

• Der Spieler verfügt: Armor_Patch.esp muss nach Weather_Mod.esp laden.
• Weather_Mod.esp (oder dessen Kern-Framework) führt im Datei-Header jedoch Armor_Patch.esp als zwingenden Master. Die manuelle Vorgabe läuft der festen Dateistruktur direkt entgegen und erzwingt einen Kreisbezug.

Szenario 3: ESM-geflaggte Plugins mit regulären ESP-Mastern

Die Bethesda-Engine schreibt vor, dass alle ESM-geflaggten Plugins vor gewöhnlichen ESPs stehen müssen. Versieht ein Mod-Autor ein Plugin mit einem ESM-Flag, lässt im Header aber eine reguläre .esp als Master eingetragen:

1. Master-Regel fordert: ESP muss vor ESM laden.
2. Flag-Regel der Engine fordert: ESM muss vor ESP laden. Dieser fundamentale Widerspruch wird von LOOT als Zirkelschluss gemeldet.

Fünfstufiger Leitfaden zur Fehlerbehebung

Nach Einschätzung von 365Finds resultieren die allermeisten Fehler bezüglich zirkulärer Interaktionen nicht aus logischen Schwächen der offiziellen LOOT-Masterliste, sondern aus sich widersprechenden manuellen 'Nach ... laden'-Regeln des Nutzers oder aus Drittanbieter-Kompatibilitätspatches, die sich versehentlich gegenseitig als Master deklarieren; das Bereinigen benutzerdefinierter Metadaten und die Prüfung realer Datensatzverknüpfungen in xEdit lösen über 90 % aller Sortierblockaden, ohne dass Mod-Pakete neu installiert werden müssen.

Gehen Sie nach folgendem strukturierten Schema vor, um den Konflikt aufzulösen:

Schritt 1: Den Zyklus im LOOT-Protokoll isolieren

Kopieren Sie bei Auftreten des Fehlers den genauen Pfad aus dem Diagnosefenster oder der oberen Statuskarte in LOOT. Beispiel: Back cycle: ModAlpha.esp, ModBeta.esp, PatchGamma.esp, ModAlpha.esp Notieren Sie alle in dieser Kette genannten Dateien. Der logische Widerspruch existiert ausnahmslos nur zwischen diesen namentlich genannten Plugins.

Schritt 2: Benutzerdefinierte Metadaten prüfen und zurücksetzen

Vor Eingriffen in Spieldateien sollte geprüft werden, ob manuelle Regeln den Konflikt verursachen:

1. Suchen Sie in der LOOT-Plugin-Liste die am Zyklus beteiligten Dateien.
2. Klicken Sie auf das Drei-Punkte-Menü (⋮) neben dem Plugin und wählen Sie Metadaten bearbeiten (Edit Metadata).
3. Prüfen Sie die Reiter Nach ... laden (Load After) und Gruppe (Group).
4. Sind manuelle Einträge vorhanden, löschen Sie diese über das Papierkorb-Symbol.
5. Speichern Sie die Änderungen über das Häkchen-Symbol.
6. Starten Sie die Sortierung in LOOT erneut. Verschwindet der Fehler, lag die Ursache rein in einer manuellen Fehlkonfiguration.

Schritt 3: Datei-Header in xEdit analysieren

Bleibt der Fehler ohne manuelle Metadaten bestehen, sitzt die Schleife direkt in den Headern der Dateien:

1. Starten Sie xEdit (SSEEdit, FO4Edit etc.) über Ihren Mod-Manager.
2. Wählen Sie im Startfenster per Rechtsklick „Select None“ und aktivieren Sie ausschließlich die im Zyklus genannten Plugins (sowie die offiziellen Basis-ESMs).
3. Öffnen Sie nach dem Ladevorgang im linken Fenster die betroffenen Plugins und klicken Sie auf den ersten Haupteintrag: File Header.
4. Prüfen Sie im rechten Fenster den Unterabschnitt Master Files (MAST).
5. Vergleichen Sie die Master-Listen der beteiligten Dateien: Welche Datei deklariert welche andere Datei als Voraussetzung?

Schritt 4: Überflüssige Master mit „Clean Masters“ entfernen

Häufig hat ein Modder beim Erstellen eines Patches versehentlich unbeteiligte Mods im Creation Kit mitgeladen, wodurch diese als Master eingetragen wurden, ohne dass der Patch tatsächlich Daten von ihnen überschreibt:

1. Klicken Sie in xEdit mit der rechten Maustaste auf den verdächtigen Patch.
2. Wählen Sie Clean Masters aus dem Kontextmenü.
3. xEdit scannt alle Datensätze des Plugins. Verwendet der Patch keine FormIDs des betreffenden Masters, wird dieser sicher aus dem MAST-Header entfernt.
4. Speichern Sie die Änderungen mit Ctrl + S und schließen Sie xEdit.

Schritt 5: Inkompatible Patch-Varianten bereinigen

Löscht „Clean Masters“ die Verknüpfung nicht, überschreibt der Patch tatsächlich Datensätze beider Seiten:

1. In diesem Fall wurden zueinander inkompatible Varianten desselben Patches installiert (z. B. versehentliche gleichzeitige Auswahl von „Standalone“ und „Merged“ in einem FOMOD-Installer).
2. Deaktivieren oder installieren Sie die betreffende Mod im Mod-Manager neu, sodass nur die für Ihr Setup passende Patch-Datei verbleibt.
3. Führen Sie die Sortierung in LOOT erneut aus. Der Graph schließt sich nun zyklenfrei und die berechnete Ladereihenfolge kann fehlerfrei angewendet werden.

Referenzen

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