[Sire Pom-pom]

Certains d'entre vous ont suivi mon histoire de programme qui ajoute des entrées à dialog.tlk et éventuellement dialogF.tlk, et produit un hakpack utilisant ces entrées. Pour pouvoir l'utiliser le concepteur du module devra distribuer
1) un fichier <nom_du_module>.dup, un hakpack renommé, dans lequel il aura mis tous les fichiers (2da, .set...) faisant référence à ces entrées ajoutées, via une notation particulière.
2) un fichier <nom_du_module>.tlm, un tlk renommé, contenant les entrées à rajouter à dialog.tlk, et en l'absence d'un fichier .tlf à dialogF.tlk si l'utilisateur a les deux. Et donc éventuellement un fichier <nom_du_module>.tlf, s'il veut ajouter des entrées différentes à dialog.tlk et à dialogF.tlk.

Pour l'instant, mon programme cherche ces fichiers dans le répertoire .\hak, cela peut faire un paquet de fichier dans ce répertoire, surtout pour les créateurs de modules, qui sont susceptibles d'avoir de nombreux hak, pensez-vous donc qu'il vaudrait mieux utiliser un répertoire à part?

EDIT: m'enfin que fout ce "Voilà" dans mon titre?

[Sire Pom-pom]

Une question, je ne me trompe pas les noms de modules et de hak sont limités à 16 caractères non?

[Jaha Effect]

Pour les nom de modules, il ne sont pas limité a 16 par contre, pour les hak je sais pas.
Et oui un répertoire à pars serait pas mal car mon fichier hak est monstrueux et je pense ne pas être seul dans ce cas là.

Jaha Effect

[Sire Pom-pom]

Merci Jaha, les noms de module je sais pas où j'ai été pêcher ça . Les nom de haks par contre je ne m'étais pas trompé. J'ai un dilemme: le .dup le .tlf et le .tlm doivent avoir le même nom que le module pour y être associé, du coup, soit j'ignore la limite, et il faudra les renommer à la main, soit je tronque le nom du module à 16 caractères, ça c'est pas compliqué, mais ça va faire des noms de fichiers bizarres, et cela introduit même une possibilité de conflit supplémentaire (pour deux modules s'appelant 0123456789012345a et 0123456789012345b) ... Qu'en pensez vous? Il y aurait une autre solution qui serait d'aller pêcher dans la description du module le nom des fichier Dup, tlk et tlm associé, simulant ainsi une association à la manière des fichier hak. C'est comme cela que je compte procéder pour ce qui est du nom du hak généré à partir du Dup: si la description du dup commence par [<nom>] c'est <nom> (maximum 16 caractères) qui sera utilisé, sinon ce sera le nom du Dup lui-même. Ceci dit ça me fait un peu suer d'ouvrir un fichier de plus, celui du module...

A propos du répertoire, au premier lancement du programme, je crée déjà un sous répertoire NWN\Dup où je mets mon fichier d'initialisation et les sauvegardes des tlk de base, ça vous irait comme emplacement? Du coup ce serait mieux si mon programme s'installait, pour l'instant, à chaque lancement il vérifie que ce répertoire existe, c'est un peu excessif je l'admets . Mais je n'ai acune idée de la façon de procéder...

[Jaha Effect]

Personnellement ça me dérange pas d'être limité a 16 caractères pour les noms de module car le PUMA ne m'en autorise que 8 donc pas de bouleversement notable à ce niveau
Par contre, en ce qui concerne le fait que le hak doit porter le même nom que le module, je crois que tu va avoir un petit problème.
Je m'explique, depuis le multi-hak, beaucoup de gens on décidé de placer un 2DA par hak (un hak pour les créatures, un hak pour les tileset...) ce qui leur permet juste de mettre a jour la partie du hak qui les intéresse et réduire le temps de téléchargement pour une petite mise à jour.
Hors si tu est limité a avoir le même nom pour le hak et le mod, ça limite le nombre de hak à 1, si tu vois ce que je veux dire.

Jaha Effect

[Sire Pom-pom]

Le hak généré ne contient que les 2da (et éventuellement .set...) qui référencent les chaînes ajoutées à dialog.tlk, cela n'empêche pas d'avoir d'autre hak pour le module. De toute façon je crois que je vais faire le coup de la description pour le nom du Dup et des tlf et tlm, par contre je ne le referais pas pour le hak généré parce que là on toucherait au ridicule je pense .
Bon je vais expliquer un peu le principe, de toute façon il faudra bien que je le fasse un jour j'espère, et cela me mettra les idées au clair.
Quand mon programme sera lancé la liste des modules présents dans le répertoire mod s'affichera.
L'utilisateur choisira un module, le programme ouvrira le module, et s'il trouve une description (la première a priori) commençant par [<un nom de 16 caractères ou moins>] il saura qu'il a affaire à un module utilisant un tlk custom.
[jusque là c'était la partie interface qui n'est pas encore en place]
Dans ce cas il va chercher le tlm et éventuellement le tlf de nom indiqué dans la description du module et ajoute leurs entrées à dialog.tlk respectivement dialogF.tlk qu'il a préalablement sauvegardé das le répertoire \Dup, mettant les fichiers résultants dans le répertoire \NWN. La bonne nouvelle c'est que cette opération prend environ une seconde même si les tlks customs sont en fait dialog.tlk et dialogF.tlk, qui sont évidemment plus lourds que ceux qui devraient être utilisés, normalement.
[à partir de maintenant c'est en cour]
Ensuite il regarde dans un ini si il a déjà construit le hakpack correspondant au .dup, si oui, on est près, sinon il le fait. à noter que cette information est effacée (même si pour l'instant elle n'est pas encore écrite :bouffon à chaque fois que les dialog.tlk sont sauvegardés (automatiquement quand NWN est patché, mais demandant tout de même une confirmation, et sinon quand l'utilisateur le désire). Donc chaque changement des tlks de base provoquera la recréation des haks au lancement des modules.
A quoi sert cette génération de hakpack? C'est simple, elle transforme toutes les références de la forme !<StrRef>, en <StrRef + nbr d'entrée dans le tlk de base> , autrement dit, elle transforme des références relatives aux .tlf et .tlm en référence absolues aux entrées ajoutées à dialog.tlk, dialogF.tlk.
Qu'est que ça veut dire pour le constructeur de module/hak?
Et bien, dans un premier lieu, il devra mettre toutes les entrées custom qu'il compte utiliser dans un .tlm (un tlk renommé) si elles sont à destination de dialog.tlk et éventuellement dans un tlf pour dialogF.tlk (sinon le tlm est utilisé par défaut).
Ensuite il devra construire un hakpack avec tous les fichiers référençant ces entrées custom. A chaque fois qu'il voudra utiliser une de ces chaînes plutôt qu'une de celles déjà existantes dans dialog.tlk, il mettra une référence de la forme !<index de la chaîne dans le tlm/tlf> plutôt que la référence classique. il renommera ce hak en .dup et lui donnera le même nom qu'au tlm et tlf.
Enfin dans son module il mettra une description commençant par [<nom des tlf/tlm/dup>] et référencera comme contenu custom le hak, pour l'instant virtuel, qui sera produit à partir du .dup. Tu va me dire comment fait-il pour l'ajouter puisqu'il n'existe pas? et ben le plus simple c'est d'utiliser le programme pour générer le hak directement a partir du dup, ce sera dans les "options avancées", ainsi que l'ajout direct des tlm et tlf aux dialog.tlk et dialogF.tlk de base.

Voilà je sais que c'est un peu () alambiqué mais je ne vois aucune méthode plus pratique.

[Sire Pom-pom]

Je vais pas faire encore un nouveau sujet, ça va finir par agacer eMRaistlin .
La fonction de transformation des .dups en haks est finie (et marche ), donc je suis sérieusement plus près de la fin que du début.
Si quelqu'un avait un truc à partir duquel je puisse faire une démo ce serait parfait parce que je sature un peu là...
Ce qu'il me faudrait c'est donc un module qui fonctionne avec des tlks auxquels des entrées ont été ajoutées. Il me faudrait le/les haks utilisant ces entrées ajoutées , et si vous pouviez préciser quels sont les 2das ou autres fichiers (.set, etc) où ces StrRef sont utilisées ce serait pratique . Bien sûr il me faudrait aussi les entrées à rajouter à dialog.tlk elle-mêmes, sous forme d'un (ou deux si ce ne sont pas les mêmes pour dialogF.tlk) tlk, si possible.
La taille n'a aucune importance, simplement je ne saurais pas où le mettre en téléchargement si c'est gros (d'ailleurs même si c'est petit, je vois pas très bien)
Voilà, si quelqu'un est intéressé , qu'il m'envoie un message.