LOOT Cyclic Interaction Detected: Circular Dependency and Load Order Conflict Troubleshooting

The Anatomy of a Cyclic Interaction Failure

In Bethesda modding environments—across The Elder Scrolls and Fallout ecosystems managed via Mod Organizer 2, Vortex, or standalone toolchains—the Load Order Optimisation Tool (LOOT) serves as the primary utility for calculating clean plugin hierarchies. However, as mod lists expand into hundreds of active .esm, .esp, and .esl files, players frequently encounter a blocking error that halts sorting entirely:

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

When this occurs, LOOT aborts the sorting routine. The existing load order remains frozen in an undefined state, unable to accept newly added patches or satisfy essential overrides. If a player attempts to launch the game while sorting is in this blocked condition, missing master dependencies or inverted patch records almost inevitably cause a Crash to Desktop (CTD) on the main menu or severe runtime quest corruption.

Understanding why cyclic loops form and how LOOT builds its dependency graph allows modders to surgically decouple the conflict without wiping configurations or reinstalling extensive mod packages.

Graph Theory and Topological Sorting in LOOT

LOOT does not sort plugins based on arbitrary guesswork; it evaluates plugins through strict graph theory.

The sorting algorithm models your entire load order as a Directed Acyclic Graph (DAG):

• Vertices (Nodes): Every active plugin in your game's data directory represents a distinct vertex.
• Edges (Directed Arrows): A rule stating that "Plugin A must load before Plugin B" is represented as a directed edge pointing from vertex A to vertex B ($A \rightarrow B$).

To generate a valid 1-dimensional load order (a sequential list from index 00 to FE), LOOT must perform a topological sort on the graph. A topological sort computes a linear sequence of vertices such that for every directed edge $u \rightarrow v$, vertex $u$ comes before vertex $v$.

A fundamental mathematical theorem of graph theory dictates that a topological sort is possible if and only if the graph has no directed cycles.

If a set of rules dictates that Plugin A must load before Plugin B ($A \rightarrow B$), Plugin B must load before Plugin C ($B \rightarrow C$), and Plugin C must load before Plugin A ($C \rightarrow A$), a closed loop is formed. In this scenario, there is no mathematical solution where every condition can be satisfied simultaneously. LOOT detects this contradiction and halts with a "Cyclic interaction detected" error.

Hard Rules vs. Soft Rules in LOOT's Pipeline

To understand how cycles arise, it is essential to distinguish between the two tiers of rules LOOT processes when constructing the plugin graph:

1. Hard Rules (Inflexible Constraints)

Hard rules are absolute structural mandates that LOOT cannot ignore under any circumstances. If any combination of hard rules forms a cycle, sorting fails immediately. Hard rules include:

• Master Flags: Plugins with the .esm master flag set must load before standard non-master .esp plugins.
• Header Master Dependencies (Hard Masters): If Plugin B has Plugin A listed under the MAST (Master Files) field of its internal file header, Plugin A must physically load before Plugin B. If Plugin B loads earlier, the game engine will instantly crash on startup.
• Hardcoded Game Masters: Engine-mandated files (such as Skyrim.esm, Update.esm, Fallout4.esm) have hardcoded positions that must precede all third-party content.
• User "Load After" Rules: Custom rules manually specified by the user in the LOOT metadata editor or through mod manager metadata plugins are treated as hard rules.
• Requirement Metadata: Masterlist instructions declaring that a plugin requires another plugin.

2. Soft Rules (Flexible Constraints)

Soft rules guide optimal conflict resolution but can be dropped if they threaten graph integrity:

• Group Rules: LOOT organizes plugins into hierarchical groups (e.g., Core, Bug Fixes, UI, Late Loaders). When a group rule would induce a cycle with a hard master rule, LOOT automatically ignores the group edge to preserve sortability.
• Overlap Rules: Rules calculated by analyzing whether two plugins overwrite the same internal records or assets. Overlap rules are ignored whenever they conflict with hard rules.

Because LOOT's internal engine automatically discards conflicting soft rules, virtually every persistent cyclic interaction error is caused by conflicting hard rules—specifically, an irreconcilable contradiction between internal master headers and explicit "Load After" instructions.

The Three Root Causes of Cyclic Loops

When a cycle warning appears, it almost invariably traces back to one of three technical configurations:

Scenario A: Circular Master Dependencies in Mod Patches

This occurs when two separate community patches inadvertently list each other—or each other's downstream dependents—as masters.

• Mod A requires base master Parent X.
• Mod B requires base master Parent Y.
• Patch 1 was authored to bridge Mod A and Mod B, but the author created a reciprocal reference where Patch1.esp lists Patch2.esp as a master, while Patch2.esp lists Patch1.esp (or an intermediate plugin) as a master. Because neither plugin can physically load before the other, the engine's hard header requirements dead-end in a loop.

Scenario B: User Custom Metadata Contradicting Header Masters

Modders frequently attempt to manually fix mod load orders by setting custom "Load After" rules in LOOT's Plugin Editor or Vortex's rule graph. For example:

• A user sets a custom rule: ArmorMod_Patch.esp must load after WeatherOverhaul.esp.
• However, WeatherOverhaul.esp depends on a core framework plugin, which itself has ArmorMod_Patch.esp (or an interconnected utility) listed as an upstream master in its internal file header. The user's manual "Load After" rule forces an edge that directly opposes the internal master chain, producing a user-induced cycle.

Scenario C: ESM-Flagged Plugins with ESP Masters

Bethesda's engine strictly requires all ESM-flagged plugins to load above all non-ESM plugins. If a mod author flags a plugin as an ESM (via the header flag or .esl format) but inadvertently leaves a standard .esp listed as a required master in its header, an impossible situation is created:

1. The master rule demands: ESP must load before ESM.
2. The engine master-flag rule demands: ESM must load before ESP. LOOT detects this structural paradox as a cyclic conflict.

Step-by-Step Triage and Resolution

In 365Finds' assessment, the vast majority of cyclic interaction errors do not stem from faulty masterlist logic, but from compounding user-applied "Load After" rules or third-party compatibility patches that inadvertently declare mutual master headers; clearing custom metadata and verifying true record dependencies in xEdit resolves over 90% of sorting deadlocks without reinstalling mods.

To systematically identify and eliminate the cycle, follow this triage workflow:

Step 1: Trace the Exact Cycle in LOOT's Error Output

When LOOT throws the error, examine the diagnostic box or scroll down the main status card. The error provides the exact chain of plugins forming the closed loop. Example output: Back cycle: ModAlpha.esp, ModBeta.esp, PatchGamma.esp, ModAlpha.esp Write down or copy every plugin listed in this ring. The problem exists strictly among these named files.

Step 2: Audit and Purge Custom User Metadata

Before modifying any files, verify whether custom user rules are causing the collision:

1. In the LOOT interface, locate each plugin identified in the cycle list.
2. Click the three vertical dots icon (⋮) next to the plugin name and select Edit Metadata.
3. Inspect the Load After tab and the Group tab.
4. If you see custom user rules (indicated by user-edited icons or non-default values), delete the "Load After" entries by clicking the trash icon.
5. Click the checkmark icon to save metadata changes.
6. Click the sort icon (Sort Plugins) at the top of LOOT. If sorting completes cleanly, the cycle was caused by an erroneous manual rule.

Step 3: Inspect Physical Headers in xEdit

If clearing user metadata does not resolve the error, the cycle is embedded in the physical file headers of the plugins.

1. Launch xEdit (SSEEdit, FO4Edit, or FNVEdit) through your mod manager.
2. In the mod selection window, select only the plugins identified in the LOOT cycle trace, along with the base game ESMs. (Loading a minimal list accelerates loading and clarifies inspection).
3. Once background loading finishes, expand each plugin in the left-hand navigation pane and click on its top-level record: File Header.
4. In the right-hand panel, look at the Master Files (MAST) subrecord.
5. Cross-reference the masters of each plugin against the other files in the cycle:
   • Does ModAlpha.esp list PatchGamma.esp as a master?
   • Does PatchGamma.esp list ModBeta.esp as a master?
   • Does ModBeta.esp list ModAlpha.esp as a master?

Step 4: Sever the False Master Link (Clean Masters)

Often, a patch author loaded an extra mod into the Creation Kit while working, accidentally tagging it as a master even though the patch does not actually override any of that mod's records.

1. In xEdit, right-click on the patch plugin suspected of containing an unnecessary master.
2. Select Clean Masters from the context menu.
3. xEdit will scan the plugin's entire record tree. If the plugin does not actually reference any FormIDs belonging to the master file, xEdit will automatically remove the unused master from the MAST header.
4. Save the modified plugin (Ctrl + S) and close xEdit.

Step 5: Resolve True Mutual Dependencies

If "Clean Masters" does not remove the master because the patch genuinely overrides records from both files:

1. You have installed two patches that are mutually exclusive or incompatible variations of the same fix. Review the mod authors' documentation on Nexus Mods: you likely selected conflicting options in a FOMOD installer (e.g., installing both the "Standalone" and "Merged" compatibility patches).
2. Uninstall the redundant patch variant in your mod manager.
3. Relaunch LOOT and run the sorting procedure. LOOT will construct the graph without circular edges, execute the topological sort, and allow you to apply the calculated load order safely.

References

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