La Couronne de Cuivre

Le problème que tu rencontres vient du fait que NearInfinity ne fonctionne pas comme tu t'y attends. Je vais tâcher de te décrire sommairement comment t'en servir.

NearInfinity est avant tout un explorateur de fichiers, restreint aux fichiers du jeu.
Les fichiers en question sont répartis dans plusieurs sous-répertoires du répertoire d'installation du jeu. Parmi les plus remarquables figurent les fichiers BIF et le fichier chitin.key. Ils n'apparaissent pas dans l'arborescence montrée par NearInfinity mais sont pourtant au centre de tout.
Les fichiers BIF (et aussi CBF dans Icewind Dale) sont des archives semblables à des fichiers zip, compressés ou non, qui contiennent la plupart des fichiers utilisés par le jeu (CRE, DLG, ITM, ...). Le fichier chitin.key est le catalogue qui permet au jeu et à NearInfinity de retrouver les fichiers CRE, DLG, ... dans ces fichiers BIF.
Les fichiers BIF se trouvent dans le sous-répertoire Data du répertoire d'installation et dans les sous-répertoires Data des CD1, CD2, ... Le fichier chitin.key est dans le répertoire du jeu.

Le moteur de jeu Infinity Engine exploite aussi d'autres sous-répertoires.
Le plus remarquable est Override. A l'origine les concepteurs l'ont prévu comme un moyen de corriger des bugs dans les fichiers archivés dans les fichiers BIF. En mettant dans ce répertoire un fichier, par exemple CRE, portant le même nom qu'un de ceux présents dans les fichiers BIF, le jeu va utiliser le fichier présent dans le répertoire Override à la place de celui figurant dans un fichier BIF. Ainsi la version du répertoire Override peut corriger un défaut de l'original.
De son côté le répertoire Music contient les définitions des musiques du jeu. Portraits et Sounds permettent d'ajouter des portraits ou des doublages sonores. Ils servent aussi de répertoires Override "secondaires", de sorte que si un fichier de même nom qu'un de ceux présents dans les fichiers BIF y est placé, c'est la version du répertoire Portraits ou Sounds qui sera choisie par le jeu.

Pour revenir à NearInfinity, il s'agit surtout de comprendre que ce programme s'appuie sur cette façon de fonctionner du moteur de jeu Infinity Engine. Autrement dit, NearInfinity est capable de montrer le contenu des fichiers BIF, classés par catégories de fichier (CRE, DLG, ...). Il recherche les fichiers uniquement dans les fichiers BIF, grâce au catalogue que constitue le fichier chitin.key, ainsi que dans les autres répertoires exploités par le moteur de jeu Infinity Engine (Music, Override, ...). Mais il s'arrête là, c'est à dire que tu ne peux pas lui demander de te montrer un fichier CRE qui ne serait pas dans un de ces répertoires !

Quand on place le programme NearInfinity en dehors du répertoire d'un jeu, il ne sait pas dans quel environnement travailler. Il demande alors à ce qu'on lui indique le fichier chitin.key, ce qui lui permet de savoir dans quel répertoire est le jeu. Il pourra alors afficher l'arborescence des fichiers sous forme d'explorateur.
Quand on copie NearInfinity dans le répertoire d'un jeu Infinity Engine, il y trouve automatiquement le fichier chitin.key et peut tout de suite afficher l'arborescence des fichiers du jeu.
NearInfinity peut adopter plusieurs comportements pour ce qui concerne le classement des fichiers présents dans le répertoire Override. Il peut les montrer à part des autres fichiers ou au milieu les fichiers de même type. Pour ma part, je préfère la seconde option. Le choix s'effectue par les différentes options du menu "Options" -> "Show Override Files".

NearInfinity a deux fonctions principales : visualiser les fichiers du jeu et, pour la plupart d'entre eux, les modifier.
La fonction de base est la visualisation. Pour accéder à l'édition, il faut généralement basculer sur l'onglet "Edit" quand on se trouve sur l'écran de visualisation du contenu d'un fichier.
Quand on modifie un fichier, NearInfinity l'enregistre par défaut dans le répertoire Override du jeu. Si le fichier s'y trouve déjà, NearInfinity va le signaler et proposer de l'écraser. Si ce n'est pas un fichier que tu as déjà modifié toi-même, il s'agit d'un fichier provenant d'un patch et il vaut mieux alors le mettre de côté avant d'accepter de l'écraser, de façon à pouvoir revenir à la version initiale.

NearInfinity propose une fonction Export pour certains types de fichiers, qui permet alors de l'enregistrer où on le souhaite, notamment en dehors du répertoire Override. Ceci permet notamment de récupérer sous forme de fichier séparé un fichier présent uniquement dans un fichier BIF, donc inaccessible par l'explorateur Windows.

Pour ce qui concerne tes propres créations, la méthode la plus simple consiste à d'abord mettre les fichiers dans le répertoire Override afin que NearInfinity les fasse apparaître dans sa liste. Si NearInfinity est déjà en train de tourner, il faut penser à lui indiquer de rafraîchir l'arborescence (menu "Game" -> "Refresh Tree") après avoir copié les fichiers, ou bien quitter et relancer le programme.
L'autre possibilité est d'utiliser le menu "Game" -> "Open File..." et de lui indiquer le fichier en question. La limitation de cette méthode est qu'elle ne permettra pas de passer facilement aux autres fichiers liés. Par exemple, si tu as créé un objet et placé dans l'inventaire d'un personnage que tu as aussi créé, tu ne pourras exploiter la capacité de passer de l'inventaire du personnage à l'objet via l'interface de Near Infinity (sans lui demander explicitement d'ouvrir le fichier).

J'espère t'avoir ouvert la voie. Si tu as d'autres questions, n'hésite pas.

Le moteur de jeu et NearInfinity manipulent des fichiers qui emploient généralement un format binaire, illisible par un humain sans un outil de visualisation tel que NearInfinity.

Fichier BAF

Un fichier BAF est un fichier "source" pour les scripts, qui portent l'extension BCS sous forme "compilée".
Bioware fournit avec le jeu, dans le répertoire "script compiler", un outil (AICompile.exe) initialement pour permettre au joueur de créer des scripts de comportement pour les personnages de l'équipe, en complément de ceux fournis d'origine par le jeu pour l'IA des personnages du groupe. Ces fichiers script pour personnage, qui utilisent l'extension .BS, se trouvent à l'origine dans le répertoire "scripts" et c'est là qu'il faut aussi mettre les fichiers que l'on crée pour qu'ils deviennent disponibles dans l'interface de personnalisation du comportement d'un personnage dans le jeu.
Mais en fin de compte, les fichiers de comportement utilisés par tous les personnages du jeu sont eux-aussi basés sur le même genre de fichier, auquel Bioware a arbitrairement donné l'extension .BCS. Mais en pratique ils ont identiques à 100% avec les fichiers .BS. On peut donc aussi les écrire sous forme de fichiers .BAF et les compiler avec le compilateur fourni par Bioware.
L'auteur de WeiDU, l'outil utilisé pour installer des mods, a "simplement" complètement réécrit un compilateur de fichier .BAF en .BCS. Il a aussi fourni un "décompilateur", pour faire l'opération inverse et obtenir un fichier .BAF à partir d'un fichier .BCS.
Sache que NearInfinity possède lui aussi son propre compilateur/décompilateur, même s'ils sont différents mais produisent probablement les mêmes résultats. C'est d'ailleurs le résultat du décompilateur que tu observes quand tu demandes à NearInfinity de te montrer un fichier BCS. Tu peux aussi t'amuser à jeter un coup d’œil à la version binaire dans l'onglet "Script code".


Fichier D et DLG

En ce qui concerne les fichiers D et DLG, c'est un peu le même principe. Le fichier DLG manipulé par le jeu est un fichier binaire.
L'auteur de WeiDU a conçu une sorte de langage informatique dédié aux fichiers dialogue permettant d'écrire sous forme plus lisible les différentes interactions d'un dialogue avec un personnage. Cet aspect de l'outil fonctionne de façon semblable au processus de compilation/décompilation des scripts et il est donc possible de passer d'un fichier D à un fichier DLG, mais aussi l'inverse. Mais, contrairement aux scripts (dans la plupart des cas), le processus de décompilation ne permet pas forcément de revenir à l'original (voir ci-dessous).
L'auteur de WeiDU a également enrichi son langage d'instructions permettant d'insérer des répliques dans un dialogue existant. C'est ce qui permet de créer un personnage et de le faire interagir avec les autres personnages du jeu. On construit alors juste un ajout au dialogue, pas un dialogue complet. Ce sont ces capacités qui rendent le processus de décompilation non symétrique de la compilation, car il n'y a pas de moyen de n'obtenir par décompilation que la partie ajoutée (on obtient le dialogue complet, original + ajout).
Les fichiers scripts ont aussi cette capacité d'ajout ou de modification, via les commandes EXTEND_BOTTOM, EXTEND_TOP ou REPLACE/REPLACE_TEXTUALLY notamment. Cet aspect-là n'est pas non plus restitué en cas de décompilation (on récupère le résultat complet, original + modification).

Parmi les autres particularités du couple D/DLG par rapport à BAF/BCS, il faut savoir que si un fichier .BAF correspond toujours à un fichier .BCS et un seul (création complète ou ajout/modification d'un existant), un fichier .D peut parfaitement avoir des répercutions dans plusieurs fichiers .DLG ou bien il peut y avoir plusieurs fichiers .D qui créent et modifient un seul et même fichier .DLG. Tu peux donc mettre dans un seul et même fichier .D des instructions pour créer plusieurs fichiers .DLG (les classiques xxxD.DLG, xxxP.DLG, xxxJ.DLG et Bxxx.DLG pour un personnage recrutable) ou bien encore faire une multitude de fichiers .D pour ces mêmes quatre fichiers .DLG.
A multitude de solutions, multitude de pratiques. Il semble que chaque moddeur ait sa façon personnelle de faire sur ce point. Tu trouveras donc des exemples différents en consultant les mods existants.
Les préfixes et suffixes classques, xxxD.DLG, xxxP.DLG, xxxJ.DLG et Bxxx.DLG, ne sont pas obligatoires mais il vaut mieux les respecter pour une meilleure lisibilité :

• xxxD.DLG : généralement les premiers échanges avec le joueur qui précèdent la possibilité de recruter le personnage
• xxxP.DLG : "Party", échanges au moment où on vire le personnage ou lorsqu'on vient le recruter de nouveau
• xxxJ.DLG : "Joined", interactions du personnage avec le joueur ou ses interventions dans les dialogues avec les personnages de l'intrigue ("ne lui fais confiance...", ...)
• Bxxx.DLG : "Banter", ou bavardages entre les membres du groupe

Le terme de "death variable" a été longtemps employé abusivement pour désigner le "nom unique" attribué au personnage, indépendamment du nom du personnage tel qu'il est affiché par le jeu ou employé dans les dialogues. L'abus vient du fait que c'est ce "nom unique" qui est employé par le jeu pour garder trace de la mort du personnage par l'intermédiaire des variables SPRITE_IS_DEADxxx que l'on retrouve dans les sauvegardes quand on les édite avec Shadow Keeper ou NearInfinity.
Certains éditeurs récents, tels que la version 1.33 beta 18 de Near Infinity utilisent désormais le terme de "script name" pour désigner ce "nom unique". En effet, il sert aussi dans les scripts de comporter pour désigner le personnage et le faire agir.


En ce qui concerne la question d'image, je n'ai pas compris à quoi tu faisais référence. Celle attribué au personnage ? De quel changement de nom parles-tu ?
Le mieux serait que tu cites explicitement, en indiquant un lien, sur quelles "recettes" tu te bases. Un tutoriel ? Si oui, lequel ou lesquels ?

Le portrait affiché par Near Infinity est le "large portrait". Pour qu'il apparaisse, il faut que le portrait respecte les contraintes imposées par le jeu, qui sont indiqués dans le fichier readme.txt dans le répertoire du jeu. Notamment sur le nombre de couleurs. J'ai eu la mauvaise surprise de constater que le Paint de Windows XP écrivait des images BMP en 32 bits quand on lui demande de le faire en 24 bits et Near Infinity n'apprécie pas.

A notre rythme actuel, tu auras vite les 5 messages nécessaires pour poster un lien.
Je vais jeter un coup d'oeil à ce tutoriel de façon à être sur la même longueur d'onde. Mais pas avant demain.

Bonne continuation.

WeiDU permet effectivement de transformer dans les deux sens : .D -> .DLG (compiler) ou .DLG -> .D (décompiler). WeiDU peut s'utiliser en ligne de commande pour ce genre de choses. Pour se servir de WeiDU de cette manière, je te suggère de copier l'exécutable weidu.exe dans le répertoire du jeu. Tout comme pour Near Infinity, WeiDU saura alors que tu veux travailler sur le jeu qui s'y trouve.
L'utilisation est simple : WeiDU détermine grâce à l'extension du fichier que tu lui indiques quelle est l'opération que tu veux faire et génère dans le répertoire courant un fichier portant le même nom que celui indiqué mais avec l'extension résultante. Exemple :

weidu Jaheira.DLG : provoque la décompilation et la création de Jaheira.D dans le répertoire courant
weidu Jaheira.D : provoque la compilation et la création de Jaheira.DLG dans le répertoire courant
weidu Jaheira.BCS : provoque la décompilation et la création de Jaheira.BAF dans le répertoire courant
weidu Jaheira.BAF : provoque la compilation et la création de Jaheira.BCS dans le répertoire courant

Je te mets en garde contre l'idée de recompiler un fichier .D obtenue par une décompilation. Vu la façon dont WeiDU crée le fichier .D (avec des références en dur sur des numéros de texte dans le fichier dialog.tlk actuel, sous la forme #900), la recompilation ne donnera de bons résultats en terme de texte des répliques que dans des cas très rares. La décompilation est utile pour étudier des dialogues mais il ne faut pas exploiter les fichiers .D résultants sans les modifier lourdement à cause de cette question de références en dur.
Pour palier ce problème de références en dur, le plus simple est d'utiliser la commande suivante :

weidu --trans Jaheira.DLG : provoque la décompilation et la création de Jaheira.D et Jaheira.TRA dans le répertoire courant

Mais en pratique, l'intérêt de décompiler un dialogue existant sous une forme utilisable pour l'intégrer dans ton mod me semble bien faible. A part la perte du fichier .D d'origine pour un fichier .DLG de ton mod, je ne vois pas vraiment d'usage.

Il y a longtemps, j'avais écrit un tutoriel plutôt destiné à la traduction de mods dans lequel j'avais montré ce qu'on pouvait obtenir en décompilant un dialogue pour obtenir un fichier .D. Le but était, pour la traduction, d'obtenir le flux des répliques en lisant la structure du dialogue. Tu peux y jeter un coup d'oeil par curiosité, même si tu n'y trouveras pas beaucoup d'informations exploitables pour la création de mods.

Le fichier TP2 constitue à la fois la carte d'identité et la procédure d'installation du mod.

Les premières lignes indiquent l'auteur et le nom du mod. La syntaxe BEGIN ~Blabla~ du début du fichier TP2 définit le nom du mod. Ici il s'agit bel et bien d'un nom libre. Tu peux le nommer ~Les aventures de Medji au pays du modding BG~ si ça te chante. C'est tout simplement le nom qui va apparaître au joueur au moment où il va installer le mod et que WeiDU demande de confirmer qu'on veut installer ou désinstaller le mod.

Comme le fichier TP2 constitue la procédure d'installation, il doit indiquer quels sont les fichiers qu'il faut copier (CRE, ITM, BMP, ...) dans le répertoire Override, quels fichiers il faut compiler (D, BAF) pour obtenir les DLG et BCS qui sont ce que le jeu sait traiter et enfin quels autres fichiers communs du jeu (par exemple certains fichiers 2DA) il faut modifier pour que le mod s'intègre dans le jeu.
Les instructions de type COMPILE sur un fichier .D ont le même effet que le fait de lancer "weidu fichier.D" dans la ligne de commande. C'est la forme qu'il faut utiliser au sein du fichier TP2.
Pour les fichiers BAF, il faut utiliser COMPILE pour les fichiers BCS à créer intégralement (par exemple, le script de comportement du personnage). Pour le script qui ajoute le personnage dans une zone particulière, il faut par contre ajouter un morceau de script et non écraser le script existant de la zone, ce qui se fait avec les instructions EXTEND_BOTTOM ou EXTEND_TOP.

J'évoquais ci-dessus des fichiers communs du jeu qu'il faut modifier pour que ton PNJ s'intègre dans le jeu. Les fichiers pdialog.2da et interdia.2da en font partie.
Le premier définit pour chaque PNJ le nom des fichiers DLG qui s'appliquent dans des conditions clairement identifiées de la vie du personnage : les répliques pour virer ou reprendre le PNJ dans le groupe (xxxP.DLG), ses répliques quand il est dans le groupe (xxxJ.DLG), le dialogue initial avant le recrutement (xxxD.DLG).

~TheNPC TheNPCP TheNPCJ TheNPCD TheNPC25P TheNPC25J TheNPC25D TheNPC25~

La première colonne concerne le "script name" (ou "death variable") qui identifie de façon unique le personnage (défini dans le fichier CRE). La dernière colonne définit le script (BCS) qu'il faut affecter au personnage lorsqu'il est rappelé depuis l'antichambre dans Throne of Bhaal. Il permet de faire des actions particulières à ce moment-là. Pour les personnages d'origine Bioware, c'est là que le jeu leur change certains doublages sonores pour la sélection ou des actions. Les "25" sont des suffixes couramment utilisés dans le jeu pour identifier des éléments propres à Throne of Bhaal. Comme ce n'était pas à proprement parler BG III mais tout de même une suite, ils l'ont appelé BG 2.5, ce qui a donné ce préfixe ou suffixe dans beaucoup de fichiers du jeu. Ici il s'agit de bien séparer les dialogues pour les deux parties du jeu de façon à ce qu'on dise au PNJ d'attendre dans l'antichambre et non à la Couronne de Cuivre quand on veut se séparer de lui, par exemple.

:!: La syntaxe de l'exemple présente une erreur à éviter : dans l'Infinity Engine, tous les noms de fichiers (sans l'extension) doivent se limiter à 8 caractères maximum ! Bref un nom tel que "TheNPC25D" est trop long !

Xena avait mis un commentaire sur la dernière partie faisant référence à un commentaire de ma part qu'elle n'avait pas compris. Il s'agissait de ce problème de nom trop long (TheNPCB25). Et aussi du fait que pour les deux fichiers 2DA, il existe deux formes selon que le joueur a ou non Throne of Bhaal. Si le mod nécessite ToB, comme dans l'exemple, c'est bon. Sinon, il vaut mieux s'inspirer que la façon de faire du mod Tashia, que j'ai indiquée dans le sujet, afin d'écrire sous la forme appropriée pour Shadows of Amn seul.

En général les indications de numéro de ligne et éventuellement de colonne que donne WeiDU sont très utiles pour trouver l'origine d'un problème.

Ici on t'indique la ligne 7. Le numéro de colonne n'est probablement pas bon. En pratique, l'erreur se situe probablement à la fin de la ligne en question. Il y a deux fois le symbole ~ alors qu'il ne le faudrait qu'une fois.
Les erreurs de manque ou d'excès de ce caractère ~ sont extrêmement fréquentes quand on travaille avec un éditeur qui ne connaît pas la syntaxe des fichiers TP2, BAF, ou D. Des créateurs de mods ont écrit des fichiers de configuration de langage pour utilisation avec certains éditeurs de texte. Ils favorisent la création de mod en surlignant les mots-clés du langage ainsi que les textes entre ~~. Ainsi on distingue assez facilement quand il manque un caractère ~ par les problèmes de surlignage que cela occasionne.
Tu trouveras des fichiers de configuration ainsi que les éditeurs concernés sur cette page. Il existe aussi des fichiers équivalents pour PSPad. Personnellement j'utilise Notepad++ avec des fichiers de configuration que je me suis créés, mais ils sont loin d'être aussi complets (je m'en sers pour un usage plus limité, la traduction principalement).

En ce qui concerne la ligne que tu soupçonnais, il n'y a rien à redire a priori. L'emploi d'un fichier BAF est le plus courant pour ce qui concerne les ajouts à un script existant, ici celui d'une zone. Certains mods utilisent des fichiers BCS, donc déjà compilés, mais il doit s'agir de mods assez anciens, pour la plupart. Le fichier BAF est lisible, donc plus pratique.