Il suffirait d'ajouter des informations sur ce que contient le .dup afin de ne pas avoir plusieurs fois les mêmes références pour un module donné (je ne sais pas s'il y a des conflits ?) un peu comme les rpm sous linux redhat et Mandrake (désolé pour tous ceux qui ne font que compiler leurs programme et qui n'utilisent pas cela).
Juste une question, peut t'on mettre un dialog.tlk dans un hakpak ?? Si ça marche, il suffirait de compiler ces infos en un hakpack pour le module à partir du dialog.tlk original qui lui, n'est pas modifié du tout. Il n'y aurait pas de risques de doublons et de fichiers beaucoup trop gros qui font planter un PC modeste (qui tourne nwn un peu juste quoi )
Ca a l'air très intéressant, je t'avouerais que l'idée de comparer chacune des chaînes ajoutées à celles qui sont déjà dans le module me fait un peu peur point de vue performance (euphémisme) . Mais j'ai rien compris... J'avais prévenu hein. Ajouter les informations ou ça?
Pour le tlk dans les fichiers hak, oui ça marche, mon idée repose en partie la-dessus, puisque les chaînes ajoutées le serait grace à un dialog.tlk (respectivement dialogF.tlk) mis dans le .dup (un .hak renommé). Le format tlk est plus perfectionné que ce dont j'ai besoin, mais est plus pratique à manipuler, et de loin, qu'un simple fichier texte. D'autant plus qu'à l'arrivée les entrées ajoutées doivent être au format tlk.
Skanzo: ta version serait beaucoup (beaucoup) plus simple à implémenter que ce que je suis en train de faire (je suis parti sur l'idée que le joueur peut "décompiler" plusieurs .dup à la fois, pour remettre toutes les infos d'un coup après chaque patch)
Néanmoins cela voudrait dire que le joueur doit changer de tlk à chaque fois qu'il change de module. De plus les lignes ajoutées à dialog.tlk (pour ce que tu veux faire le dup ne contiendrait que les tlk à ajouter en fait, pas besoin de hak "dynamique") pourrait devenir obsolète si l'index de la première StrRef ajoutée est ratrapé par les patchs de Bioware. Un autre truc est que l'on ne peut pas laisser de trou dans un tlk (un peu comme dans les 2da), donc il faut remplir avec des entrées vides, et étant donné le format cela a un coup en terme de poid du fichier, et de performance pour le parser. M'enfin si cette solution convient à tout le monde comme je le disais, c'est quand même beaucoup plus simple. L'interface pourrait même permettre de restaurer le fichier original/ changer de dialog.tlk customisé automatiquement je suppose.
Une précision: les seules entrées qui devraient avoir le format !<StrRef> dans les 2da seraient celles faisant référence au texte ajouté, donc il ne s'agit pas exactement de refaire les 2da en repartant de 1 (surtout pas en fait). !<StrRef> serait une référence relative, pour les lignes ajoutées à dialog.tlk, les références <StrRef> aux lignes Bioware, n'en serait pas moins valide, même dans la partie modifiée des 2da.
Hum une idée vient de me venir qui pourrait s'avérer plus efficace que ce que je suis en train de faire, bon ça veut dire qu'il faut que je refasse toute mon interface (sic, mais c'est pas grave):
1) le programme sauvegarde automatiquement dialog.tlk, permettant de le restaurer pour chaque patch.
2) on ne peut ajouter qu'un seul dup à la fois, quand on fait ceci: dialog.tlk est mis à jour ainsi qu'un fichier de sauvegarde des entrées ajoutées .
3) grâce à ce fichier de sauvegarde, on peut ré-ajouter toutes les lignes "custom" d'un coup à dialog.tlk après un patch, en même temps le programme parse tous les hakpaks dans le fichier \hak, et à chaque fois qu'il trouve une StrRef supérieure à la valeur de l'ancienne dernière entrée Bioware, il décale cette référence (du nombre d'entrée rajouté par le dernier patch Bioware) . Parser tous les hakpaks dans \hak et seulement cela c'est pas top, m'enfin...
Bon je suis désolé c'est encore moins compréhensible que la première fois...