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.