Moder proprement.

Il ne s'agit pas du tout d'une procédure à suivre, mais de plusieurs points auxquels il faut songer au cours de la réalisation d'un Mod.
Il ne s'agit pas ici d'un "purisme" excessif, mais tout simplement de petits trucs qui vous permettront d'avoir un Mod au final qui sera fonctionnel, pratique et qui aura nettement plus de chance de s'intégrer harmonieusement avec d'autres Mod sans générer de conflit abominable.

• Contenant : Ne jamais ajouter quoique ce soit dans un inventaire, coffre, etc... déjà existant. Préférez à ceci, la méthode suivante, placez un contenant équivalent à proximité en lui donnant un nom et mettez y vos accessoires. Ceci est indispensable dans le cas d'un marchand.
  - Pourquoi : Ainsi vous ne risquez pas de voir vos objets disparaître si un autre Mod modifiant le même contenant a été chargé.
  
  
  
  
• Dénomination : Dès l'instant où vous ajoutez quoique ce soit, un objet, une maison, un PNJ, etc... Pensez à noter au début de son ID quelques lettres en majuscule qui identifieront immédiatement votre MOD. Ainsi plutôt que d'utiliser ElvenSword01 appelez la plutôt JB_EA_ElvenSword.
  - Pourquoi : Ceci vous permet surtout de vous y retrouvez plus rapidement dans les infâmes listing du CS, puisque tous vos objets se retrouvent groupés ensemble dans chaque catégorie, et surtout de vous apercevoir si certains objets n'ont rien à faire dans la version finale de votre Mod.
  
  
  
  
• Nettoyage : Lorsque vous estimez que votre Mod est finalisé, pensez à faire un nettoyage de printemps. Le CS garde en mémoire dans votre .esp "TOUTES" les modifications aussi minimes soient-elles que vous avez faîtes. Vous avez bougé par inadvertance un caillou à l'autre bout de Tamriel tandis que vous en faisiez du tourisme dans le CS, c'est noté dans l'Esp.
  - Pourquoi : Ceci allège votre Mod, évite les conflits inutiles avec d'autres Mods et vous permet d'y voir clair en un instant. Si vous avez lu mon Tutorial sur les LOD, vous noterez l'importance de cette étape. Mon .esp avant le nettoyage faisait 45Meg, pour ne plus peser que 2.5Meg une fois nettoyé. Tous les deux fonctionnaient, la seule différence est que le premier utilisait des ressources inutiles

- Mohawk -

Vous trouverez ICI un lien vers le Tuto original.



Oh non ! J'ai travaillé sur mon mod pendant des mois, suant sang et eau, et pleurant toutes les larmes de mon corps, et je viens de réaliser qu’il y a deux semaines j’ai :

• Supprimé une quête / PNJ / gadget qui était essentiel au scénario principal.
  
• Accidentellement appuyer sur « Recompile All » dans l’éditeur de script.
  
• Déplacé quelque chose dans une cellule, que je regardai pour trouver l’inspiration.
  
• Touché à un enregistrement de dialogue que je n’aurai pas dû.
  
• D’une manière ou d’une autre bidouillé quelque chose de véritablement important, dans le jeu.

Je n'ai pas de sauvegarde récente, et chaque fois que j'essaye de résoudre mon problème en copiant/collant la ressource que j’ai enlevée dans mon mod, ça ne fait qu’aggraver les choses ! Est-ce que j'ai ruiné trois mois de travail ? Est-ce que je devrai tout recommencer ? Est-ce que la vie que j’ai connue jusqu’alors vient de se terminer ?

Détendez vous. Asseyez-vous. Prenez une profonde inspiration. Maintenant, lisez ce qui suit et apprenez tout au sujet de votre vilain Mod, et comment résoudre tout cela.





Un Mod sale est n'importe quel mod dans lequel vous, le modder, avec accidentellement touché quelque chose dans la base d’Oblivion alors que vous n’en aviez pas l’intention. La plupart du temps vous ne l’aurez même pas remarqué. Peut-être étiez-vous juste en train de regarder un donjon et vous avez accidentellement poussé une roche. Ou peut-être que vous passiez en revue l’éditeur de quête en cochant les diverses cases afin d’en saisir les subtilités, puis vous avez oublié tout ceci et avez sauvegardé votre Mod. Ou peut-être que vous avez commis l'erreur classique de faire un «Recompile All» dans l’éditeur de script, et soudainement votre mod a brusquement grossi de 2MB et maintenant vous avez une copie de chaque script du jeu.

Citation :

Ne touchez jamais à la fonction « Recompile All » JAMAIS.

Souvent, un Mod sale est bénin. Vous ne savez même pas la plupart du temps qu’il était « sale » jusqu'à ce qu'un utilisateur vous demande pourquoi votre mod est en conflit avec un autre mod, et vous ne parvenez pas à comprendre ce qu’ils ont en commun. Ou peut-être vous avez noté tout de suite après que vous ayez accidentellement supprimé Martin de la quête principale, mais vous ne savez tout simplement pas comment rétablir les choses.





Heureusement la solution à tous ces problèmes (et à bien d’autre encore) est le bouton « Détails ». Le bouton « Détails » peut être trouvé sur l’écran de chargement, lorsque vous chargez votre Mod, à la droite du bien connu « Set Active File ».




Cliquer sur le bouton « Détails » vous projette dans les entrailles de votre mod. Il vous montre une liste des enregistrements de votre mod, qui sont les instructions qui indiquent à Oblivion comment changer le principal dossier Oblivion.esm. Tout ce que vous faites dans votre mod, chaque changement que vous faîtes, s’ajoute à cette liste. Même la suppression un objet de base d'Oblivion ajoute un nouvel enregistrement à votre mod qui demande à Oblivion d’enlever cet article du monde que vous proposez au joueur. Fondamentalement votre mod est simplement une énorme transformation étant appliqué à l'Oblivion.esm, et la fonction « Détails » vous laisse voir chacun de ces infimes changements que vous avez vous-même créés.
Il y a une raison pour laquelle nous ne faisons pas notre modding quotidien par l’intermédiaire du rédacteur de détails, c'est qu’il n’est pas exactement la chose la plus simple à comprendre.




Cependant, le concept de base est tout à fait simple. L’enregistrement énumère quel genre de chose a été changé. Ceci peut être une référence (REFR), une ligne d’entrée d’un dialogue (DIAL), quelque chose au sujet d'un worldspace (WRLD) ou d'une cellule (CELL), ou tout autres choses. Souvent, ces enregistrements sont regroupés. Ainsi modifier une cellule extérieure « touche » également le worldspace contenant cette cellule, et vous verrez les deux enregistrements dans la liste de détails. Vous savez quand quelque chose est lié parce qu'elle sera précédée par un enregistrement de GRUP qui ne peut pas être modifié. L’objet précédent l’enregistrement GRUP correspond à ce qui a été modifié au sein du groupe suivant. Ainsi, par exemple, la modification d'une cellule sera décrite par l’enregistrement d’un WRLD, suivit d’un enregistrement GRUP, suivi d'un enregistrement de CELL.




Les autres données sont nettement plus claires. La colonne « D » indique tout simplement que l’enregistrement supprime l'article référencé, plutôt que de le changer. La colonne « I » vous signale que cet enregistrement est ignoré. La colonne suivante est l’identifiant de l’enregistrement, qui peut être toutes sortes de choses différentes, en fonction du type d’enregistrement. Habituellement vous pourrez comprendre ce don il s’agit en fonction de l’identifiant et du type.






La véritable puissance dans cet écran vient de sa capacité à ignorer les enregistrements. Pour ignorer un enregistrement, il suffit de le sélectionner et de valider avec la touche « Suppr » de votre clavier. Si vous vous apercevez d’une erreur, sélectionner à nouveau votre ligne et valider à nouveau avec « Suppr », votre ligne revient à son état initial.
Ignorer les enregistrements est la manière selon laquelle vous nettoyez un mod. Recherchez simplement dans la liste des enregistrements de votre mod jusqu’à trouver l'article qui correspond à votre changement accidentel.
Si vous aviez supprimez un NPC, vous verrez probablement un enregistrement de NPC_ ou de REFR avec une annotation « D » dans la colonne attenante. Si vous aviez déplacé accidentellement une roche quelque part, vous verrez un enregistrement de CELL concernant la cellule que vous avez touchée, suivi d'un enregistrement de GRUP, suivi de plusieurs enregistrements de REFR concernant les choses que vous avez accidentellement déplacées. Naturellement, chaque cas est unique, mais en cherchant un peu et avec du bon sens vous devriez retrouver ce que vous cherchez.
Le seul avertissement est de s'assurer que vous avez vraiment trouvé tout ce que vous avez touché. En raison de l'emboîtement, le déplacement d’un objet dans une cellule peu potentiellement toucher la REFR de cet objet, l’enregistrement de la CELL qui le contient, et l’enregistrement du WRLD où elle est située, tout à la fois. Pour nettoyer ceci correctement vous devriez ignorer chacun de ces trois enregistrements (en supposant que vous n’aviez pas fait d’autre modification dans cet ensemble de cellules/monde).



En conclusion, ignorez les enregistrements non désirés en frappant « Suppr ». Chargez le mod, puis sauvegardez le, et ces changements disparaîtront pour toujours de votre mod. Les cellules que vous n'avez pas voulu toucher n’apparaîtront plus comme étant modifié. Les NPCs que vous avez accidentellement supprimé se retrouveront là où vous les aviez laissés. Les conflits mystérieux disparaîtront soudainement. Vos utilisateurs se réjouiront, et vous pouvez pousser un soupir de soulagement !

______________________________________________________________________________________
par dev_akm, Martigen, et Blade9722

Comme de plus en plus de modders expérimentent l’usage des fichiers principaux (ESMs), ils rencontrent fréquemment des erreurs inattendues, telles que des disparition de paysage et des erreurs de duplication (Duplicate) dans le CS. Ce problème provient d'un manque de bonnes informations sur la façon créer des fichiers maîtres propres.

Vous ne pouvez pas stocker des changements de paysage à un worldspace existant dans un ESM. En fait, vous ne devriez enregistrer aucun changement dans un ESM, bien qu'un bon nombre de gens le fassent, créant ainsi des fichiers «maîtres sales».

J'ai décrit ce problème plus en détail et proposé de créer un outil qui résoudrait automatiquement le problème sur le site de Dave Humphrey tes4code site.

Mais que pouvons-nous faire jusqu'à ce que cette utilitaire soit fini ?

Vous pouvez créer un maître propre à la main en utilisant l’actuel TES4 Plugin Utility, mais ce peut être un processus plutôt pénible. J'expliquerai comment procédé dans une minute, mais d'abord vous devez en comprendre un peu à ce sujet et pourquoi c'est un point important. Vous aurez besoin de TES4 Plugin Utility et Wrye Bash ou TESsnip.

Le format d'ESM est employé dans beaucoup de cas sans aucun respect pour le fait que le mod change des enregistrements dans un fichier principal ou non. Les raisons de cet état de fait sont assez évidentes : il est facile de le faire avec les outils actuels, ceci fonctionne habituellement dans le jeu sans problème et fonctionne habituellement très bien également dans le CS, et c'est la solution facile pour de nombreux problèmes où vous essayez d'ajouter un contenu original aux objets d’origine (tels que les listes de niveaux). Les Modders commencent généralement par la construction d’un ESP qui comprend des changements de Oblivion.esm, puis décident plus tard qu'ils veulent convertir leur mod en maître pour quelque raison (les limites de taille, l'extensibilité, et la compatibilité sont les seules bonnes raisons qui me viennent à l'esprit). Nous utilisons des outils faits par la communauté pour réalisé ceci, puisque Bethesda a enlevé les siens du CS, mais nos outils conçus par des fans ne prêtent aucune attention à la méthodologie de conception que Bethesda a utilisé dans sa structure d'ESM/ESP, et en conséquence nous voyons apparaître des problèmes dans le CS quand nous essayons d'employer ces fichiers maîtres bricolés.

La majeure partie du temps, nous convertissons intégralement un ESP en ESM, alors qu’en vérité il n'y a absolument aucun avantage à gagner pour plusieurs (peut-être même pour la majorité) des enregistrements dans ce mod puisqu'ils sont tout simplement des changements aux enregistrements maîtres existants dans un autre ESM plutôt que du nouveau contenu. En fait, la seule chose que nous gagnons en procédant ainsi est un mal de tête pour n'importe qui désirant employer le contenu de ce nouvel ESM tout neuf.

Si nous voulons vraiment que d'autres modders puissent se baser dessus, réutiliser, étendre, et augmenter notre nouveau contenu, alors la mise en place au sein d’un ESM est la bonne solution. Mais si nous polluons également l'ESM avec des enregistrements de reproduction d'un autre maître (particulièrement Oblivion.esm), alors nous nous tirons en même temps dans le pied.

Ceci est tout à fait compréhensible étant donné les limites des outils que nous avons à notre disposition, mais tout ceci ne doit pas être fait de cette façon. Nous pourrions et devrions créer des outils qui font un travail bien meilleur dans la création d’un maître ESM-- en séparant les nouveaux enregistrements des enregistrements de modifications, en mettant les nouveaux enregistrements dans un ESM et en mettant les modifications qui en découlent dans un ESP.

Il est tout à fait faisable de faire et d’employer des fichiers maîtres propres dès aujourd’hui. En fait, les seuls mods qui devraient rencontrer des problèmes réels sont ceux qui provoquent des changements à grande échelle de l'Oblivion.esm. Cette méthode est tout à fait appropriée à la création de groupes de nouvelles créatures ou d’articles, de nouvelles listes de niveaux pour les contenir, et de nouveaux points de génération pour qu'elles apparaissent (même dans le worldspace existant de Tamriel), puis de convertir dès lors tout ceci en maître. Ce serait un maître propre. Car bien qu'il contienne des références à Oblivion.esm, il ajoute seulement de nouveaux contenus. Cependant, dès que nous voudrons ajouter de nouvelles créatures ou listes à des points de génération existants dans Oblivion.esm, alors nous devons faire ces changements séparément dans un ESP qui est attaché aux deux maîtres.

Cependant, cette sorte de méthodologie de conception exige beaucoup de planification, ainsi tandis qu' il peut être fait, il peut ne pas être raisonnable de s'attendre à ce que la plupart des fabricants de Mod aient pensés à toutes ces choses pendant le processus de création d’un mod. Pour résoudre ce problème, vous pouvez fractionner votre mod après l’avoir fait, en créant un composant ESM et un composant ESP (à la base en triant individuellement les enregistrements et en les plaçant dans le fichier approprié selon, qu'ils sont nouveaux ou non).

Les critères pour la séparation sont simples :

1) Si un enregistrement dans le mod a une FormID locale (c'est-à-dire qu’il ne modifie pas un enregistrement principal), alors il doit être écrit à un nouveau fichier maître ( par exemple « monmod.esm ").

2) Si un enregistrement dans le mod a une FormID étrangère c'est-à-dire qu’il est une modification à d’un enregistrement d’un fichier principal, tel que Oblivion.esm) alors il devrait être écrit dans un ESP (par exemple « mymod.esp »). Ce nouvel ESP devra être rendu dépendant de tous les maîtres qu'il met en référence (c'est-à-dire « mymod.esm " et « Oblivion.esm ").

Les nouveaux enregistrements sont facilement reconnaissables dans l'utilitaire TES4 Plugin en utilisant l'option d'Affichage/Copie d’Enregistrement (Display/Copy Records). Les nouveaux renregistrements commencent presque toujours par 01 (en fonction du fait, que vous ayez déjà plus d'un maître ou pas) et ils ne commencent jamais par 00 (ce sont toujours les enregistrements principaux, à moins que votre mod n'ait aucun maître, ce qui est peu probable). Les enregistrements de modification commenceront toujours par 00 si votre mod a seulement un maître. Si votre mod a deux maîtres, alors il peut contenir des enregistrements de modification commençant par 00 et 01. S'il a trois maîtres, de la même manière 00, 01, et 02.

Comment Procéder.
Voici les étapes de base requises pour faire ceci, se concentrant la plupart du temps sur des registres de cellules/ Worldspace et assumant seulement un maître :

1] Création du fichier ESM.
- Copier le fichier ESP original de votre Mod.
- Utiliser TES4 pour le transformer en ESM.
- Dénommer le « mymod.esm ».

- Ouvrez-le dans le TES4 (en utilisant Display/Copy plugin records) et choisissez au haut de la rangée Cellules et Worldspaces.

- Ignorez-les (Toggle Ignore)
- En option, utilisez Toggle Ignore avec tous les registres de Modification (ceux qui commencent avec un 00 dans leur FormID)
- Sauvegardez le Plugin

2] Création du fichier ESP.
- Copier à partir de l’original mymod_source.esp sous l’appelation mymod.esp (ou donnez lui le nom que vous voulez)
- Ouvrez-le dans le TES4, choisissez tout à l’exception des registres Cell et Worldspaces.
- Ignorez-les (Toggle Ignore)
- En option, utilisez Toggle Ignore avec tous les Nouveaux registres (ceux qui commencent avec un 01 dans leur FormID)
- Sauvegardez le Plugin

3] Insérez la dépendance envers les fichiers Maîtres en utilisant Wrye Bash.
- Lancez Wrye Bash.
- Effectuez un clic droit sur votre nouveau « mymod.esp » (celui que vous avez créé à l’étape 2).
- Sélectionner Ajouter Maître (Add Master) dans le menu déroulant.
- Sélectionner « mymod.esm » (celui que vous avez créé à l’étape 1).
- Valider l’opération avec « Ok ».

Mohawk a écrit:

Je vous fournirai ultérieurement d’autres méthodes, ainsi que des variantes des différentes étapes, qui pourront nous être utile dans certains cas particulier.

_________________________________________________________________________________

Si vous avez lu attentivement ce qui précède vous devez déjà avoir compris, que tout ceci va nécessiter d’apprendre à modder différemment. Le travail en équipe peut rapidement tourner au cauchemar si chacun d’entre nous ne respecte pas des règles élémentaires. Car à la différence de votre Mod individuel, si vous ne procédez pas avec prudence, vous risquez non seulement de générer des « bugs » dans votre propre travail, mais pire encore dans celui des autres. Je vais donc tenter de lister ici, les différentes choses auxquelles vous devrez faire attention lors de la création de vos Mods. Notez que j’augmenterai au fur et à mesure ce message afin d’y intégrer de nouvelles procédures visant à réduire ces problèmes.

Structure des Fichiers.
Pour la structure des fichiers, et des archives je vous propose à la base ceci :

Data
distantlod
menus
meshes
. . Archipel
sound
textures
. . Archipel
Video

Ainsi nous retrouverons immédiatement les fichiers propres au Mod, en regroupant ainsi chaque fois toutes nos ressources au sein d’un répertoire supplémentaire dénommé « Archipel » dans chaque cas.

Exemple :

Nous ajoutons une nouvelle créature, un corbeau constitué pour son modèle du fichier crow.nif
La structure classique d’Oblivion sera donc :
=>Data
==>meshes
===> creatures
====>Archipel
=====> Crow

Dénomination.
De la même manière, la manière dont nous allons dénommer nos divers fichiers devrait répondre à une structure et à des règles communes. Il y a plusieurs raisons à ceci, il est plus facile de s'y retrouver dans un premier temps si tous les fichiers commencent par le même préfixe. Au sein du Construction Set, toute les références se retrouveront ainsi regroupées dans chaque rubrique. Voici quelques règles que je vous propose :

PREFIXE OBLIGATOIRE :
Tous les fichiers commencent par ce même préfixe désignant ainsi le Mod. Notre Mod commun traitant d’un archipel je vous propose d’utiliser le préfixe AC (AR aurait été plus approprié mais ce préfixe existe déjà donc...)
AC

SECOND PREFIXE.
Le nom du fichier est ensuite suivit d'un second préfixe indiquant la partie du Mod en question. Imaginons que nous décidions de créer plusieurs scénario parallèles, chacun d'entre eux étant développés par un Moddeur ou un groupe. Ce second préfixe identifie ainsi rapidement les éléments qui sont concernés. Toujours dans mon exemple, je développe un Mod sur un culte d'adeptes de Nocturne, je l'intitule par exemple par ses initiales : Adeptes de Nocturne.
AN

SIGNATURE DU MODDER.
Poursuivons dans le même ordre d'idée, il est selon indispensable de pouvoir identifier le Modder ayant travaillé sur un fichier, un script, etc... Pas uniquement pour lui taper dessus en cas de problème mais plutot pour savoir tout de suite à qui il faut s'adresser pour une explication, une modification etc... Le plus simple étant dans ce cas que chacun d'entre nous se choisisse une signature de 2 lettres, dans mon cas :
MH

DENOMINATION DU FICHIER.
Il ne nous reste plus ensuite qu'à donner un nom à notre fichier, script, etc... Il y a ici quelques détails à noter : évitez d'utiliser des caractères spéciaux, accents, tirets, et autres symboles. De plus le nom doit être le plus clair possible. Pour des soucis de lisibilité, préférez 'usage des majuscules en début de nom, et les minuscules entre les mots
Imaginons que dans mon Mod je souhaite habiller mes adeptes de Nocturne d'une toge spécifique, je dénommerai le Meshe, ainsi que la texture qui y est jointe du même nom (puisque mes deux fichiers ne seront pas dans le même répertoire) :

TogeAdepteNocturne

Exemple.
Selon cette procédure mes fichiers porteraient les dénominations suivantes :
ACANMHTogeAdepteNocturne.nif (pour le meshe)
ACANMHTogeAdepteNocturne.dds (pour la texture de base)
ACANMHTogeAdepteNocturne_n.dds(pour la texture normale)

Citation :

L'on peut si vous le désirez développer encore plus loin cette structure en ajoutant des initiales pour le type de fichiers, pour la quête à laquelle ils sont liés, etc....

Les Plug-In s’ajoutant à Archipel.esm
Voici le début des changements réels, ce qui précède n’étant que des règles d’organisation.

Vous avez constaté que notre fichier Archipel.esm ne doit contenir que des nouveautés. Vous allez donc devoir basculer régulièrement entre deux plug-in en fonction de ce que vous faîtes. Je vais vous donnez aussitôt un exemple afin que les choses soient claires :

Je commence par créez un plug-in qui aura pour but d’être fusionné avec Archipel.esm, afin qu’il soit aisément identifié je le dénomme :

Archipel_MH_Master_01.esp

Pour le créer j’ouvre le CS, sans charger AUCUN fichier et je le sauvegarde aussitôt sous ce nom. Il s’agit en fait à cet instant d’un fichier blanc entièrement vide, mais ainsi je suis sur qu’il ne peut être lié à rien d’autre. Il possède de plus un suffixe en ESP, car il est impossible de travailler sur un fichier ESM (j’expliquerai plus tard tout ça).

Au cours de mon Mod, chaque fois que je voudrai ajouter un contenu NOUVEAU, j’ouvrirai le CS en plaçant ce fichier en « Mode Active ». Ainsi lorsque je désirerai intégrer une nouvelle épée dans le Mod, j’ouvrirai ce fichier en « Mode Active » et je créerai l’épée qui y sera sauvegardée. Mais je ne placerai pas cette arme nulle part, elle sera uniquement présente dans la liste des armes. De la même manière si je veux placer un bâtiment sur l’une des îles, je le ferai au sein de ce fichier. Il en ira de même d’un nouveau script, d’un nouveau livre, etc…

Pour résumé, TOUT ce que j’ajouterai de Nouveau (c'est-à-dire en piochant dans les listes d’Oblivion.esm et/ou Archipel.esm) sans jamais avoir utilisé la fonction Copy et/ou Duplicate (ni non plus Ctrl+C et Ctrl+V) devront être sauvegardé avec ce plug-in en Mode Active.

Lorsque j’ai terminé la partie du Mod sur laquelle je travaille, il me suffira d’expédier ce fichier ainsi que Tous les fichiers additionnels que j’aurai créer dans une même archive à Walzou (si c’est lui qui s’occupe de la fusion). Après avoir expédié cette archive JE NE TOUCHERAI JAMAIS PLUS A CE FICHIER.

Walzou effectuera la fusion et m’expédiera dès lors un nouveau fichier Archipel_02.esm, que j’utiliserai à la place du précédent. Pour mes nouveaux additifs au nouveau fichier maître je recréerai un nouveau Plug-In blanc que je dénommerai :

Archipel_MH_Master_02.esp

Je vous invite d'ailleurs à venir en discuter Ici.