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

Répondre
Partager Rechercher
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.
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.
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 )
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...
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 )
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.
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...
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
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 )
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.
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
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...
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 ^^
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 .
Citation :
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) .
j'avoue ne pas trop avoir suivis le système dans ses profondeurs (pasque je suis flemmard, pas parsque tu n'explique pas bien), donc je te donne ce qui peut tendre le truc a ramer, et tu voix si ca peux poser problème dans le contexte :

au niveau des ressources cpu, aucun problèmes, une telle opération peut se faire en bien moins de 10s par un 486 (sauf si c'est vraiment très mal codé, mais je ne pense pas que la qualité du coding soit ton problème )
Par contre, c'est au niveau de la vitesse des disques que ca peux poser problème
Un disque standard met quand même un certain temp pour copier des données. Si ca ne se vera pas pour de tout petits fichiers, des copies de fichiers de plus de 100mo peuvent se montrer longue, trop longues.
Je le redis, je n'ai pas suivis le système, j'ai juste vu marqué "hakpak", or certains hakpak peuvent être vraiment très gros dézzipés, si le but de l'opération consiste à agir sur ces hakpak, prend garde.

Mais je n'ai pas l'impression que ce soit le but de l'opération, donc pas de problème ct juste une petite mise en garde (que tu avais peut être/surement déjà en tête )
Merci Azraël, le gros fichier serait bien dialog.tlk, les hakpacks contiendraient juste des 2da, donc 2MO serait déjà pas mal.
Pourquoi est que je parlais de restaurer dialog.tlk pour les modules "normaux" au fait? C'est inutile...
Citation :
) 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.
euh.... j'ai toujours pas cherché a comprendre le système mais ca ne risque pas de pauser de problèmes lors du patching de nwn si le système est configuré pour un module utilisant un dialog.tlk autre que celui de base ?
Non, parce que les 2da sont recréés suite au patch. Je te fais un résumé rapide, j'espère plus clair que ce que je raconte au-dessus:
Pour savoir que NWN a été patché il suffit de lire le.ini au lancement du programme, et de comparer avec l'info que l'on avait préalablement enregistrée.
Après le patch, quand le joueur veut lancer un module, on remet les chaînes "custom" à la fin du nouveau dialog.tlk.
On a, dans un fichier hak renommé en dup, les 2da avec des références relatives au chaînes rajoutées: !0 pour la première chaîne custom , !4 pour la cinquième... On remplace !0 par <0 + Nbre d'entrées dans le dialog.tlk après le patch> et !4 par <4 + Nbre d'entrées dans le dialog.tlk après le patch> . On met ce hak dans le dossier \hak du joueur (en écrasant la version précédemment créée si nécessaire) . Et comme le module référence ce hak on est bon jusqu'au prochain patch avec ce hak: toutes les références au chaînes "custom" sont correctes.

EDIT: en tout cas j'aurais apris un truc sur la programmation WIN32: il vaut mieux faire l'interface après avoir terminé la partie procédurale :bouffon: . Une question technique pour Azraël ou quelqu'un d'autre, je charge la clef de registre indiquant la racine de l'installation de NWN, mais je ne sais pas du tout comment gérer les erreurs au cas ou cette clé n'existe pas (je suppose qu'il faudrait que je laisse choisir le dossier à l'utilisateur, ça c'est bon, mais c'est chopper l'erreur elle même que je ne sais pas trop comment faire). Vous n'auriez pas une addresse à me conseiller? Dans le même ordre d'idée, pour les erreurs fatales (pour l'instant echec de malloc ou de MapView c'est tout ce que je vois) je ne sais pas trop comment faire, pour l'instant je pop une boite de message puis exit(0). Vaut-il mieux que je ferme les fenêtres avant?
bien... désolé je peux pas trop t'aider la dessus, j'y connais rien en prog sous WIN32/64 (j'ai un bouquin qui m'attend sur ma table de nuit, mais pour ca fo que je trouve le temp de lire le soir ^_^)
En fait, je ne suis même pas sur de savoir tapper un code en C en entier, je connais (très bien) les bases de la programmation, mais pas du tout les fonctions (bon, c'est ce qu'il y a de plus facile a apprendre )

Pour un lien... bien... tu peux demander à dieu, c'est le genre de truc qu'il connais très bien ^_^

EDIT :

bon, aller, je t'aide ^^
http://telecharger.01net.com/windows...ches/2760.html
http://www.cppfrance.com/article.aspx?Val=1301
http://perso-iti.enst-bretagne.fr/~b...utorialCPP.pdf

et la page de recherche
Merci pour les adresses Azraël, elles sont plus orientées C++, mais intéressantes. Pour le registre, j'ai trouvé, c'est tout simple en fait, mais la documentation de WIN32 API est quelque fois un peu déroutante (je trouve tout de même que renvoyer ERROR_SUCCESS en cas de réussite c'est un peu n'importe quoi ). Pour le exit j'ai rien trouvé de mieux, en théorie les mallocs devrait marcher de toute façon ...
Je pensais juste vous donner quelques nouvelles, après beaucoup d'hésitation j'ai choisi l'option II.1.c (à savoir construire dialog.tlk au lancement de NWN, à partir d'une sauvegarde de l'original et du fichier d'ajout). La mauvaise nouvelle c'est que je ne suis pas arrivé; la bonne, c'est que j'ai écrit la fonction d'addition des tlks et que c'est extrêmement rapide. Moins d'une seconde pour ajouter dialog.tlk à lui-même et obtenir un fichier de 14+ MO. Donc tout ceci m'a l'air faisable.
EDIT: Sur un céléron 1.7 et un disque dur IBM 20GO dont je ne me souviens plus des caractéristiques, mais qui a 3/4 ans.
Aie.... sur quoi a tu bloqué ? Dis tout à tonton azra ^_^
Pour moi, si t'as réussi à interagir avec les .tlk tu as déjà fait le plus dur, mais dis moi ce qui te bloque, je peux voir ce que je peux faire

PS : il y aurait moyen que tu publie une bibliothèque avec les fonction que tu as fait, genre "AddResRefToDialogFile" et "RemoveResRefToDialogFile" (je parle biblio et fonctions de C bien sur, pas de nwscripts). Bon, si t'as trop de modifs a faire pour la publier, pas grave, mais j'avoue que ca me ferais gagner pas mal de temp ^_^
Oui c'est pas trop surprenant, c'est l'australien dont je parlais . Et tu remarqueras qu'il précise que c'est mon idée, sympa de sa part, étant donné que ce que j'avais écrit sur les forums Bio était encore moins compréhensible que ce que j'ai mis ici :bouffon:
Franchement je ne sais pas trop quoi faire, je comprendrais qu'il ne soit pas très content si j'arrive avec ma propre version du schmilblik après qu'il a passé du temps sur la sienne. D'un autre point de vue, quoique le coup de l'override soit très malin (c'est de lui ça), ça oblige aussi le joueur à gérer lui même les 2da. Et il y a aussi le problème des deux tlks qu'il ne prend pas en compte pour les versions "internationales". Je veux pas avoir l'air de vendre ma soupe, surtout que rien ne dit ce qu'elle vaudra à l'arrivée, mais mon truc devrait être plus automatisé.
Pour préciser mon embarra, au moment de mon post sur le forum Bio, je ne me voyais pas du tout apprendre WIN32 API, ce qui me semblais essentiel pour ce programme (manifestement Tangello vient de prouver que j'avais tord la dessus). Dans un second temps j'ai même souhaité bonne route à Tangello pensant que je ne le ferais pas... Et puis quelques jours après...
Voilà, voilà .
Sinon Azraël je ne bloque sur rien de particulier, je disais juste que je n'étais pas arrivé, il me reste du chemin. Programmer en même temps que tu apprends une partie du langage c'est un peu coton, se retrouver dans WIN32 API, ça prend du temps.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés