JeuxOnLineForumsPlusConnectés : 637 (sites) | 1136 (forums)Créer un compte
Forum jeux-vidéo>Neverwinter Nights
Maskado
Les forums JOL > Forum jeux-vidéo > Neverwinter Nights > NWN - Maskado > Une idée de programme pour le problème des tlk RSS
   
Répondre
Partager Outils Rechercher
Sire Pom-pom
Roi
 
Lightbulb

Une idée de programme pour le problème des tlk

J'en ai déjà parlé sur les forums Bioware, quelqu'un a d'ailleurs repris l'idée et doit être en train de faire sa version. Mais puisque j'avais décider de me frotter à l'API Win32 de toute façon, je me suis lancé de mon côté. Etant donné que le cas des versions "internationales" de NWN est unh peu spécial, et que la personne que je mentionnais est Australienne, cela peut s'avérer utile. Le seul problème c'est que, comme je l'ai souvent déclaré sur ces forums, je ne suis pas exactement le meilleur programmateur de ce côté de l'Atlantique. Je viens de finir l'interface, il ne reste donc presque plus rien à faire :bouffon: .

Voilà l'idée générale: distribuer dans un format hak (mais renommé .dup) , des tlks avec les entrées que l'on veut rajouter au dialog.tlk et dialogF.tlk du joueur, ainsi que les 2da faisant référence à ces entrées. A la place des références normales au tlk on mettrait dans ces 2da des références relatives au tlk maison si c'est dans ces derniers que ce trouve l'entrée souhaitée. Pour ce faire au lieu de simplement écrire "<StrRef>" on écrira "!<StrRef>", où StrRef serait. la référence dans le tlk ajouté, commençant à 1, donc.

Le programme commencera par parser dialog.tlk dans le .dup (et éventuellement dialogF.tlk), et à rajouter les entrées à la fin du dialog.tlk du joueur, en gardant en mémoire la nouvelle référence des lignes ajoutées. Puis il créera un nouveau fichier .hak dans le répertoire \hak du joueur, de même nom que le fichier .dup, sans les tlks et en modifiant les entrées de la forme "!<StrRef>" dans les 2da: à la place il mettra la référence correspondante dans le dialog.tlk mis à jour, sans le "!" bien entendu. Et voilà résultat le hak fera référence aux bonnes entrées.

L'avantage c'est que le joueur n'aura plus besoin de changer de dialog.tlk pour changer de module, il lui suffira de rajouter les nouvelles entrées nécessaire à la fin, via le .dup distribué pour ce module. Si je me trompe prévenez moi tout de suite, il n'y a pas de problème (à par les BadStrRef) pour jouer ensemble si l'on a des Dialog.tlk différents?

Reste le problème des updates, pour pouvoir les faire, le joueur devra reprendre le tlk d'origine, et il devra ensuite réappliquer les .dup sur le Dialog.tlk patché, pour pouvoir rejouer à des modules utilisant ces hak "dynamiques".

Voilà, si par extraordinaire vous avez compris quelque chose à mon charabia, dites moi ce que vous en pensez.

EDIT: Idéalement le programme ne rajouterait que les entrées nécessaires, pas celles déjà présentes dans le dialog.tlk du joueur, mais dans un premier temps je ne pense pas que je tenterais cela, ca je n'impose aucune réstriction sur le type d'entrée dans les tlks ajoutées (entrées sons...), dans ces conditions ça n'est pas une très bonne idée je crois, pas trop regardé quand même.
Lien direct vers le message - Vieux
Avatar de 'Az
'Az [P.H.]
Alpha & Oméga
 
Avatar de 'Az
 
Mais, j'ai peut être pas tout compris, mais ca necessite de modifier toutes les entrées dans les fichier .2da dont on veut modifier le nom ?

personnelement, j'ai opté pour une solution bien plus simple, mais à mon avis tout aussi efficasse, qui est le renom du fichier dialog.tlk originial lors du lancement du mod, et le renom du fichier .tlk de mon mod (4eage.tlk par exemple) en le fichier dialog.tlk, et oppération inverse lors de la terminaison du programme.

Certe c'est moins jolie que ce que tu as fait, mais outrement moins complexe.
Lien direct vers le message - Vieux
Avatar de eMRaistlin
eMRaistlin
Alpha & Oméga
 
Avatar de eMRaistlin
 
Citation:
Provient du message de Azrael07
Mais, j'ai peut être pas tout compris, mais ca necessite de modifier toutes les entrées dans les fichier .2da dont on veut modifier le nom ?

personnelement, j'ai opté pour une solution bien plus simple, mais à mon avis tout aussi efficasse, qui est le renom du fichier dialog.tlk originial lors du lancement du mod, et le renom du fichier .tlk de mon mod (4eage.tlk par exemple) en le fichier dialog.tlk, et oppération inverse lors de la terminaison du programme.

Certe c'est moins jolie que ce que tu as fait, mais outrement moins complexe.
oO


Euh... tu explique, la ?

C'est quoi, c'est une appli tierce a lancer au loading, qui permet de faire le choix du TlK oO?

Euh, tu pourrait modifier ton appli pourqu'elle soit multi-tlk, et qu'elle lance le mode joueur ou le mode DM avec selection du module, et / ou selection du tlk ??

Ca serait chouette d'avoir un truc dynamique, et a mon avis, si c'est pas encore fait (mais ca m'etonnerait, vu que ca me dit rien), tu upload ca sur le vault, puis tu te prepare a signer des oteaugraphes...



(PS, et si en plus tu peux rediriger, dans des proprietes, vers un autre programme tiers (genre Puma et autre), ce serait encore mieux )
Lien direct vers le message - Vieux
Sire Pom-pom
Roi
 
Citation:
Mais, j'ai peut-être pas tout compris, mais ca necessite de modifier toutes les entrées dans les fichier .2da dont on veut modifier le nom ?
Pour celui qui fait le package oui, pour le joueur, non, le programme le ferait pour lui. Par nom, tu veux bien dire une entrée "name" ou "description" dans un 2da? Les seules fois ou le joueur manipulerait les tlk, c'est pour les sauvegarder et au moment des patchs.
Le truc n'est évidemment pas idéal, mais s'il y a un intérêt par rapport à la permutation de tlk , c'est en dehors du cadre des modules permanents:

Bill est un joueur frénétique il joue simultanément à 143 modules ayant tous des hakpaks, et des entrées spécifiques dans les tlk. Son Dialog.tlk fait maintenant 18Mo mais il n'en change que pour les patchs. Après le patch en revanche il doit réappliquer les 143 .dup qu'il a téléchargé pour pouvoir rejouer à ses modules préférés.

Jo fait des modules, il aime beaucoup les hak "sorts.hak" et "baseitem.hak" , sur lesquels il est tombé, en fait sorts.dup et baseitem.dup puisqu'ils contiennent des altérations aux tlk . Comme leurs noms l'indiquent, ces haks n'ont pas de conflit de 2da. Pour les distribuer avec son module, il suffira à Jo de distribuer les .dup tels qu'il les a trouvés.

Sid est un fabriquant de hakpack/mod de tlk à la chaîne, il n'a pas trop le temps de reprendre ses tlk pour les modifier après les patchs de Bioware, du coup ses tlk sont obsolètes, les .dup en revanche seraient toujours bon...
Mon dernier mot sera que ce truc à une chance de valoir le coup si j'arrive à éviter les redondances dans le tlk d'arrivée. Si je continue ce projet , je vais tenter le coup.

Ce serait quand même mieux si c'était Bio qui le faisait...
Lien direct vers le message - Vieux
Avatar de gaeriel/nekresh
gaeriel/nekresh
Empereur
 
Avatar de gaeriel/nekresh
 
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 )
Lien direct vers le message - Vieux
Avatar de Skanzo Sylan
Skanzo Sylan
Empereur
 
Avatar de Skanzo Sylan
 
Après un monstrueux gambergeage, je viens de voir l'atout du système de Pom-pom mais ce qui reste pour moi parfaitement mystérieux, c'est de devoir utiliser "!<StrRef>"...

En effet, un patch de Bioware modifie quasiment tout le temps le dialog.tlk. Il faut donc refaire le dialog.tlk de son module à chaque fois et le redistribuer aux joueurs.

L'avantage est bien ici d'avoir un morceau de tlk adaptable au toute circonstance, peu importe si le dialog.tlk original a été modifié ou non, c'est astucieux

Mais alors pourquoi refaire les 2DA (baseitem and co.) en repartant de 1?
Il suffirait de s'octroyer une gamme d'entrée, disons de 71000 à 73000...


L'idée de mettre un tlk dans le hak-pack me parait bonne car jusqu'à preuve du contraire, il est possible de mettre n'importe quoi dans un hak (enfin c'est ce que je me suis dit... ).


Je verais bien un programme qui check le contenu des hak-packs liés au module lancé.
- Si un hak-pack contient du tlk, il l'extirpe et ajoute les entrées au dialog.tlk original.
- Si aucun hak-pack ne contient de talk, on remet le dialog.tlk original.
Lien direct vers le message - Vieux
Sire Pom-pom
Roi
 
Citation:
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...
Lien direct vers le message - Vieux
Avatar de Skanzo Sylan
Skanzo Sylan
Empereur
 
Avatar de Skanzo Sylan
 
Citation:
Un autre truc est que l'on ne peut pas laisser de trou dans un tlk
Ha ben en effet, c'est bien ce que je craignais

Donc il sera possible de balancer dans le dialog.tlk toutes les entrées rencontrées dans un ou plusieurs .dup?

Au résultat, le joueur X qui vient sur le module A va avoir un dialog.tlk totalement différent du serveur et même du joueur Y qui fréquente aussi ce module A (sans parler des 2DA qui seront eux aussi différents).

Mouaip, maintenant que je comprend mieux, ça me plait assez
Lien direct vers le message - Vieux
Avatar de 'Az
'Az [P.H.]
Alpha & Oméga
 
Avatar de 'Az
 
bien.... c'est un bien beau projet en perspective, disons que c'est un truc vraiment universel qui peut êter facilement utiliseable (sauf pour la modification des .2da des sref, qui restent asset galère, encore que ca peux aller ^^), mais personnelement je garderais ma solution, c'est quand même bien plus simple

Citation:
C'est quoi, c'est une appli tierce a lancer au loading, qui permet de faire le choix du TlK oO?

Euh, tu pourrait modifier ton appli pourqu'elle soit multi-tlk, et qu'elle lance le mode joueur ou le mode DM avec selection du module, et / ou selection du tlk ??

Ca serait chouette d'avoir un truc dynamique, et a mon avis, si c'est pas encore fait (mais ca m'etonnerait, vu que ca me dit rien), tu upload ca sur le vault, puis tu te prepare a signer des oteaugraphes...
euh... ouais c'est un de met projets, mais j'ai vraiment pas beaucoup de temp, je suis pas sur de le sortir du contexte de mon module, j'ai le regret d'annoncer que ca risque fortement de rester dans le contexte de 4eage (comme bien d'autres apps de ce genre d'ailleur )
Lien direct vers le message - Vieux
Sire Pom-pom
Roi
 
Citation:
Au résultat, le joueur X qui vient sur le module A va avoir un dialog.tlk totalement différent du serveur et même du joueur Y qui fréquente aussi ce module A (sans parler des 2DA qui seront eux aussi différents).
Voilà , c'est ça que j'aurais du expliquer...
Au fait je ne pense pas que ça pose de problème, si? Etant donné bien sûr qu'au final toute les chaînes pointées se retrouvent identiques?
Bon je suis arrivé à un mélange de la première idée et de la deuxième qui pourrait être satisfaisant (l'idée de parser les .hak dans NWN \hak ne me revenait pas). Grosso modo le programme sauvegarderait tout: les dialog.tlk de Bio, les lignes ajoutées et les hak dynamiques, pour permettre la restitution totale. Au pire ça devrait faire autour de 20M de sauvegarde je pense.
Lien direct vers le message - Vieux
Avatar de Skanzo Sylan
Skanzo Sylan
Empereur
 
Avatar de Skanzo Sylan
 
Ben moua je dis tant mieux pour 4eage, de toute façon je pense pô que les gens iront ailleurs une fois qu'ils y auront gouté


Citation:
Au fait je ne pense pas que ça pose de problème, si?
Ben je me suis posé la question et heum, le seul truc qui risque de poser problème, c'est GetStringByStrRef... mais est-ce que y'a vraiment beaucoup de gens qui l'utilisent
J'en doute un max
Lien direct vers le message - Vieux
Sire Pom-pom
Roi
 
Bien vu Skanzo.
GetStringByStrRef: je pense que c'est acceptable, d'autant plus que cela marcherait pour les chaînes Bioware, donc pas de problème de leur côté. Il serait tout de même impossible d'utiliser cette fonction pour les chaines ajoutées avec cette technique. Cela me fait me demander si il ne pourrait pas y avoir d'autres problèmes...
Lien direct vers le message - Vieux
Avatar de Skanzo Sylan
Skanzo Sylan
Empereur
 
Avatar de Skanzo Sylan
 
Faudrait faire des tests en multi avec baseitem et dialog.tlk différents
Lien direct vers le message - Vieux
Avatar de 'Az
'Az [P.H.]
Alpha & Oméga
 
Avatar de 'Az
 
bon, ca sort un tout petit peu du contexte, mais voila comment je fait pour le GetStringByStrRef
En fait, je programme un système qui n'utilise pas le dialog.tlk mais une fonction qui possède des "StrRef" créée grace à des switch.

Ex : pour les dialogues flotant des npc :

Code PHP:
string StrRefDialogues(int nStrRef)
{
    
string sString;
    switch(
nStrRef)
    {
    case 
sString "Salutation voyageur, bienvenus dans notre petit village"; break;
    case 
sString "Il parait que le roi n'a plus toute sa tête ces temps ci"; break;
    case 
sString "Bon, chui pas la non plus pour trouver des exemples pour vos dialogues pour npc ^^"; break;
   default : 
ERROR("StrRefDialogues : StrRef inexistante"); //La fonction ERROR est une fonction que j'utilise courament pour le debugging, j'ai du déjà donner le corps quelque part dans ce forum
    
}
    return 
sString;

ce système est très interessant en équipe, pour ainsi permettre au créateur des dialogues de ne pas avoir à chercher dans tout les scripts pour créer/arranger les dialogues, ou corriger les fautes d'orthographe ^^

personnelement, j'ai fait un fichier include avec toutes mes fonction StrRef*, ce qui permet en fait d'obtenir un fichier dialog.tlk pour ce qui conserne l'utilisation de la fonction GetStringByStrRef (bien sur, pour les .2da, on ne peut rien faire avec ce système ^_^)


Bon, par contre, je suis un peu honteux, j'ai pas dis beaucoup de bien du système de Sire Pom-pom , qui pourtant est très prometteur si toutes les prévisions sont maintenues, mais bon, c'est un système interessant et très simple, je me devais d'en parler à un moment ou à un autre ^^
Lien direct vers le message - Vieux
Sire Pom-pom
Roi
 
Bon l'accumulation de chaînes ajoutées sur dialog.tlk, et le principe des tlk/hak différents étant un peu, disons tangent, je propose une autre possibilité, il faut voir si le temps pris par les différentes opérations ne la rend pas impraticable. Un programme lançant NWN.exe pour le joueur. Pour installer un module avec des "haks dynamiques" il suffirait de mettre un fichier hup et un fichier tlk ayant tout deux le même nom que le module dans le répertoire hak. La fenêtre principale du programme scan \mod et propose une liste des modules à lancer.

1) Soit le module choisit est le même que celui qui a été lancé la dernière fois (ou équivalent : ie pas besoin de tlk modifié) , auquel cas le programme lance NWN sans rien faire.

2) Soit le module un fichier .dup est trouvé dans le répertoire hak, auquel cas l'update de tlk est faite, et le dup transformé en un hak (de nom par exemple d_<module>.hak) de façon cohérente. Le module enregistre le nom du module, et quelques autres informations (première entrée custom...) en prévision des patchs Bioware. Peut-être le .dup devra-t-il être sauvegardé en prévision des patchs.

3) Soit le module nécessite le dialog.tlk d'origine, et ce dernier n'est pas en place, auquel cas il est restauré (la sauvegarde aura été faite au premier lancement, ou juste après que le jeu ait été patché cf plus loin).

4) Soit le module est sur la liste des modules déjà traité, le programme fait juste l'update de tlk, sans toucher au hak.

reste un point, les patches: le programme doit enregistrer la version du patch en cours après la sauvegarde de dialog.tlk ; et si , plus tard, il détecte un changement, grosso modo se réinitialiser: prévenir le joueur qu'il (le programme) va sauvegarder dialog.tlk... Quand un module traité pour le patch précédent sera demandé on recommencera l'opération 2) .

Voilà je peux me tromper complètement mais je ne pense pas que, même dans le pire des cas, les opérations avant le lancement d'un module prendrait plus de dix secondes (sauf bien sûr sur un 486) .

Qu'en pensez-vous?

PS désolé pour ces posts à répétition, mais j'aimerais bien parvenir à une conception stable avant de me lancer .
Lien direct vers le message - Vieux
Répondre
Les forums JOL > Forum jeux-vidéo > Neverwinter Nights > NWN - Maskado > Une idée de programme pour le problème des tlk
   

Outils Rechercher
Rechercher:

Recherche avancée

Les vidéos de Neverwinter Nights RSS
  • Aucune vidéo pour le moment...
Thème visuel : Fuseau horaire GMT +1. Il est actuellement 14h04.
   

© JeuxOnLine, le site des MMO, MMORPG et MOBA. Tous droits réservés. - Conditions générales d'utilisation - Conditions d'utilisation des forums - Traitement des données personnelles - ! Signaler un contenu illicite