Erreur d'interaction cyclique dans LOOT : résolution des dépendances circulaires et conflits d'ordre de chargement

La nature de l'erreur d'interaction cyclique

Dans l'écosystème de modification des jeux exploitant le moteur de Bethesda — à l'instar des franchises The Elder Scrolls et Fallout, gérées via Mod Organizer 2, Vortex ou des suites d'outils dédiées —, LOOT (Load Order Optimisation Tool) constitue l'utilitaire de référence pour organiser rationnellement la hiérarchie des plugins. Néanmoins, à mesure que la liste de mods s'étoffe pour atteindre plusieurs centaines de fichiers .esm, .esp et .esl, les joueurs se heurtent fréquemment à un message d'alerte critique bloquant toute réorganisation :

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

Face à cette situation, LOOT interrompt net la procédure de tri. L'ordre de chargement en vigueur demeure figé dans un état indéfini, empêchant le bon positionnement des nouveaux patchs de compatibilité et rompant les priorités d'écrasement indispensables. Si le joueur lance son jeu dans ces conditions, l'absence de fichiers maîtres ou l'inversion de dépendances fondamentales provoquera presque inévitablement un plantage avec retour au bureau (CTD) dès le menu principal ou de graves altérations dans l'exécution des quêtes et des scripts.

Comprendre la théorie des graphes sous-jacente et le modèle décisionnel de LOOT permet de dénouer chirurgicalement ce blocage sans devoir réinitialiser son installation ni reconfigurer l'ensemble de ses mods.

Théorie des graphes et tri topologique dans LOOT

LOOT ne détermine pas l'agencement des plugins au hasard ou selon des intuitions empiriques ; il applique rigoureusement les principes de la théorie des graphes.

L'algorithme de LOOT modélise l'ensemble des plugins actifs sous la forme d'un graphe orienté acyclique (DAG, pour Directed Acyclic Graph) :

• Sommets (Noeuds) : Chaque fichier de plugin activé dans le répertoire Data du jeu correspond à un nœud unique du graphe.
• Arêtes orientées (Flèches) : Une règle stipulant que « le Plugin A doit se charger avant le Plugin B » est formalisée par une arête orientée reliant le nœud A au nœud B ($A \rightarrow B$).

Pour convertir cet enchevêtrement complexe de relations en une séquence linéaire ordonnée (une numérotation continue s'étendant de l'index 00 à FE), LOOT doit exécuter un tri topologique (Topological Sort). Ce tri ordonne les sommets de telle sorte que pour chaque arête orientée $u \rightarrow v$, le sommet $u$ figure systématiquement avant le sommet $v$ dans la séquence finale.

Un théorème fondamental de la théorie des graphes énonce qu'un tri topologique n'est réalisable que si et seulement si le graphe est totalement dépourvu de cycles orientés (circuits fermés).

Si le jeu de règles contient des injonctions contradictoires telles que « A doit précéder B ($A \rightarrow B$) », « B doit précéder C ($B \rightarrow C$) » et « C doit précéder A ($C \rightarrow A$) », une boucle fermée se forme. Dans cette configuration, aucune solution mathématique ne permet de satisfaire simultanément l'ensemble des contraintes. LOOT identifie cette impossibilité logique, émet l'erreur « Cyclic interaction detected » et interrompt l'opération.

Hiérarchie des règles : règles strictes vs règles souples

Pour diagnostiquer l'origine de la boucle, il est indispensable de dissocier les deux niveaux de contraintes pris en charge par LOOT lors de la génération du graphe :

1. Les règles strictes (Hard Rules, contraintes absolues)

Les règles strictes représentent des impératifs structurels inviolables dictés par le moteur du jeu. Si plusieurs règles strictes forment une boucle entre elles, le tri échoue obligatoirement :

• Indicateur maître (Master Flag) : Les plugins dotés de l'indicateur .esm doivent impérativement être chargés avant les plugins standards .esp.
• Dépendances maîtresses dans l'en-tête (Header Masters) : Si le Plugin B déclare le Plugin A dans le champ MAST (Master Files) de son en-tête interne (File Header), le moteur exige physiquement que le Plugin A soit chargé en amont. Toute inversion provoque un plantage au démarrage.
• Ordre codé en dur par le jeu : Les fichiers officiels incontournables (Skyrim.esm, Fallout4.esm, etc.) bénéficient de positions fixes prioritaires.
• Règles personnalisées « charger après » (User "Load After") : Les directives saisies manuellement par l'utilisateur dans l'éditeur de métadonnées de LOOT ont le statut de règles strictes de premier rang.
• Métadonnées de prérequis : Relations de dépendance indispensables spécifiées dans la liste maîtresse officielle.

2. Les règles souples (Soft Rules, recommandations flexibles)

Les règles souples servent à harmoniser la résolution des conflits mineurs, mais peuvent être abandonnées si elles mettent en péril la faisabilité du tri :

• Règles de groupes (Group Rules) : LOOT classe les plugins par strates logiques (Core, Bug Fixes, UI, Late Loaders, etc.). Lorsqu'une règle de groupe menace de créer un cycle avec une règle stricte, LOOT ignore automatiquement cette règle de groupe.
• Règles de chevauchement (Overlap Rules) : Calculées lorsque deux plugins modifient les mêmes entrées ou partagent des ressources identiques. Elles sont immédiatement écartées en cas de conflit avec une règle stricte.

Puisque LOOT élimine de lui-même les cycles induits par les règles souples, la quasi-totalité des erreurs persistantes d'interaction cyclique découle d'un antagonisme entre règles strictes : une opposition frontale entre les en-têtes maîtres physiques des fichiers et les règles manuelles créées par l'utilisateur.

Les trois causes majeures de boucles circulaires

Dans la pratique, ces blocages s'expliquent presque toujours par l'une des trois configurations suivantes :

Cas 1 : Dépendances maîtresses croisées entre patchs de compatibilité

Situation courante lors de l'installation de multiples patchs communautaires conçus pour harmoniser les mêmes mods fondamentaux :

• Le Mod A requiert la base X.
• Le Mod B requiert la base Y.
• Un auteur conçoit Patch1.esp pour ajuster A et B, mais inscrit par mégarde Patch2.esp comme maître ; en parallèle, Patch2.esp déclare Patch1.esp (ou un intermédiaire direct) dans son propre en-tête. Chaque fichier réclamant la préséance de l'autre, les en-têtes se verrouillent mutuellement dans une impasse.

Cas 2 : Règles manuelles contraires aux en-têtes physiques

Survient lorsque l'utilisateur, guidé par un tutoriel obsolète ou une mauvaise manipulation, ajoute des règles personnalisées dans LOOT :

• L'utilisateur impose la règle : Armor_Patch.esp doit se charger après Weather_Mod.esp.
• Or, Weather_Mod.esp (ou l'infrastructure dont il dépend) intègre directement Armor_Patch.esp dans sa liste interne de maîtres obligatoires. La consigne manuelle de l'utilisateur s'oppose frontalement à la structure interne du fichier, provoquant l'apparition d'un cycle.

Cas 3 : Fichiers avec flag ESM dépendant d'un ESP standard

Le moteur de Bethesda exige que tout fichier portant l'indicateur ESM précède les fichiers ESP classiques. Si un moddeur applique le flag ESM à son plugin tout en conservant comme maître requis un fichier .esp ordinaire :

1. La règle de dépendance maîtresse exige : l'ESP ordinaire doit se charger avant l'ESM.
2. La règle du moteur exige : l'ESM doit se charger avant l'ESP ordinaire. Cette contradiction directe entre deux règles strictes est sanctionnée par LOOT sous forme d'interaction cyclique.

Protocole de dépannage méthodique en cinq étapes

Selon l'analyse de 365Finds, la grande majorité des erreurs d'interaction cyclique ne provient pas d'anomalies dans la liste maîtresse officielle de LOOT, mais de l'accumulation de règles manuelles 'charger après' définies par l'utilisateur ou de patchs de compatibilité tiers déclarant par mégarde des dépendances maîtresses réciproques ; purger les métadonnées personnalisées et contrôler les liaisons réelles dans xEdit résout plus de 90 % des blocages de tri sans nécessiter la réinstallation des mods.

Appliquez cette démarche pas à pas pour neutraliser l'anomalie :

Étape 1 : Relever la chaîne cyclique dans le rapport de LOOT

Lorsque le message d'erreur surgit, copiez l'itinéraire textuel affiché dans la fenêtre de diagnostic ou sur le bandeau d'état de LOOT. Exemple : Back cycle: ModAlpha.esp, ModBeta.esp, PatchGamma.esp, ModAlpha.esp Notez l'ensemble des plugins qui composent cette boucle fermée. Le conflit se situe exclusivement dans les interactions unissant ces fichiers ciblés.

Étape 2 : Auditer et purger les métadonnées utilisateur

Avant de modifier les fichiers du jeu, assurez-vous qu'une consigne manuelle n'est pas à l'origine du blocage :

1. Dans l'interface principale de LOOT, repérez les plugins mentionnés dans le cycle.
2. Cliquez sur l'icône des trois points verticaux (⋮) située à côté du fichier et sélectionnez Éditer les métadonnées (Edit Metadata).
3. Consultez les onglets Charger après (Load After) et Groupe (Group).
4. Si vous identifiez des règles manuelles personnalisées, supprimez-les en cliquant sur l'icône de corbeille.
5. Validez vos modifications en cliquant sur la coche de confirmation.
6. Relancez le tri dans LOOT. Si la réorganisation réussit sans erreur, le problème provenait uniquement d'une règle manuelle contradictoire.

Étape 3 : Examiner les en-têtes physiques dans xEdit

Si l'erreur subsiste en l'absence de règles personnalisées, la boucle est gravée dans les en-têtes des fichiers :

1. Lancez xEdit (SSEEdit, FO4Edit, etc.) depuis votre gestionnaire de mods.
2. Dans la boîte de dialogue de sélection des plugins, effectuez un clic droit, choisissez « Select None » et cochez uniquement les fichiers impliqués dans la boucle (ainsi que les ESM officiels du jeu de base).
3. Une fois le chargement terminé, déployez chaque plugin dans l'arborescence de gauche et cliquez sur son entrée racine : File Header.
4. Dans le volet de droite, examinez attentivement la section Master Files (MAST).
5. Comparez les dépendances déclarées par chaque fichier : identifiez quel plugin réclame quel autre plugin comme prérequis direct.

Étape 4 : Éliminer les dépendances superflues via « Clean Masters »

Il arrive fréquemment qu'un créateur de patch ait chargé des mods tiers par accident dans le Creation Kit, les intégrant comme maîtres alors que le patch ne modifie aucun de leurs enregistrements :

1. Dans xEdit, faites un clic droit sur le patch suspecté de contenir des dépendances parasites.
2. Choisissez l'option Clean Masters dans le menu contextuel.
3. xEdit examine l'ensemble des données du plugin. S'il constate qu'aucun FormID appartenant au maître en question n'est exploité, il purge proprement l'entrée du bloc MAST.
4. Enregistrez les modifications avec Ctrl + S et quittez xEdit.

Étape 5 : Résoudre les incompatibilités entre variantes de patchs

Si l'exécution de « Clean Masters » ne supprime pas la dépendance, cela prouve que le fichier altère bel et bien les données des deux côtés :

1. Cette situation signale l'installation conjointe de variantes mutuellement exclusives d'un même correctif (par exemple, avoir sélectionné par mégarde à la fois la version « Standalone » et la version « Merged » dans un installeur FOMOD).
2. Désactivez ou réinstallez le mod concerné dans votre gestionnaire de façon à ne conserver que la variante adaptée à votre profil.
3. Rouvrez LOOT et relancez le tri. Le graphe acyclique sera reconstitué sans boucle, permettant d'exécuter le tri topologique et d'appliquer le nouvel ordre de chargement en toute sécurité.

Références

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