[CRE] Comment modifier un fichier CRE avec NearInfinity ?

[Medji]

Bon, je me lance. (Pour ce que ma vie n'intéresse pas éviter le spoiler.)

► Afficher le texte

Comme tout fan de BG qui se respecte (sors une édition de bg1 5 cd dont la pochette en carton fait pale figure ) J'ai immédiatement bondit sur le pack bg1 bg2+ TOB en dvd lorsque je suis tomber dessus par pur hasard cet été
J'ai donc ressortit ma vielle disquette, déterrer mon cher conjurateur avant d'affronter les périples de BG2 et de TOB, le tout dans la joie la bonne humeur et une bonne dose de rire. Finalement le temps passant, même cet excellent jeu devenait un poil monotone, même en variant RP et équipe au final on finit par avoir a peu près fait le tour.
J'ai donc chercher sur internet de quoi raviver la flamme de ma passion pour ce jeu. Et la surprise des mods en tout genre grouillaient finalement a coter de mes yeux.
D'ailleurs je remercie grenouillebleu pour son remarquable travail et pour le temps que j'ai pus passer a fouiner dans son mod :kim (mon préféré ) (J'attendrai le prochain avec impatience )
Bien sur la j'ai tout de suite pensé, mais si un autre peux faire un si bon travail pourquoi pas moi !
Je fouine donc dans ce site tente de suivre quelques conseils et commence a bidouiller un NPC seul dans mon coin, autant dire que j'ai pas réussit grand chose, en fait je dirai même que j'ai juste rien pu faire
J'ai donc continuer de fouiller pour trouver une recette plus ou moins déjà faite miracle!! elle existe bien dans le forum je suis donc les conseils télécharge les bons marteaux pour bien forgé mon squelette de NPC bricole un dialogue, prépare le NPC réfléchit a son caractère ses réactions deux trois trucs pour démarrer.
Je jette un oeil a la 'programmation' qui me parait riche en prise de tête, en larme, en sueur, et en futur crise de nerf "ca promet d'être intéressant" ai je penser

Alors que je suivait la recette d'un bon gâteau avec une pâte déjà faite (un NPCéclair vous l'aurais compris ) c'est le drame impossible d'ouvrir un fichier .cre avec Near Infinity.
Première réaction > j'ai pas télécharger le bon, je vais tenter l'autre
Hélas aucun changement
Deuxième réaction > Mon fichier n'est pas bien créer pour X raison je vais essayer un autre .CRE
Toujours rien
Troisième réaction > Bon je pense pas être le premier a mes casser les dents la dessus je vais voir sur le forum si quelqu'un n'a pas un problème similaire.
Il y a bien un problème similaire, mais la personne ne dit pas comment elle est parvenue a le régler
Je continue donc de fouiller cherche un tutorial miracle mais rien ne me tombe dans le bec. J'ai tenter plusieurs manipulation avec NearInfinity et sa version beta et tout ce que j'obtiens c'est ce message d'erreur

>Unsuported keyfile: C:\Program files\Black Isle\BGII\override\test.cre

en fait je n'arrive pas a ouvrir quoi que ce soit avec NI

Je demande donc de l'aide pour m'aider a ressoudre ce petit problème de marteau

[Isaya]

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.

[Medji]

merci pour l'explication j'ai pu comprendre comment utiliser NI (Le reste viendra petit a petit je pense)
Et voila les nouveaux problèmes que je rencontre

Si je suis la recette tout s'emboite parfaitement pendant l'edit, puis vient le premier problème, je ne trouve pas la death variable dans la liste, j'ai un peu fouiller mais sans succès, porte t elle un autre nom ou me faut il me paire de lunette ?

Deuxième problème le fichier .D ne semble pas correspondre a celui demander .DLG (apparition en gris sous l'image du personnage)
Les deux sont ils différents ou bien ai je mal compris la recette ?
Après avoir un peu regarder j'ai cru comprendre que le .D servait pour le regroupement des dialogues du NPC et le .DLG pour celui du 'recrutement' (Aie ca sonne faux comme mot)
Idem pour le ficher .BAF il n'est pas 'reconnu' lui aussi > Une erreur de frappe de ma part?

Et pour finir l'image n'apparait plus une fois que j'ai changer les nom > temporaire ou bien une troisième erreur de ma part ?

Je pose pas mal de question mais bon j'ai pas inventer l'eau chaude

[Isaya]

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 ?

[Medji]

Encore merci pour ces informations tres claires.

L'image dont je parle est le 'portrait' du NPC, j'entre le nouveau nom d'image et l'ancien portrait présent sur la page du fichier .cre d'origine disparait, sans que le nouveau portrait prenne sa place.

Je me base sur ce tutoriel la > .baldursgateworld.fr/lacouronne/les-outils/15077-tutorial-tuto-npc.html (pas encore les 5 messages pour mettre un lien on dirait)

[Isaya]

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.

[Medji]

Bon grâce a tes conseils je pense avancer sur la bonne voie (on verra bien lors de l'essai )

Reste encore pas mal de question.

il est donc possible de passer d'un fichier D à un fichier DLG, mais aussi l'inverse.
J'utilise Weidu pour la décompilation on bien le programme sert juste a convertir mes DLG en binaire utilisable par BG ?

Ensuite vers la fin du totorial il y a ce petit morceaux qui me chiffone >

BEGIN ~The NPC~ //ce que vous voulez


Ce que je veux ? ca correspond a mes documents créer ou ca sert que pour le .tp2?

COMPILE ~lenomdudossier\lenomdusousdossier\lenomdufichierdialogue.d~


Je dois compilé mes .DLG pour faire le .D réclamé?


//Pour ce qui suit c'est pour lier les différents fichiers dialogues entre eux
APPEND~pdialog.2da~
~TheNPC TheNPCP TheNPCJ TheNPCD TheNPC25P TheNPC25J TheNPC25D TheNPC25~
UNLESS~TheNPC~ // UNLESS sauf si TheNPC n'est pas présent

LA j'avoue je seche un peu, c'est quoi ces 25 ?

APPEND~interdia.2Da~
~TheNPC TheNPCB TheNPCB25~
UNLESS~TheNPC~
//d'après Isaya y'a un truc qui cloche ici mais je ne sais pas ce que c'est.

et question ca cloche la, peut être mais pourquoi ?

[Isaya]

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.

[Medji]

Bien, me voici donc munie
d'un fichier .CRE pour le npc
- 4 fichier .D MO#Ori (B,P,J)
+les 4 25 (vide pour le moment)
- deux portraits théoriquement bon
- Un .tp2 et le setup weidu du meme nom
- Un dossier backup
- le fichier .Baf pour le script reconnaissance du perso et un autre pour ajouter le pnc sur une map

seulement petit hic l'installation ne marche pas. Je fouine sur un autre mod deja creer pour cherche d'où viens l'erreur et je pense que c'est celle la :

Code : Tout sélectionner

//Identité
BACKUP ~OriginNPC\backup~
AUTHOR ~Medji > mederic.berton@gmail.com~

//Instalation
BEGIN ~Origin~

//Extension oblige
REQUIRE_FILE ~Data/25Dialog.bif~ ~You do not appear to have TOB installed.~~

//Ajout des creatures
COPY ~OriginNPC\Creature\MO#ORI.cre~ ~override\MO#ORI.cre~
SAY NAME1 ~Origin~ //ce sont les noms de votre perso
SAY NAME2 ~Origin~
SAY BIO ~ Test de bio~ // là c'est pour la bio du perso

//Ajout des images
COPY ~OriginNPC\Images\Ori1M.bmp~ ~override\Ori1M.bmp~ //ça c'est pour le grand portrait
COPY ~OriginNPC\Images\Ori1S.bmp~ ~override\Ori1S.bmp~ //votre deuxième image

//Script
COMPILE ~OriginNPC\Script\MO#See.baf~
USING ~~

//Dialogues
COMPILE ~OriginNPC\Script\MO#OriD.d~
COMPILE ~OriginNPC\Script\MO#OriJ.d~
COMPILE ~OriginNPC\Script\MO#OriP.d~
COMPILE ~OriginNPC\Script\BMO#Ori.d~

[color="DarkRed"]EXTEND_TOP ~Ar0710.bcs~ ~OriginNPC\Script\MO#Cre.baf~ //c'est pour ajouter votre script à la zone et créé votre perso[/color]

//Pour ce qui suit c'est pour lier les différents fichiers dialogues entre eux
APPEND~pdialog.2da~
~MO#Ori MO#OriP MO#OriJ MO#OriD MO#O25P MO#O25J MO#O25D MO#O25~
UNLESS~MO#ORI~ // UNLESS sauf si TheNPC n'est pas présent

APPEND~interdia.2Da~
~MO#Ori BMO#Ori BMO#O25~
UNLESS~MO#ORI~

Dans les autres mod il semblerait que le fichier soit completement different, il faut un fichier de quel type, un baf comme le mien ou non?
Ou alors l'erreur est autre part je vais reecrire le message d'erreur:

Code : Tout sélectionner

[Setup-Origin.TP2] Parse error at line 7 column 7-15
Next Text: OriginNPC
syntaxe error

[Setup-Origin.TP2] Parse error at line 7 column 7-15
Next Text: OriginNPC
parsing.parse_error 
ERROR :p arsing[Setup-Origin.TP2] : Parsing parse error
ERROR :p robleme parsing TP file[Setup-Origin.TP2]: Parsing parse error

FATAL ERROR : Parsing.Parse_error

Hum comment dire: Help?

[Isaya]

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.