Bonjour
Pour commencer un petit peu de baratin généraliste, je m'excuse d'avance de dévier un peu des questions plus concrètes.
Pour une installation "propre" des mods, il y a trois paramètres à prendre en considération :
1) la propreté des mods utilisés : c'est la responsabilité conjointe du moddeur et du testeur de fournir des mods les plus propres possibles, pas celle du joueur. Propre cela signifie que le mod ne doit modifier strictement que ce qui est nécessaire, et d'autre part, lorsqu'il procède à des modifications, il doit les effectuer de la façon la élégante possible, c'est à dire éviter d'entrer en conflit avec d'autres modifications venant d'autres mods, lorsque c'est possible.
En cas de doute, je recommanderais de poster sur le sujet du mod associé plutôt que de se lancer dans un nettoyage sauvage (d'une part pour éviter d'éventuelles erreurs, d'autre part pour en faire profiter la communauté si jamais le mod est effectivement sale). Evidemment, on ne garantit pas la propreté des mods venant d'autres sources et tous les sites n'ont pas le soucis de proposer des mods propres.
Un joueur n'a donc pas a priori à nettoyer ses mods, même en utilisant la procédure automatisée de Testools. Testools n'a pas la panacée universelle même pour la procédure de nettoyage qui est pourtant très fiable. Il existe par exemple un sujet entier de dix pages sur le forum officiel consacré aux mods qui ne doivent pas être nettoyés avec Testools.
2) l'ordre de chargement des mods : l'ordre de chargement des mods ne doit pas être bouleversé en cours de jeu, dans la mesure du possible, sous peine de risquer des corruptions, des références manquantes et des doublons dans la sauvegarde. Cela survient en particulier lorsqu'on ajoute ou que l'on retire des mods en cours de partie.
Il est donc fortement recommandé d'éviter de retirer ou d'ajouter des mods en cours de partie. Si on veut ajouter un mod, il est souhaitable qu'il soit chargé en dernier (d'où une certaine utilité à la procédure "update time" de Testools).
3) les conflits entre les mods : différents mods peuvent modifier les mêmes données. Le dernier mod chargé prend alors le dessus et écrase les modifications précédentes. Une seule modification mineure peut entraîner l'écrasement d'un grand nombre de données. Par exemple quand vous modifiez la quantité d'argent dont un marchand dispose, vous modifiez entièrement ce marchand, tous ses paramètres sont sauvegardés dans l'esp et donc votre mod est de facto incompatible avec tous les mods modifiant ce PNJ. Parfois cela est "normal" pour ainsi dire, parfois cela compromet sérieusement le fonctionnement de l'un ou l'autre plugin en conflit. Dans tous les cas, les conflits entre plugins doivent être identifiés clairement par le joueur (parce prévoir, identifier et résoudre tous les conflits entre un millier de créations dans une quasi-infinité de configurations d'installations différentes n'est clairement pas possible ni pour les testeurs ni pour les créateurs de mods). A ce titre la fonction "
generate detailed conflict report" de Testools ou le TES Plugin Conflict Detector (TESPCD) rendent d'inestimables services.
Après c'est au joueur d'interpréter les résultats de ces rapports de conflits (normalement, les moddeurs ont également dû documenter ces possibles conflits dans leur readme) et d'agir en conséquence.
- soit certaines modifications restent écrasées et le joueur fait avec, il peut éventuellement changer l'ordre de chargement de ces plugins pour que la modification qu'il préfère conserver soit retenue.
- soit dans certains cas comme les leveled lists, il est possible de résoudre le problème en faisant un merge avec un outil approprié. Par contre les merges par Tesame ou le tescs ne résolvent pas les problèmes de conflit, ils se contentent d'empiler les données des esps en écrasant au fur et à mesure s'il y a conflit.
- soit le joueur se bricole un patch de compatibilité de façon à pouvoir utiliser les mods ensemble en conservant tous leurs apports (ce qui peut être long ou pénible dans certains cas et peut nécessiter des compétences de modding ou tout au moins dans l'utilisation du tescs, et dans tous les cas, d'avoir une idée claire de comment ça marche et de ce que l'on fait)
Les problèmes sérieux rencontrés par les joueurs sont liés à un de ces trois points. Le problème d'avoir un warning "Un ou plusieurs plugins n'ont pas pu trouver la bonne version du fichier master dont ils dépendent. Des erreurs pourraient se produire en cours de chargement ou de partie. Consultez le fichier "warnings.txt" pour de plus amples précisions." lors du chargement ne fait pas partie des problèmes sérieux.
Quant aux retours bureau, ils ont de multiples origines (bug du moteur, ressources graphiques manquantes, erreur du moddeur, surcharge CPU, paramètres de Morrowind.ini incorrects, sauvegarde corrompue, défaut de fichier maître, etc etc.) et il n'est pas possible de dire a priori quelle en est la cause directe.
Citation
Je précise que Sara et l'argonien qui la vend sont là, sans problèmes apparents ... par contre je ne vois pas la borne pour se téléporter vers Gilbertus et faire tous les réglages pour Kalendaar ... mais peut-être apparait-elle seulement lorsque l'on a acheté Sara, je ne sais plus ...
La borne n'est pas visible au début du jeu
Citation
2/Est-il nécessaire, une fois Kalendaar installé, de lui appliquer update time et update header, comme les autres mods ?
Il n'est pas nécessaire d'appliquer update time et update header pour faire marcher n'importe quel mod. Le seul but de cette manoeuvre expliquée dans le wiwiki est de supprimer le warning au chargement des plugins.
Il faut comprendre qu'en matière d'installation de mod le mieux est l'ennemi du bien. Ce n'est pas parce qu'on va utiliser douze mille outils tiers différents, suivre cinquante-trois mille procédures d'installation à la virgule près qu'on aura au final une installation propre et sans bug. Il est au contraire fort probable qu'on aura au final une installation infiniment plus sale qu'à l'origine, parce qu'on va suivre des recettes de cuisine sans comprendre ce que l'on fait, parce que les outils qu'on utilise et les directives que l'on suit sont faillibles et d'application limitée. A l'arrivée, bien sûr, le plat final peut être immangeable même en suivant la recette.
Citation
3/C'est peut-être la question qui me "tracasse" le plus, comme j'utilise morts vivants et créatures, je fais, comme j'ai déjà lu qu'il le fallait, une nouvelle liste de niveaux pour que ces mods soient compatibles ... j'utilise TESTool, avec la fonction Merge Leveled Lists for active plugins, par contre, dois-je cocher aussi Kalendaar, lorsque je fais cette nouvelle liste de niveaux ? Je l'ai faite en cochant tous mes mods actifs, mais peut-être ne dois-je la faire qu'en en cochant certains, et pas d'autres ... c'est là que cette fonction est un peu floue pour moi. De plus, au cours d'installations de Morro très similaires dans les mods, il m'arrive que TESTool génère, au cours de la création de cette nouvelle liste, un fichier nommé, je crois, TESTool.bak, et d'autres fois, non . Pour cette installation, il en a généré un.
Il est nécessaire de faire des merges de leveled lists lorsque et seulement lorsqu'il y a des conflits entre les leveled lists de différents mods, c'est à dire, la plupart du temps, entre les mods qui modifient les leveled lists originales.
Kalendaar utilisant son propre espace, ses propres leveled lists, il est improbable qu'il soit concerné par un merge de leveled lists.
D'ailleurs, à ce sujet, d'après Wrye, Testools ne merge même pas les leveled lists correctement ( source :
http://www.uesp.net/...d:Leveled_Lists )
Lorsque Testools travaille, il génère à la fin un fichier de rapport nommé Testools.log. Lorsque ce fichier est mis à jour, l'ancien contenu du fichier Testools.log est copié et sauvegardé dans un fichier testools.bak. C'est une procédure standard, le tescs fait de même lorsqu'il sauvegarde des esps.
Citation
1/ Est-il préférable d'installer Kalendaar avant ou après le PNOG, ou du moins lequel est-il préférable de charger en premier ?
L'ordre d'installation des mods (pas leur ordre d'activation au cours d'une partie) n'a aucune importance. Ce qui importe est, pour ces deux mods, de les installer seulement au commencement d'une nouvelle partie.
Les conflits entre Kalendaar et le PnoG sont minimaux et l'ordre de chargement n'a donc pas vraiment d'importance. Etant donné quelques données résiduelles dans Kalendaar.esm qui seraient à vérifier, je recommanderais toutefois de charger le PnoG après Kalendaar (ce qui est l'ordre par défaut)
Citation
La fonction JUST FIX IT est-elle "propre", puis-je l'utiliser aussi avec Kalendaar installé, et si oui, dois-je laisser les options par défaut, ou en cocher ou décocher certaines pour que cela fonctionne ?
Non
Citation
Est-il vrai, pour tous les mods dont il est conseillé de les sauvegarder dans le tesc, qu'il ne faut pas le faire parce que cela les "salit" plus qu'autre chose,
Oui
Citation
et que les deux fonctions update time et update header remplacent cette sauvegarde dans le tesc ?
Oui, si l'on peut dire.
Testools redate l'esp pour le mettre à la date la plus récente (de telle sorte que l'esp soit chargé en dernier), et fait passer le numéro de version de l'esp à 1.3 ce qui élimine le warning "Un ou plusieurs plugins n'ont pas pu trouver la bonne version du fichier master dont ils dépendent. Des erreurs pourraient se produire en cours de chargement ou de partie. Consultez le fichier "warnings.txt" pour de plus amples précisions." qui apparaît lorsqu'on charge un mod Morrowind seul ou Morrowind + Tribunal sur une install Goty ou Bloodmoon.
Stricto sensu, aucune de ces opérations n'est toutefois nécessaire pour faire marcher correctement un plugin.
Citation
Je pense notamment à Qynn 1, 2 et 3, dont la procédure d'installation "complexe", implique apparemment comme étape incontournable de les sauvegarder l'un après l'autre en les cochant.
Ce n'est certainement pas incontournable. S'il agit de rendre tous les esps dépendant à Tribunal et Bloodmoon, on peut utiliser TESDTK ou d'autres outils pour cela.
Ce qu'il faut comprendre enfin, c'est que les instructions données dans un readme datant de plusieurs années sont des recettes de cuisine, données à une certaine époque, avec les connaissances et les outils de l'époque, conseillées pour résoudre un problème précis, sans garantie qu'il n'y ait pas d'effet secondaire indésirable ; or la compréhension de la gestion des mods, les méthodes et les outils disponibles ont évolué depuis, sans compter que les problèmes ne se posent plus forcément dans les mêmes termes (ex l'update des sauvegardes et des esps pour le passage à Bloodmoon en cours de jeu était important en 2003/2004 mais n'a plus guère d'intérêt aujourd'hui)