Salut Cocrane
J'ai essayé la version 2.03. La barre de titre m'indique toujours 2.02 mais la version des propriétés Windows est bien 2.03 et les nouveaux menus ne laissent pas de place au doute.
J'ai repris la même installation que la dernière fois :
Chemin de l'éditeur : C:\Program Files\TeamBG IE MOD Tools\Editeur_Baldur_Gate\
Chemin des fichiers Temp : C:\Program Files\TeamBG IE MOD Tools\Editeur_Baldur_Gate\Tmp\
Chemin des fichiers MOD : F:\Tmp\Mod_Test_Editeur_BG\
Chemin WeiDU : C:\Program Files\TeamBG IE MOD Tools\WeiDU\
Racine du jeu BG : F:\Tmp\BGII BGT - Test\
Base de registre : F:\Program Files\Jeux\BGII - SoA\BGMain.exe
Le lancement s'est bien passé, du moins en apparence. Par contre, j'ai vu que quelque chose clochait toujours dès que j'ai ouvert la fenêtre des créatures : bien que mon installation désigne un environnement avec BGT, la créature ADDY.CRE (dont on a déjà parlé, propre à BGT) ne figurait pas dans la liste.
Problème confirmé par la vérification du fichier Liste_fichier_BG.txt, qui ne fait que 537 Ko au lieu des 614 Ko que j'obtiens en recréant la liste à la main avec WeiDU et où figure ADDY.CRE.
J'ai alors inversé les choses :
Racine du jeu BG : F:\Program Files\Jeux\BGII - SoA\
Base de registre : F:\Tmp\BGII BGT - Test\BGMain.exe
Après avoir relancé l'éditeur, j'obtiens alors une liste de 614 Ko, sauf qu'elle est plus complète que ce qui se trouve dans le répertoire désigné pour le jeu. Du coup, quand j'ouvre l'éditeur de créature et que je double-clique sur ADDY.CRE, j'obtiens une erreur à cause de l'absence du fichier dans le répertoire du jeu :
La nouvelle fenêtre "Test Weidu" de l'éditeur montre l'origine du problème.
J'ai essayé de surligner la présence d'un espace à la fin du chemin indiqué après --game dans la commande pour la liste de fichiers, mais ce n'est pas passé dans la capture d'écran. Tu pourras néanmoins vérifier sa présence en déplaçant le curseur dans la zone du texte.
Cet espace, absent sur la ligne relative aux créatures, explique pourquoi l'extraction de créature pointait bien sur mon installation de base de BG II dans mon essai.
L'absence de l'option --game sur la ligne de commande pour les dialogues m'a par contre inquiété. Son absence signifie que l'éditeur ne tient pas forcément compte du répertoire choisi par l'utilisateur, sauf dans des cas particuliers (installation de base de BG II ou WeiDU.exe placé dans le même répertoire). Pour en avoir le coeur net, j'ai remis la configuration initiale :
Racine du jeu BG : F:\Tmp\BGII BGT - Test\
Base de registre : F:\Program Files\Jeux\BGII - SoA\BGMain.exe
J'ai essayé d'afficher le dialogue ADDY.DLG, avec succès. Bien qu'il existe aussi dans BG II (un ménage mal fait par les développeurs, il reste beaucoup de fichiers BG dans BG II), les textes correspondants aux répliques ont été écrasés (tu peux le vérifier avec Near Infinity). Le fichier ADDY.d dans le répertoire temporaire montre bien que le fichier a été extrait à partir de la racine désignée du jeu, soit "F:\Tmp\BGII BGT - Test/DATA/BG1DLG.BIF" (fichier BIF de BGT).
Je suppose donc que les paramètres WeiDU affichés pour les dialogues dans la fenêtre Test Weidu ne sont représentatifs des options véritablement passés à WeiDU.
Remarque : j'ai fait un essai pour extraire un gros dialogue avec pleins de liens vers d'autres, en choisissant AERIEJ.DLG. L'extraction des dialogues liés entraîne l'ouverture de nombreuses fenêtres DOS et a dû durer une bonne minute sur ma machine. La façon dont c'est fait par l'éditeur est particulièrement pénible : la fenêtre WeiDU/DOS passe systématiquement au premier plan et capte le focus, ce qui interrompt systématiquement ce que je cherche à faire pour passer le temps (dans ce cas, il s'agissait de taper le début de ce message). Je ne sais pas si tu peux faire quelque chose pour éviter que l'exécution de la commande prenne le focus, mais cela rendrait l'éditeur moins pénible. De même, je pense que l'utilisateur lambda apprécierait de ne pas avoir ces ouvertures sporadiques de fenêtre WeiDU. Peut-être est-il possible avec WinDev de masquer la fenêtre, tout au moins de s'arranger pour qu'elle s'ouvre en arrière plan ?
Pour revenir au problème de chemin du jeu, j'ai l'impression que tu n'as pas tenu compte pour la commande de liste des fichiers de ce que j'avais indiqué dans ma conclusion précédente :
Je te propose de corriger le chemin passé de deux façons :
- en retirant le "\" à la fin du nom du chemin
- en t'assurant que tu n'ajoutes pas d'espace à la fin
J'ai pris le temps de creuser l'hypothèse que je t'avais exposée à propos de l'utilisation de l'option --biff-get.
Pour éviter tout problème de chemin, j'ai fixé un et un seul répertoire possible :
Racine du jeu BG : F:\Tmp\BGII BGT - Test\
Base de registre : F:\Tmp\BGII BGT - Test\BGMain.exe
Avec Near Infinity, j'ai créé une copie du fichier ABAZIGAL.CRE sous le nom ISAYA.CRE. Cette copie n'existe que dans le répertoire Override du jeu (F:\Tmp\BGII BGT - Test\Override).
Après avoir relancé l'éditeur, j'ai constaté que le fichier ISAYA.CRE n'apparaissait pas dans la liste des créatures. Après vérification, il n'apparaissait pas non plus dans le fichier Liste_fichier_BG.txt. De même, il n'apparaissait pas en exécutant la commande WeiDU --list-files à la main.
Après vérification de la documentation de WeiDU, l'explication est évidente. De même que --biff-get, --list-files ne traite que les fichiers inclus dans un fichier BIF. Ou plus exactement les fichiers référencés dans le fichier chitin.key, ce qui revient au même (à part quelques incohérences, dont celles, telles que XR2400.ARE qui existe dans chitin.key mais dans aucun fichier BIF, qui provoquent des messages d'erreurs quand on fait des recherches avec Near Infinity). Du coup les fichiers ajoutés par un patch officiel ou par un mod ne sont pas vus par l'éditeur.
De même les fichiers modifiés par un patch officiel ou un mod et qui existaient à l'origine dans un fichier BIF ne sont pas bien pris en charge par l'éditeur. En effet, au lieu de prendre la dernière version (celle du répertoire Override), l'extraction avec -biff-get va fournir la version présente dans le fichier BIF, donc la version non modifiée.
J'ai fait l'expérience avec des fichiers tels que HAER10.CRE, qui est présent dans le répertoire Override d'une installation de base de BGII + ToB + patch officiel. Le fichier que récupère l'éditeur dans le répertoire Tmp diffère de la version présente dans le répertoire Override. Pour ce fichier la différence ne saute pas aux yeux : la taille est la même ; mais en effectuant une comparaison binaire, on se rend compte qu'il y a bien des différences.
La différence est plus flagrante avec une installation avec le BG2Fixpack. Le fichier AERIE12.CRE présente une différente de taille de fichier entre la version extraite par l'éditeur dans le répertoire Tmp et la version présente dans le répertoire Override.
Ce comportement rend l'éditeur inutilisable pour visualiser des fichiers d'une installation du jeu ! Même une installation de base a toujours des fichiers dans le répertoire Override (déjà plus de 800 pour BGII - ToB). En conséquence, il est en l'état actuel inexploitable pour les travaux de traduction que j'avais évoqué.
Pour contourner cette restriction, il faudrait que l'éditeur adopte le même comportement que le jeu vis à vis des fichiers présents dans le répertoire Override. En pratique, il y a même d'autres répertoires dans lequel le moteur de jeu va vérifier s'il n'y a pas des surcharges des fichiers du jeu (voir
cette page d'IESDP) mais Override serait déjà suffisant, puisque c'est celui qu'utilisent les patchs officiels et les mods.
Le jeu et les autres éditeurs travaillent sur le principe suivant :
- la liste des fichiers du jeu constitue l'union des fichiers référencés dans le fichier chitin.key (contenus dans les fichiers BIF) et des fichiers présents dans le répertoire Override
- le fichier présent dans le répertoire Override a priorité sur celui du même nom présent dans un fichier BIF
Du point de vue de l'éditeur, il faudrait donc constituer la liste des fichiers en combinant la liste des fichiers obtenue avec --list-files et celle obtenue en référençant tous les fichiers du répertoire Override, et en éliminant les doublons.
Par la suite, quand l'éditeur veut obtenir un fichier, il faudrait qu'il vérifie si le fichier est présent dans le répertoire Override, auquel cas il lui suffit de le recopier dans son répertoire Tmp au lieu de l'extraire avec --biff-get. Si le fichier n'existe pas dans le répertoire Override, il suffit de l'extraire avec --biff-get.
Pour être plus efficace et éviter de vérifier la présence du fichier dans le répertoire Override à chaque fois au cours d'une session de l'éditeur, il suffirait de conserver en mémoire une table des noms de fichiers avec une indication de son emplacement (Override ou fichier BIF).
A titre d'exemple, c'est ainsi que procède l'éditeur de sauvegarde Shadow Keeper.
Le premier problème signalé (défaut de la liste de fichiers à cause du chemin avec espace à la fin) devrait être facile à corriger. En revanche établir la liste complète des fichiers en tenant compte de ceux du répertoire Override pourrait s'avérer un peu plus compliqué. En C, l'API Windows propose des fonctions pour établir la liste des fichiers d'un répertoire. J'imagine que WinDev propose quelque chose de similaire, peut-être même bien plus simple d'utilisation. Quant aux fonctions permettant d'éliminer les doublons entre les fichiers référencés dans chitin.key et ceux du répertoire Override, je suppose que WinDev doit aussi proposer quelque chose. Reste à trouver comment s'y prendre. Dans le pire des cas, il s'agit d'un tri alphabétique, suivi d'une vérification de la présence d'un voisin de même nom, que l'on élimine ensuite. Le principal inconvénient est le temps nécessaire pour le faire.
J'ai constaté que la désinstallation laissait toujours la quasi-totalité des fichiers (DLL, fichiers divers de l'installation, fichiers créés à l'exécution) dans le répertoire d'installation. Tu n'as pas peut-être pas travaillé là-dessus. Il est vrai que ce n'est pas prioritaire.
Je suis à ta disposition pour plus de précisions et pour continuer à tester les évolutions de l'éditeur. Si tu le souhaites, nous pourrions discuter directement par mail, pour faciliter les échanges de fichiers notamment.
Félicitations pour le travail acharné et les avancées récentes, même si elles ne sont pas encore toutes exploitables. Bon courage.