L'art multi-séculaire de rechercher les conflits
«tu as marche sur mon gros orteil » « et toi tu as dit que ma jupe etait ridicule » 1476 av X.E
«tu as marche sur mon gros orteil » « et toi tu as dit que ma jupe etait ridicule » 1476 av X.E
Ce tutoriel fait échos aux suivants :
- Précis condensé à l'usage d'un nettoyage
- Nettoyer les mods - Pourquoi ? - Comment ?
Il n'est pas nécessaire de les consulter pour ce qui va suivre.
XEdit est le terme générique pour désigner Tes4Edit, Tes5Edit, FO3Edit, FNVEdit etc, tout ce qui est écrit ici est applicable aux autres jeux.
L'ensemble du tutoriel n'est pas très lourd et est ponctué d'images ; il a pour but de vous aider à identifier les conflits, qu'ils soient directement visibles en jeu ou masqués insidieusement. Certaines parties s'adresse toutefois à des personnes ayant des connaissances de base pour reconnaître et identifier certaines informations. Il se déroule en quelques étapes clés :
1 - Être à jour
2 - Essence du conflit
3 - Charger les mods
4 - Préparer le filtre
5 - Identifier et résoudre un conflit 6 - Résoudre un conflit 7 - Conclusion
1 - Être à jour
Première étape et non des moindres : utilisez toujours la dernière version de xEdit.
| Oblivion | Fallout 3 | Fallout New Vegas | Skyrim | Enderal | Skyrim Special Edition | Fallout 4 | Fallout 76 |
|---|---|---|---|---|---|---|---|
2 - L'essence du conflit
Il y a conflit lorsqu'une entrée ( « Record » en anglais) identifiée par son FormID unique est modifiée dans au moins 3 mods : un maître (qui est très souvent un esm) et 2 overrides qu'on peut traduire par « passer outre » ou « primer sur ». Le conflit survient lorsque les deux overrides modifient des aspects différents de la même entrée, faisant que par l'ordre de chargement le dernier mod remplace les modifications du premier. Ainsi, le dernier mod chargé est le « Gagnant du conflit » tandis que le premier mod, dont les changements ont été annulés, est le « Perdant du conflit ». Dans xEdit, les perdants de conflit apparaîtront sur un fond rouge, avec un texte rouge.
Il est tout à fait possible d'avoir plusieurs mods modifiant une même entrée sans créer de conflit, tant que la dernière version chargée de cette entrée inclut tous les changements des autres mods. C'est le but des patchs, et le processus pour en créer commence par l'application d'un filtre que nous détaillerons après ces quelques exemples visuels :
LeModA.esp rajoute la très fameuse scène de la danse de l'ours et du Grosse-barbe au sortir d'Helgen :
LeModB.esp se contente lui de modifier la zone en la rendant moins « autoroute direction la grotte cachée » :
Si on charge maintenant ces deux mods, avec en premier LeModA puis LeModB, on voit qu'il y a visiblement un conflit. Pas nécessairement avec les éléments ajoutés par l'un et l'autre, mais par le terrain (hauteur, textures et herbes) modifié successivement par ces deux mods au mod endroit :
Si on charge LeModA après LeModB :
Le compromis est assez intéressant, mais pour cela il faut déjà savoir quel(s) mod(s) modifient ces lieux et qui ne résout pas totalement le conflit. Un moyen très efficace est de se placer au plus près d'un objet problématique, d'ouvrir la console avec la touche ² , cliquer sur l'objet et noter le FormID indiqué en haut de l'écran. Il nous permettra par la suite de trouver rapidement au moins quelle cellule est impactée, et donc par quel(s) mod(s). Si vos problèmes sont liés au jeu Skyrim, More Informative Console peut vous aider à cibler plus rapidement en indiquant quel plugin modifie en dernier l'élément sélectionné (attention, ce n'est pas forcément lui qui posera problème).
3 - Charger les mods
À l'ouverture de xEdit, une liste des fichiers .esm et .esp présents sur votre installation apparait. Vous pouvez cocher / décocher ceux qui vous intéressent bien que normalement, ceux cochés sont ceux de votre profil de jeu et ordre de chargement.
Si vous cherchez à l'aveuglette, laissez les mods que vous utilisez cochés. Si vous cherchez un conflit entre quelques mods en particuliers, alors pour un gain de temps lors du filtrage décochez les mods qui ne vous intéressent pas. On est parfois surpris de découvrir des conflits là où il ne devrait pas y en avoir, alors soyez bien sûr !
Attendez quelques dizaines de secondes le temps que le programme charge toutes les entrées de tous les mods. Vous êtes informé que tout est chargé lorsque dans l'onglet « Messages » la ligne « Background Loader: finished » apparait.
4 - Préparer le filtre
« La Joueuse et le Moddeur » - 817 av X.E
xEdit intègre désormais une fonction rapide de création de filtre pour la recherche de conflit. Faites un Clic droit sur n'importe quel mod de la liste > Apply Filter to show Conflicts
Vous pouvez également créer un raccourci via MO2 par exemple, en utilisant l’argument -quickshowconflicts. Une fois après avoir séletionné les mods à charger, xEdit lancera immédiatement le filtrage. Vous pouvez aussi utiliser -veryquickshowconflicts avec le même effet, l'étape de sélection des mods sera sautée et xEdit chargera tout ce qui se trouve dans votre liste Plugins.txt (à moins que vous pressiez la touche CTRL).
Armez-vous de patience, suivant votre liste de mod cela peut prendre plusieurs minutes et consommer un peu de ressources de votre machine, xEdit vous rassurera de temps en temps avec un « Still applying filter » dans l'onglet Messages. Au terme du processus, xEdit vous informera avec un Done: Applying Filter, précédé de la liste des mods conservés, ceux n'entrant pas en conflit étant masqués pour une meilleure lecture et ceux conservés le sont uniquement avec les records en conflit. Ici pour l'exemple, le processus a pris 3min 21, et j'ai un installation très légère (parce que je ne joue quasiment pas, je nettoie et teste des mods pour vous haha
)
Le code couleur est expliqué via le bouton « Legend », visible depuis l'onglet « View »
Couleur de fond :
Blanc - Simple entrée
Vert - Plusieurs modifications ne créant pas de conflit
Jaune - Remplace mais sans créer de conflit (souvenez-vous, il faut au moins 2 mods modifiant une même entrée d'un master)
Rouge - Conflit
Couleur du texte :
Noir - Simple entrée
Violet - Master (les éléments de base)
Gris - Identical to Master (ITM)
Jaune/or - Identical to Master mais gagnant le conflit
Vert - Remplace mais sans créer de conflit
Orange - Gagnant du conflit
Rouge - Perdant du conflit
Vous retrouverez ces couleurs aussi bien dans l'arborescence que dans le tableau comparatif de l'onglet « View ». Suivant vos paramètres d'interface, l'aspect peut varier avec mes captures d'écrans, c'est que j'utilise le thème original. Vous pouvez changer cela dans les Options > UI Themes.
Par exemple, un mod qui rajoute de nouvelles armures devrait avoir dans son arborescence, pour le groupe Armor, uniquement des entrées écrites en noir sur fond blanc (et qui donc, ne devraient pas ressortir dans le cas d'un filtrage).
Vous pouvez supprimer le filtre pour afficher la totalité des entrées immédiatement en faisant un Clic droit dans l'arborescence > Remove Filter. Mais attention, rétablir le filtre impliquera un nouveau temps de calcul.
5 - Identifier un conflit
- 5.a - Compréhension du tableau
Affichez l'onglet « View ». Celui-ci se présente sous la forme d'un tableau récapitulatif et comparatif de chaque mods / entrée / champs. Il se lit de gauche à droite et respecte l'ordre de chargement de votre liste. Aussi, le mod le plus à droite est celui dont les modifications l'emporte sur un autre mod avec lequel il pourrait être en conflit.
- 5.b - Recherche
Le filtre est créé, si vous aviez noté précédemment un formID comme indiqué ici par exemple, vous pouvez le renseigner dans le champ dédié en haut à droite pour voir si cet élément ressort. S'il s'agit d'un élément vanilla modifié, par exemple un arbre déplacé par un mod, puis par un autre, il devrait apparaitre. Si aucun résultat ne sort, c'est que le filtre l'a exclu. Depuis Fallout New Vegas, les commandes de débug en jeu permettant de se localiser ne sont plus fonctionnelles, aussi, pour éviter d'avoir à refaire le filtre, je vous recommande d'ouvrir une seconde instance d'xEdit avec les mêmes mods chargés, ne pas filtrer et y faire la recherche. Cela vous permettra de localiser la cellule impactée, dans le cas d'une modification de paysage ou d'intérieur. Vous pourrez ensuite faire une cherche à nouveau avec l'EditorID ou le FormID de la cellule. La plupart des cellules extérieures n'ont pas d'EditorID, et leur nom correspond à des coordonnées sur une grille. Le FormID marche tout le temps !
Pour comprendre l'arborescence liées aux cellules extérieures :
Il y a différents espaces (Wordspace) regroupant de grands ensembles de cellules (Blocks). Ces Blocks contiennent d'autres ensembles, les Sublocks, dans lesquels les cellules sont rangées. Ces cellules ont des propriétés, par exemple la hauteur de l'eau, tout ce qui concerne le terrain, la dénivellation, le climat etc. Enfin, en bout d'arborescence, les cellules contiennent des objets placés dans Temporary (car tous ces éléments ne sont pas conservés dans vos sauvegarde, et régulièrement purgés / réinitialisés).
Les objets persistants, comme les portes, marqueurs, râteliers, bibliothèques et d'autres éléments dont on a besoin de conserver l'état pour le fonctionnement de scripts ou quêtes, sont eux tous groupés dans une cellule fictive du Worlspace appelée Persistent Worldspace Cell, normalement en tête de liste.
Les cellules intérieurs sont elles rangées dans Cell, et embarquent chacune leur groupe Temporary et Persistent.
- 5.c - Exemple
Dans l'onglet « View », on peut voir avec quel(s) mod(s) cette entrée sélectionnée est en conflit (encart bleu sur l'image). La première colonne (encart violet) est générique, c'est une liste des paramètres possibles pour ce type d'entrée (position, taille, contenu, nom etc.). En descendant un peu, on peut voir qu'est-ce qui est en conflit, c'est le paramètre « Respawn » (encart orange-un-peu-saumon-mais-pas-trop) qui définit si oui ou non, le contenu du coffre sera régénéré en même temps que la cellule (au bout de 72 heures en jeu). C'est un coffre générique. On voit que dans Skyrim.esm, par défaut il ne se renouvelle pas. On voit que le mod « Clothings & Clutters fix » change ce paramètre. Ce n'est pas nécessairement incohérent, sans connaitre les détails de ce dernier mod, l'action était peut-être volontaire.
Par contre, le mod « NerniesThiefPack » modifie également ce type de coffre en y rajoutant une arme (ligne Item). Comme le mod a été construit sur la base de Skyrim.esm simple, il n'est pas au courant qu'un autre mod modifie également le coffre, et enregistrant les modifications du coffre, il enregistre dans la foulée tous les autres paramètres et donc rétablit ceux par défaut.
Et du coup cela crée un conflit.
6 - Résoudre un conflit
Dans cette partie nous allons essayer de voir ce qu'il est possible de faire pour résoudre un conflit. Il existe des quantités de types de conflits possibles à combiner proportionnellement avec le nombre de mods utilisés, alors autant être honnête, les solutions miracles n'existent pas.
De manière non-exhaustive on peut déjà lister cela :
- Avoir des mods nettoyés : un mod comportant des éditions qui par exemple rétablissent du contenu de base involontairement invalideront des modifications apportées par d'autres mods et PNO. Des références supprimées et utilisées par d'autres mods feront carrément planter le jeu. Je vous renvoie aux différents tutoriels sur le nettoyage des mods pour cet aspect. Quoi qu'il en soit, c'est aux créateurs et créatrices de s'assurer en premier lieu que leurs mods sont propres. Nous faisons notre possible pour nettoyer ou au moins alerter les moddeurs lorsque nous mettons des mods en ligne sur le site de la Confrérie, mais gardez à l'esprit qu'une quantité énorme d'anciens mods ne le sont pas (encore), et que dans la masse de nouveaux nous ne pouvons gérer systématiquement cela avec l'effectif de l'équipe et les affinités ou non, avec ces aspects
- Avoir des mods bien rangés : on l'a vu, cela permet de trouver des compromis, parfois de rétablir totalement des modifications non-voulues induites par d'autres mods. Les gestionnaires d'ordre de chargement vous aident à cela, par exemple LOOT avec ses algorithmes tentera de faire au mieux, tandis que BOSS appliquera des listes de mods créées et entretenues par des humains, sur la base de tests et retours de la communauté. Aucun de ces deux exemples n'est ni infaillible ni parfaitement interchangeable !
- Limiter le nombre de mods : oui c'est un peu « dis-moi de quoi tu as besoin, et je te dirai comment t'en passer », mais honnêtement, au bout du troisième mod de météo, du quatrième modifiant les PNJS et du douzième pour l'aspect des cités, vous vous doutez qu'à un moment il va se passer un truc.
- Utiliser les patchs existants et dédiés : ils sont conçus pour rendre pleinement compatibles quelques mods entre eux, les compromis faits sont généralement minimes voire inexistants.
- Utiliser les utilitaires de créations de patchs : Bashed Patch, Merge Patch etc. il existe là aussi quelques outils permettant de faire une tambouille automatisée. Il faudrait des kilomètres de texte pour expliquer leur fonctionnement et ce n'est pas le but ici, référez-vous à d'autres sources et lisez-moi préconisant de passer par ces étapes. Dans ces cas aussi, certains compromis seront faits et les problèmes liés au landscape ne seront pas résolus par exemple.
- Créer son patch : enfin, quand tous les jokers ont été fumés, qu'aucune communauté ne peut pas vous apporter une solution clef en main, c'est à vous de retrousser vos manches et de contribuer ! Nous allons étudier ici une approche rapide, qui ne nécessite pas d'utiliser les outils de création mais seulement xEdit - puisqu'il est déjà ouvert et pointe ce qui ne va pas !
6.a - Un patch simple avec xEdit
Nous allons utiliser une fonctionnalité d'xEdit permettant de copier une entrée dans un mod existant ou créé pour l'occasion. Pour cela, sélectionner dans l'arborescence l'entrée en conflit la plus modifiée par un mod (ça marchera tout pareil si vous prenez l'entrée vanilla de l'esm, c'est juste pour limiter les manipulations), faites un Clic droit dessus puis > Copy as Override into...
Pour l'exemple, j'ai reproduis un conflit similaire à celui décrit en 5.c - Exemple.
Choisissez ensuite dans quel mod vous aller copier l'entrée. Ici le but étant de créer un patch, nous allons créer un nouveau fichier simple de type ESP. Pour cela sélectionnez le template de fichier adapté à votre besoin (ici c'est le premier), et validez avec Ok :
Donnez-lui un nom qui vous permettra de retrouver facilement sa fonctionnalité (donc tout l'inverse de l'exemple) et validez :
Un nouveau fichier est créé avec le nom que vous avez choisi. Il est automatiquement rangé en dernier. Vous allez pouvoir y transposer les modifications de LeModA.esp et LeModB.esp lorsque cela est possible. Pour faire cela, il y a différentes techniques à maitriser.
- La plus simple est celle du Glisser-déposer lorsqu'il est possible de le faire (par exemple ici pour le flag Respawn). Vous pouvez aussi éditer directement la cellule de destination, mais il vaut mieux savoir ce que vous faites. Le logiciel sait quel type d'information doit recevoir une cellule, vous êtes relativement bien encadré.
- Pour rajouter des objets à une liste, il faudra y faire un Clic droit > Add dans la toute première ligne de l'arborescence (ici ce sera Items (sorted)). Une nouvelle entrée avec NULL comme référence est créée, et le nombre d'objets est mis à jour (on passe ici de 5 à 6). Sans cette étape intermédiaire, il ne sera pas possible de glisser ou ajouter une référence.
Et voici le résultat final. Vous l'aurez compris, ce n'est pas avec cela que vous pourrez remodeler le paysage, mais vous pourrez conserver des modifications d'un mod chargé en milieu de votre liste si elles sont écrasées par d'autres et que l'ordre de chargement ne peut être changé. Construire manuellement implique de connaître un peu l'architecture et le fonctionnement du jeu. Toutefois, si effectuez les modifications dans un nouveau fichier créé pour l'occasion vous vous assurez une certaine sécurité.
Pour ajouter d'autres entrées au mod patch, il faudra de nouveau utiliser la fonction Copy as Override into... en cochant cette fois le mod précédemment créé. Vous pouvez copier une portion d'arborescence (l'option se renomme automatiquement alors Deep copy as Override into..., puis supprimer dans le mod de destination le surplus avec Clic droit > Remove.
Petit plus pour terminer, xEdit peut nous indiquer où sont utilisées les références, ici notre coffre. Comme c'est un coffre générique, il est utilisé à plusieurs endroit, en fait, à 49 autres endroits différents comme l'indique l'onglet « Referenced by () » :
► Afficher le texte
Pensez à sauvegarder votre œuvre !
6.b - Un patch pour l'aménagement de paysage
Il faudra pour cela utiliser les outils de développement (CS, GECK, CK etc.) . Je résume génériquement la procédure car l'objet de ce tutoriel n'est pas de vous apprendre à vous servir des éditeurs :
- Transformez vos fichiers à patcher en master. Pour cela, chargez-les dans xEdit, dans l'arborescence séléctionnez File Header, et dans l'onglet View cliquez dans le champs en face de Record Flags et cochez ESM, pour chacun des mods concernés. Vos mods sont désormais considérés comme des ESM, leur extension reste en .esp et c'est normal, il ne faut pas la changer.
- Sauvegardez et quittez xEdit
- Ouvrez votre éditeur de jeu, cochez vos nouveaux master et chargez
- Vous pouvez désormais faire les ajustements visuels nécessaires dans la fenêtre de rendu (déplacement du terrain, déplacement d'objets se superposant etc.)
- Sauvegardez, avec un nom approprié et si possible une description et quittez l'éditeur.
- Ouvrez à nouveau xEdit, repassez vos mods en conflit en ESP en décochant le flag ESM, sauvegardez.
- N'oubliez pas de vérifier la propreté de votre nouveau mod et de le nettoyer au besoin, il serait idiot de créer un nouveau conflit inutile !
- Suivant l'éditeur de jeu que vous utilisez, si vous devez refaire des modifications il sera très certainement nécessaire de repasser les mods conflicuels en ESM pour les charger sans que votre mod de patch en perde la dépendance.
7 - Conclusion
Voilà, vous savez désormais cibler les conflits et en résoudre une petite partie, mais parfois (souvent) ils sont liés à des modifications sauvages apportées par les mods. Ces modifications sont soit directement liées à une fausse manipulation de l'auteur comme ici avec la modification d'un coffre générique au lieu de créer un nouveau coffre pour y ranger une arme unique, soit aux mécaniques du programme de d'édition (CS, CS1.2, GECK, CK etc.) qui font qu'en validant une fenêtre, cela est considéré comme un enregistrement et donc une modification. Idem pour les copie d'objets et la suppression, mais tout ceci est concerné par le nettoyage :
- Précis condensé à l'usage d'un nettoyage
- Nettoyer les mods - Pourquoi ? - Comment ?
N'hésitez pas à poster vos questions et remarques à la suite du sujet !
