Création d'un Editeur Baldur's Gate

[Luren]

Que manque t'il aux éditeurs actuels pour améliorer la réalisation de mod?
Il serait intéressant d'avoir plusieurs retours sur cette question.

- Le manque d'unité : il faut utiliser plusieurs programmes différents, et on passe son temps à naviguer de l'un à l'autre, ce qui multiplie les sources potentielles d'erreurs, et demande un certain temps d'apprentissage. Je ne pense pas qu'un éditeur qui prenne tout en charge serait possible ou souhaitable. Ce qui serait déjà bien, serait des éditeurs pour des types de données : aspect graphique (zones, images animées, icônes, interface), sonore (musiques, sons d'ambiance, dialogues), texte (dialogues, livres, journal) et programmation (créatures, scripts, zones de jeu).... mais je n'ignore pas combien je suis loin de la réalité et du possible lorsque je parle de cela !
- Le manque de finalisation : il n'est pas rare de se ramasser des erreurs/plantages sur la plupart d'entre eux, ou ils ne prennent pas en charge toutes les versions des fichiers existantes : IETME, DLTCEP, BamWorkshop, MosWorkshop, CreMaker... doivent toujours être utilisés avec des restrictions et en connaissance de leurs limites.

Au sujet de ton programme :
C'est agréable de travailler dans une interface graphique, comme tu as commencé à le faire pour les créatures dans ton éditeur, mais pour le temps de travail que cela va te demander comparé au plus que cela apporte par rapport au tableaux, je ne sais pas si cela en vaut la chandelle. En général les personnes qui se lancent dans la création de Mods ne sont pas rebutées par un style "sobre" qui permet, quand il est bien organisé, de visualiser plus de données à la fois et de travailler plus vite. Personnellement, un interface comme celui de Near Infinity ou de DLTCEP ne me gênent pas du tout.
Autre argument : il te sera peut-être plus facile de créer un programme avec un interface graphique inspiré du jeu, lorsque tu auras un programme qui marche parfaitement, et sera bien rodé et huilé en mode tableur.


- J'avais noté des problèmes de positionnement des fenêtres lorsqu'on est sous "Liste Base", mais je vois que tu les as notés aussi.
- Une petite remarque sur la désinstallation : Un certain nombre de fichiers restent dans le dossier d'installation. Lors d'une réinstallation ils entrent en concurence avec les nouveaux et on se récolte un plantage lors du lancement du programme. J'ai dû les supprimer manuellement, et refaire une installation pour que tout marche nickel.
- Le mode "simulation" des dialogues ne semble pas encore fonctionnel, non ? Lorsque je coche/décoche "condition", cela n'a aucun effet sur l'affichage des dialogues même si certains contiennent des conditions.

[Isaya]

Merci pour les précisions sur le fonctionnement de l'éditeur. Cela permet de mieux comprendre certaines questions que tu te poses.

Mon but est de faciliter le travail technique du modeur au maximum. Je pense que c'est l'une des causes principales d'abandon de mod.

La partie installation du mod en est une. Si WEIDU + Tp2 sont des incontournables, comme tout le monde me le dit, je n'ai rien contre.
Ma réflexion avait pour but de savoir, si il est possible de "soulager" cette partie de manière automatique via l'éditeur.
Est il possible de faciliter, aider, à l'écriture du tp2, en automatique, en fonction de ce qu'a réalisé le modeur?

Pour faciliter la création du fichier TP2, il faudrait que tu ajoutes un gestionnaire de projet qui recenserait tous les fichiers créés pour le mod et ceux qui ont été modifiés. En cas de création, c'est relativement simple (mais j'insiste sur le relativement, car il peut y avoir malgré tout des cas compliqués) d'écrire les lignes du TP2 associées. Mais dans le cas de modification, cela peut-être très très compliqué de patcher le fichier modifié : il est généralement interdit d'écraser un fichier existant (et si un autre mod avait déjà apporté une modification ?), il faut donc apporter la modification par un patch (par exemple, cas simple, ajouter un objet à un personnage).
Un éditeur pourrait faciliter la vie du moddeur en écrivant le patch. Mais ce travail-là suppose des connaissances très très pointues des formats et du langage de WeiDU. Disons simplement que le contrôle de conformité d'un élément aux règles du jeu est de la simple rigolade par rapport à ça. Quant tu t'ennuieras, aux environs de 2015 peut-être, tu pourras y penser.

Actuellement:
- tout le mod en cours est stocké dans des fichiers au format du jeu.
- un fichier crée ou modifié est copié et stocké dans le répertoire \mod de l'éditeur. C'est lui qui contient l'évolution. Le fichier de référence, si il y en a un, reste au chaud, intact, dans le jeu.

C'est ce que je fais avec les champs de type biographie. L'évolution est stockée dans le dialog.tlk de \mod. Il contient l'existant du jeu avec les nouveaux textes correctement "insérés".

Si le joueur veut tester son mod en cours de création dans le jeu, je suppose qu'il doit copier coller ses fichiers \mod dans le jeu ou faire un tp2 intermédiaire.

Cela peut marcher à condition qu'il n'y ait pas eu entre temps de modifications dans le fichier dialog.tlk du jeu de référence. C'est une hypothèse raisonnable, et tant pis pour le bidouilleur qui travaille sur une base instable.

-au moment d'installer le jeu, il faut utiliser les fichiers présents dans \mod comme source.
=> si c'est maladroit je vais modifier ce point.

Non, c'est tout à fait raisonnable.

L'idéal serait que le moddeur place ce répertoire dans celui du jeu (comme on fait au final pour l'installation), copie le fichier dialog.tlk du mod dans le répertoire du jeu, puis lance WeiDU en utilisant l'option --automate. Cette option "magique" de WeiDU est capable, en lui indiquant le répertoire des fichiers du mod, de créer une grosse partie du fichier TP2 nécessaire à l'installation. Mais attention, il ne faut l'exploiter que pour les fichiers ajoutés par le mod. Le travail de patch pour les fichiers modifiés ne sera jamais magique.

Echange de point de vue
Penses tu que c'est une 'perte' de temps que de vouloir mettre une interface graphique à l'éditeur?

Si je ne travaille pas ce point, je ne vois pas ce que 'Monsieur Plus' peut apporter dans ce domaine. Mon éditeur ressemblera à NI. On aura juste un tableur BG de plus.

Je n'ai pas dit ça. J'ai simplement indiqué que beaucoup d'idées que tu avais exprimées n'étaient pas fondamentales pour obtenir déjà un bon éditeur : glisser-déposer comme dans le jeu, contrôle de respect des règles, ...

Par ailleurs, DLTCEP dispose d'une "interface graphique", pas d'un simple tableau comme Near Infinity. Ce n'est pas un modèle d'ergonomie. Mais le fait qu'elle ne reprenne pas les effets "flashy" du jeu la rend tout de même plus fonctionnelle. Le jeu n'a pas du tout la même approche : pas d'ajout d'objet depuis l'inventaire, par exemple (ni de sorts, ...).
Actuellement, les icônes de l'éditeur de créature ne me paraissent pas parlantes : je préfèrerais un bon texte. Idem pour de nombreux boutons. Mais bon, chacun ses goûts. Ce que je retiens néanmoins, c'est que l'ergonomie est bien plus importante que l'aspect. Des informations regroupées de façon intelligible dans des écrans clairs et non surchargés me semblent bien plus importants qu'une ressemblance factice avec le jeu. Qui lui a une ergonomie adaptée au joueur mais du tout au créateur de mod, pour l'essentiel.

Que manque t'il aux éditeurs actuels pour améliorer la réalisation de mod?
Il serait intéressant d'avoir plusieurs retours sur cette question.

Impossible de répondre simplement à cette question tant il y a d'éditeurs différents et pour différents besoins.
Si on les compare aux éditeurs de jeux comme Neverwinter Nights 2 et Dragon Age, il leur manque surtout une interface unique, prenant en compte tous les aspects d'un projet de mod (hormis les aspects son et graphique, laissés à des outils spécialisés). Pour le reste, ils sont rarement ridicules, sinon par certaines limites ou bugs. Il est probable que Luren galère notamment parce que bien peu connaissent les spécificités d'Icewind Dale II.

La comparaison avec des éditeurs du commerce n'est pas fortuite : le problème de fond est toujours le même, le fait qu'aucun de ces outils n'est vraiment à la portée du débutant. La raison est simple : les éditeurs livrent ce qu'ils utilisent en interne. Et ils peuvent se permettre de former leurs créatifs avec le support direct des programmeurs.

Quand Interplay a diffusé, bien des années plus tard, les outils internes pour Fallout, les gens ont découvert que les éditeurs réalisés par les fans étaient par bien des aspects souvent meilleurs. Certes, c'était il y a longtemps mais il y a fort à parier qu'on aurait la même chose si Bioware n'avait pas perdu ceux de Baldur's Gate et les avaient rendus disponibles (prétexte ultime invoqué pour ne pas les diffuser).


Editeur actuel

Mon but est de créer/modifier les fichiers en conservant le style de présentation dans le jeu. Il sera possible de travailler en mode tableur si le modeur préfère ou si le champ n'est pas disponible en version graphique.

Je ne suis pas convaincu que ce soit une bonne idée de conserver deux façons de faire, plus ou moins complètes. Il vaudrait mieux concentrer l'effort sur un mode, qui dispose de toutes les capacités. Si tu veux simplifier, propose un option qui désactive les aspects "complexes" qui servent rarement (option "Avancé" de nombreux programmes qui cachent une partie des choses). Sinon tu vas te retrouver avec un éditeur qui présente le même défaut que l'agglomération d'éditeurs qu'on utilise parfois : IETME pour cette partie, puis passage dans DLTCEP, ... (cf l'exemple de Luren).

Ecran pris d'assaut au démarrage
C'est noté cher ami, je regarderai pour stopper cette animation et te laisser maitre de ton écran!
J'ai bien senti que j'allais en prendre une sinon!

Mais non, je ne suis pas violent, mais je préfère le fonctionnel au kikoulol !

[Luren]

La comparaison avec des éditeurs du commerce n'est pas fortuite : le problème de fond est toujours le même, le fait qu'aucun de ces outils n'est vraiment à la portée du débutant. La raison est simple : les éditeurs livrent ce qu'ils utilisent en interne. Et ils peuvent se permettre de former leurs créatifs avec le support direct des programmeurs.

Quand Interplay a diffusé, bien des années plus tard, les outils internes pour Fallout, les gens ont découvert que les éditeurs réalisés par les fans étaient par bien des aspects souvent meilleurs. Certes, c'était il y a longtemps mais il y a fort à parier qu'on aurait la même chose si Bioware n'avait pas perdu ceux de Baldur's Gate et les avaient rendus disponibles (prétexte ultime invoqué pour ne pas les diffuser).

Et de plus ils n'ont pas à se poser le problème de réunir les différents aspects d'un jeu dans un même éditeur. Le travail en équipe avec des postes bien définis permet de séparer le travail en différentes tâches, puis de le fusionner ensuite. Le florilège des formats de fichiers de l'Infinity Engine est révélateur de ce type de fonctionnement.
Le problème des moddeurs se pose de manière tout à fait différente : leur nombre en général restreint les oblige à travailler sur plusieurs domaines : graphismes, programmation, scénario, etc. qui recquièrent des outils complètement différents !
D'où la recherche d'un éditeur "multitâche" qui arriverait à réunir des outils de travail abordant si ce n'est la totalité des aspects d'un jeu, au moins un grand nombre, et dont la pierre d'achoppement est la complexité... augmenté du fait qu'il s'agit de le mettre à disposition de débutants ! Un véritable défi !!!

[Cocrane]

J'ai pris note de vos retours. Ca m'aide à prendre du recul.

Quelques commentaires

"autre argument : il te sera peut-être plus facile de créer un programme avec un interface graphique inspiré du jeu, lorsque tu auras un programme qui marche parfaitement, et sera bien rodé et huilé en mode tableur"

Tout à fais d'accord avec toi. C'est la bonne démarche:
"avant de faire 'joli', il faut que le programme fonctionne."
J'ai commencé à coder sans avoir une analyse complète car le jeu garde jalousement ses secrets. Il faut creuser et appeler à l'aide pour avancer. Je fais donc l'analyse et le code en même temps.

Depuis Avril 2010 (début du projet), je me suis concentré sur la partie fonctionnelle jusqu'à décembre. J'ai codé les fonctions communes de lecture / écriture pour certains fichiers.
Mon but est de livrer la partie créature. J'attaque donc les graphismes.

Hier j'ai fait des essais pour le glisser / déposer d'icônes sur l'écran d'équipement. Ca fonctionne plutôt pas mal (sélectionner, positionner, reprendre, jeter un objet).

Cependant deux soucis majeurs:
- accéder en temps réel aux données des fichiers va être trop long je pense. Surtout si on recherche une arme... On doit lire x ITM et BAM pour afficher la BAM, la description etc...
=> Solution possible:
> charger en base de données les informations dont j'ai besoin (au minimum)
> mettre ces données dans le fichier d'installation. L'affichage des données sera donc rapide dans l'écran d'équipement.
> Si un fichier ITM est crée ou évolue, la base de données du modeur sera mise à jour.
> En d'évolution pendant que l'éditeur est fermé, un nouveau fichier collé dans le jeu sera détecté. La substitution sera par contre non traitée.

- la BAM que je traduis est entourée de "vert fluo". Dans le jeu, le fond de la case est conservée.
=> solution à trouver.

"Désinstallation foireuse"
Ta remarque est bonne. Il faut toujours pour le moment installer dans un nouveau répertoire. Je maîtrise mal l'outil 'Inno Setup'. Mais à terme, la désinstallation sera propre.
Certains fichiers non listés dans Inno sont crées par le programme à son lancement. Inno, ne les connait pas et ne les désinstalles pas...

"La simulation fonctionne mal avec les cases à cocher"
J'ai testé quelques fichiers hier soir. J'ai pas noté d'erreur. Peux tu me donner un nom de fichier lié au jeu d'origine? Si c'est un fichier de modeur, peux tu me l'envoyer?

J'aimerai pouvoir faire une sorte d'assistant sur ce sujet. Mais le dossier me semble très complexe.

"Projet d'installation de mod"
Je note que le répértoire \mod suffit pour permettre à l'équipe WEIDU + tp2 de remplir son office. Je vais me concentrer sur les fichiers de modeur. C'est pas une priorité.

A noter, il y a une explication en partie technique de l'éditeur dans la doc présente dans l'installation.

"Par ailleurs, DLTCEP dispose d'une "interface graphique", pas d'un simple tableau comme Near Infinity. Ce n'est pas un modèle d'ergonomie. Mais le fait qu'elle ne reprenne pas les effets "flashy" du jeu la rend tout de même plus fonctionnelle. Le jeu n'a pas du tout la même approche : pas d'ajout d'objet depuis l'inventaire, par exemple (ni de sorts, ...).
Actuellement, les icônes de l'éditeur de créature ne me paraissent pas parlantes : je préfèrerais un bon texte. Idem pour de nombreux boutons. Mais bon, chacun ses goûts. Ce que je retiens néanmoins, c'est que l'ergonomie est bien plus importante que l'aspect. Des informations regroupées de façon intelligible dans des écrans clairs et non surchargés me semblent bien plus importants qu'une ressemblance factice avec le jeu. Qui lui a une ergonomie adaptée au joueur mais du tout au créateur de mod, pour l'essentiel."

J'accroche davantage à NI qu'a DLTCEP même si DLTCEP fait l'effort d'ordonner les champs par thème. Vu qu'on l'on doit deviner soit même le rôle du champ, je préfère les avoir dans l'ordre du fichier source.

Ca me semble une bonne idée d'avoir un éditeur qui explique le rôle du champ (info bulle ou clic sur '?')

Je suis d'accord sur le fait que l'interface graphique ne doit pas être identique au jeu. Les besoins ne sont pas les mêmes: le joueur joue et le modeur doit moder.
L'éditeur reprend les graphismes du jeu pour l'adapter aux modeurs. J'essaie de rendre l'interface intuitive et efficace. Si elle ne l'est pas, je tacherai de la faire évoluer en fonction des retours utilisateurs.

Un bouton a la place d'un texte, je trouve ça plus agréable. J'ai fait un choix parmi les icônes que j'avais sous la main. Si il y a des icônes, plus 'parlant', je suis preneur.

Equipement
On pourra:
- rechercher, ajouter, supprimer, (dé)placer et décrire des objets dans l'équipement. Les restrictions de type d'objet et de kit seront gérées.

- l'évolution des caractéristiques de même si c'est possible (THACO, CA etc...)

- autre?

La gestion des sorts sera dans le même ordre d'idée. J'ai pas encore réfléchi dans le détail.


"Envoyé par Cocrane Voir le message
Mon but est de créer/modifier les fichiers en conservant le style de présentation dans le jeu. Il sera possible de travailler en mode tableur si le modeur préfère ou si le champ n'est pas disponible en version graphique.
"
Le mode tableur aura pour moi, un fonctionnement similaire à NI. Je ne vois pas comment j'aurai une valeur ajouté sur ce point. Mis à part de se dire, "tout est dans un seul outil".

De même, je n'ai pas d'intérêt à thématiser comme DLTCEP vu que j'ai la partie graphique sur ce domaine.

Conclusion: On limite la partie tableur à la visualisation des données par rapport à la structure du fichier? ou on permet la création et modification?

Coco

[Armand]

- la BAM que je traduis est entourée de "vert fluo". Dans le jeu, le fond de la case est conservée.
=> solution à trouver.

D’après ce que je sais il faut indexer le vert en première position dans la palette de couleur je te renvois au Tutorial de rigel sur légende qui traite de la recolorisation de bam.

[Isaya]

Cependant deux soucis majeurs:
- accéder en temps réel aux données des fichiers va être trop long je pense. Surtout si on recherche une arme... On doit lire x ITM et BAM pour afficher la BAM, la description etc...
=> Solution possible:
> charger en base de données les informations dont j'ai besoin (au minimum)
> mettre ces données dans le fichier d'installation. L'affichage des données sera donc rapide dans l'écran d'équipement.
> Si un fichier ITM est crée ou évolue, la base de données du modeur sera mise à jour.
> En d'évolution pendant que l'éditeur est fermé, un nouveau fichier collé dans le jeu sera détecté. La substitution sera par contre non traitée.

DLTCEP et Near Infinity font une indexation de tous les fichiers du jeu au démarrage. Comme ils lisent directement les fichiers chitin.key et le répertoire Override sans passer par WeiDU, ils vont plus vite. A partir de ces informations, ils savent aussi facilement aller lire un fichier (ITM, BAM, ...) dans les fichiers BIF ou le répertoire Override. Ce qui va aussi bien plus vite que d'appeler WeiDU (qui refait ce boulot à chaque fois que tu l'exécutes). Ceci rejoint mes incitations passées à savoir traiter les fichiers du jeu sans recourir à WeiDU.
Mettre ces informations dans un fichier fourni avec l'éditeur est de mon point de vue une bêtise. Si un moddeur veut s'appuyer sur autre chose que le jeu que tu as prévu dans ta livraison de l'éditeur (SoA sans ToB, ou avec, ou avec BGT, ...), cela ne fonctionnera pas. Si tu veux constituer une base une fois pour toute, fais-le quand l'utilisateur choisit le répertoire du jeu dans ton écran de configuration.

- la BAM que je traduis est entourée de "vert fluo". Dans le jeu, le fond de la case est conservée.
=> solution à trouver.

J'ai déjà abordé cette question dans ma réponse décrivant le format BAM puis dans le cas concret du fichier IMISC2J.BAM.

La fameuse couleur transparente est éventuellement définie dans l'en-tête. Si elle n'est pas définie, elle prendra pour valeur (dans la palette de 256 couleurs) la première entrée de la palette qui a un code RGB correspondant au vert (0, 255, 0). C'est pour ça que le vert apparaît fréquemment dans l'affichage des BAM dans les outils. Ce choix n'est sûrement pas anodin car il correspond à la couleur de transparence utilisée en fond au cinéma pour découper les acteurs afin de les superposer à d'autres images.

Pour décompresser le RLE, il faut s'appuyer sur la valeur de "The compressed colour index for RLE encoded bams" dans l'en-tête du fichier.
La description de ce champ donne, en français :

L'index de la couleur compressée pour les BAMs codés en RLE (c'est à dire la couleur qui est compressée).

L'index de transparence est fixé à la première occurence du code RGB(0,255,0). Si le code RGB(0,255,0) ne figure pas dans la palette, l'index de transparence est fixé à 0.

Dans le fichier qui nous intéresse, ce champ vaut 0. C'est donc la couleur à l'index 0 dans la palette qui sera compressé puisque le fichier utilise la compression RLE. Cela signifie que la valeur 0 dans la table de valeur de l'image indique que l'octet suivant est le nombre - 1 de pixels consécutifs dans la couleur compressée. Autrement dit une séquence 0 20 dans la table de pixel d'une image signifie 21 pixels consécutifs dans la couleur 0 de la palette.
Si le champ de l'en-tête avait valu 10, il aurait fallu repérer les séquences 10 suivi d'un nombre pour savoir combien de fois cette couleur 10 de la palette était répétée.

Dans la palette de notre BAM, l'index 0 a également la valeur RGB(0,255,0), plus le quatrième octet alpha toujours à 0. C'est à dire que ce sera notre couleur transparente. Ça tombe bien, c'est le code RGB du vert. Notre couleur compressé est donc la couleur transparente. C'est fréquemment le cas dans les BAMs. En effet, il y a souvent tout l'entourage autour de l'objet ou de l'icône de sort que l'on ne veut surtout pas faire apparaître à l'écran. Choisir cette couleur pour la couleur compressée est donc judicieux pour gagner sur le codage des pixels entourant la véritable image.

Autrement dit, dans l'exemple en question, c'est bien la couleur 0 de la palette qui correspond au vert, RGB(0,255,0). Donc à chaque fois qu'intervient la couleur 0 dans l'image (décompressée RLE, si nécessaire), il te faut tout simplement ne rien afficher pour le point correspondant.

"Désinstallation foireuse"
Ta remarque est bonne. Il faut toujours pour le moment installer dans un nouveau répertoire. Je maîtrise mal l'outil 'Inno Setup'. Mais à terme, la désinstallation sera propre.
Certains fichiers non listés dans Inno sont crées par le programme à son lancement. Inno, ne les connait pas et ne les désinstalles pas...

Il me semble que je t'avais proposé un fichier exemple avec Inno Setup pour gérer la désinstallation. Si tu préfères, envoie-moi par mail ton fichier .iss (je te donnerai mon adresse par message privé) et je tâcherai d'ajouter le nécessaire.
Pour ma part, actuellement, je me contente de désinstaller la version précédente et d'effacer le répertoire d'installation pour faire place nette à la nouvelle version.

A noter, il y a une explication en partie technique de l'éditeur dans la doc présente dans l'installation.

Ma foi, si tu veux faire fuir le moddeur...
Je sais bien que les créatifs ont toujours bien mieux à faire que documenter leur travail. Et je sais aussi par expérience qu'un programmeur est rarement capable de décrire simplement le fonctionnement de son outil car il est prisonnier de l'aspect technique de outil. L'idéal serait que tu trouves un moddeur qui veuille bien contribuer (inutile de regarder dans ma direction ).

Ca me semble une bonne idée d'avoir un éditeur qui explique le rôle du champ (info bulle ou clic sur '?')
...
Un bouton a la place d'un texte, je trouve ça plus agréable. J'ai fait un choix parmi les icônes que j'avais sous la main. Si il y a des icônes, plus 'parlant', je suis preneur.

Sacré travail, à vrai dire, un peu comme la documentation. Parce que, quand on commence, il ne faut pas s'arrêter à moitié et ne décrire que les boutons jugés les plus importants, sous peine de perdre l'utilisateur.
C'est pour cette raison qu'un bon texte me semble pratiquement toujours préférable à une icône ambiguë. Surtout quand tu dois essayer de composer avec des icônes faites pour un autre usage (le jeu) et qu'il est alors plus compliqué d'en créer une soi-même qui ne dépare pas.

Equipement
On pourra:
- rechercher, ajouter, supprimer, (dé)placer et décrire des objets dans l'équipement. Les restrictions de type d'objet et de kit seront gérées.

- l'évolution des caractéristiques de même si c'est possible (THACO, CA etc...)

- autre?

La gestion des sorts sera dans le même ordre d'idée. J'ai pas encore réfléchi dans le détail.

A mon avis, tout ceci entre dans la catégorie des choses ambitieuses et dévoreuses de temps. Je pense que tu aurais intérêt à sortir avant tout une version basique mais couvrant tous les besoins de la création de créature, qui sera amplement suffisante, avant d'envisager ces "fioritures".

Bonne continuation.

[Cocrane]

Vu que j'attaque l'affichage des fichiers CRE dans l'interface Graphique. Je vais gérer la traduction en même temps.

Par rapport à ce que l'on a dit sur le sujet, voilà ce que j'ai choisi:
- fichier Excel
- une colonne pour le champ BG
- une colonne par langue pour le champ traduit.

Le fichier de traduction, localisé dans le chemin de l'éditeur, a pour nom 'BG_traduction.xls'. Il sera chargé au démarrage.

Si le champ BG n'est pas traduit, c'est celui de BG qui sera affiché par défaut.

Attention:
- Pas de ligne à blanc.
- Pas de colonne à banc ajoutée.

Le programme considéra respectivement que la traduction en cours est terminée ou que le chargement de la traduction est finie.

Action
Il ne reste plus que des courageux pour traduire. Le fichier est disponible sous:

BG_traduction.xls

J'ai mis le contenu de 3 fichiers IDS pour le moment.

Si certains d'entre vous, décident de m'aider. Ecrivez un message afin que vous ne soyez pas plusieurs à faire la même chose.

Coco

[Cocrane]

BAM vert fluo
"
Autrement dit, dans l'exemple en question, c'est bien la couleur 0 de la palette qui correspond au vert, RGB(0,255,0). Donc à chaque fois qu'intervient la couleur 0 dans l'image (décompressée RLE, si nécessaire), il te faut tout simplement ne rien afficher pour le point correspondant.
"
Je me souviens de ce sujet mais je ne pensais pas que WINDEV laisserait le fond apparaitre si le pixel n'était pas renseigné.
Arfff j'ai eu tord! WINDEV a bon caractère.

Documentation Editeur
"
Ma foi, si tu veux faire fuir le moddeur...
Je sais bien que les créatifs ont toujours bien mieux à faire que documenter leur travail. Et je sais aussi par expérience qu'un programmeur est rarement capable de décrire simplement le fonctionnement de son outil car il est prisonnier de l'aspect technique de outil. L'idéal serait que tu trouves un moddeur qui veuille bien contribuer (inutile de regarder dans ma direction ).
"
Non la doc est orienté utilisateur. J'ai notamment précisé l'arborescence de l'éditeur.


INNO SETUP
"
Il me semble que je t'avais proposé un fichier exemple avec Inno Setup pour gérer la désinstallation. Si tu préfères, envoie-moi par mail ton fichier .iss (je te donnerai mon adresse par message privé) et je tâcherai d'ajouter le nécessaire.
Pour ma part, actuellement, je me contente de désinstaller la version précédente et d'effacer le répertoire d'installation pour faire place nette à la nouvelle version.
"
Je me suis pas penché sur tes explications par manque de temps et choix sur les priorités de l'éditeur. (non non je ne baratine pas!)

Le lancement de l'exe, génère les DLL et des fichiers .fic et ndx non listés dans l'INNO.
Du coup à la désinstallation, il ne les supprime pas. Ce sont des fichiers de base données vides au lancement.

Documentation des champs
Je lance cette idée car quand tu débutes et que tu ouvres NI. Tu te demandes à quoi sert ce champ. Tu as le nom uniquement pour l'interprétation c'est assez bloquant pour un modeur débutant. Moi j'ai fui .

Donc une documentation dynamique dans l'éditeur me semble être un plus.

Entre floritures et fonctionnel
"A mon avis, tout ceci entre dans la catégorie des choses ambitieuses et dévoreuses de temps. Je pense que tu aurais intérêt à sortir avant tout une version basique mais couvrant tous les besoins de la création de créature, qui sera amplement suffisante, avant d'envisager ces "fioritures"."

Faire une interface avec des champs et listes va nécessiter du temps. Je n'apporterai rien de plus que ce qui existe déja.
Tout faire directement via la partie graphique est je pense plus économique au final car je me dirige directement sur mon objectif.

- La lecture / écriture des CRE fonctionne.
- J'arrive à afficher des BAM non animées.
- Je peux lire / écrire dans des ITM, SPL et TLK.
- je viens de créer la partie traduction qui fonctionne.

Ce qui manque c un test de fichier traité dans l'éditeur, intégré dans le jeu et voir si ca fonctionne.

Je pense avoir le fonctionnel nécessaire pour faire ma partie graphique sur les CRE.

Se passer de WEIDU
Tu abordes une 2nd fois ce sujet et je ne vois toujours pas comment se passer de l'extraction du fichier par WEIDU.

Je lis les données du fichier KEY (que je n'ai pas étudié). Mais comment dire au moteur, de m'extraire le fichier?

Pour ce qui est de créer ma base de données à l'installation. J'ai pensé proposer cette solution. L'install va être longue si on doit lire et charger les ITM et BAM.

NI est très rapide mais il n'a pas besoin de charger x fichiers suite à une demande du moddeur pour avoir 'la liste de toutes les armures du jeu en icône avec la description de l'armure".

En allant même plus loin, on peut tout charger dans ce cas. Mais je pense qu'on en a pour un bon moment. A voir.
En tout cas le résultat est alléchant. Tout en base de données et les fichiers modés dans \mod, le rêve.

Si il existe une rubrique sur les connaissances du jeu, on pourrait p.e alimenter par domaine cette dernière de nos discussions.
Je pourrais poser mes questions connaissances dessus et traiter ici uniquement les sujets liés à l'ergonomie / graphisme de l'éditeur.

Coco

[Luren]

En me servant de Near Infinity et Infinity Talker, et en comparant les entrées anglaises et françaises, j'ai renseigné le fichier .xls que tu donnes. :

Télécharger la modif de BG_traduction.xls sur MEGAUPLOAD

À vérifier / valider !

[Isaya]

Documentation Editeur
Non la doc est orienté utilisateur. J'ai notamment précisé l'arborescence de l'éditeur.

En l'état, elle semble trop technique pour le débutant. En particulier sur la configuration (choix des répertoires), où aucune explication n'est fournie sur la meilleure façon de choisir ces répertoires (pour la partie Mod).

L'appel à la contribution de simples utilisateurs me semble pertinent car un programmeur a toujours tendance à considérer comme évident ce dans quoi il trempe depuis longtemps. J'ai exactement ce genre de problème quand je réponds à certaines de tes questions sur le système de jeu sans arriver à me faire comprendre du premier coup.

INNO SETUP
Le lancement de l'exe, génère les DLL et des fichiers .fic et ndx non listés dans l'INNO.
Du coup à la désinstallation, il ne les supprime pas. Ce sont des fichiers de base données vides au lancement.

Il n'est pas difficile, moyennant la connaissance de cette liste de fichiers (il suffit de regarder l'arborescence après installation), d'ajouter une section une section sur la désinstallation dans le fichier d'Inno Setup. Tu peux aisément vider et supprimer le répertoire Tmp ainsi que les fichiers générés dans le répertoire principal lors de l'installation.
Je renouvelle ma proposition de te fournir un fichier modifié et des explications si tu me transmets ton fichier actuel.

Documentation des champs
Je lance cette idée car quand tu débutes et que tu ouvres NI. Tu te demandes à quoi sert ce champ. Tu as le nom uniquement pour l'interprétation c'est assez bloquant pour un modeur débutant. Moi j'ai fui .

Donc une documentation dynamique dans l'éditeur me semble être un plus.

Bien entendu. Mais on doit toujours arbitrer entre l'indispensable et ce qui serait mieux (le mieux est l'ennemi du bien), quand on travaille dans un espace de temps restreint. Tes premiers testeurs, qui devront être expérimentés, pourront fort bien s'en passer voire contribuer à l'écriture.

Entre floritures et fonctionnel
Faire une interface avec des champs et listes va nécessiter du temps. Je n'apporterai rien de plus que ce qui existe déja.
Tout faire directement via la partie graphique est je pense plus économique au final car je me dirige directement sur mon objectif.

- La lecture / écriture des CRE fonctionne.
- J'arrive à afficher des BAM non animées.
- Je peux lire / écrire dans des ITM, SPL et TLK.
- je viens de créer la partie traduction qui fonctionne.

Je n'ai pas parlé de fioritures pour ces aspects-là, mais à propos de

Equipement
On pourra:
- rechercher, ajouter, supprimer, (dé)placer et décrire des objets dans l'équipement. Les restrictions de type d'objet et de kit seront gérées.

- l'évolution des caractéristiques de même si c'est possible (THACO, CA etc...)

- autre?

La gestion des sorts sera dans le même ordre d'idée. J'ai pas encore réfléchi dans le détail.

Rechercher, décrire, voire déplacer (= supprimer puis ajouter ailleurs) des objets dans l'équipement d'une créature n'est pas du domaine de l'indispensable. D'ailleurs je ne comprends pas pourquoi tu évoques la description, qui relève de la création d'objet, pas de la gestion de l'inventaire.
Gérer les restrictions de type d'objet, en tenant compte des kits sera un sacré boulot qui t'obligera à recoder une partie du moteur de jeu, impliquant l'interprétation de nombreux fichiers 2DA, de façon dynamique car elle dépendra de la présence ou non de kits venant de mods dans l'arborescence choisie par le moddeur.
Idem pour la question des caractéristiques.

Alors qu'il suffirait d'exporter la créature au format CHR (éventuellement avec un autre éditeur) pour qu'on puisse l'importer dans le jeu en tant que PJ et voir tout ça (compatibilité d'objet, TACO, CA, au moins).

Ce qui manque c un test de fichier traité dans l'éditeur, intégré dans le jeu et voir si ca fonctionne.

Souhaites-tu que quelqu'un le fasse ou veux-tu le faire toi-même ?

Se passer de WEIDU
Tu abordes une 2nd fois ce sujet et je ne vois toujours pas comment se passer de l'extraction du fichier par WEIDU.

Je lis les données du fichier KEY (que je n'ai pas étudié). Mais comment dire au moteur, de m'extraire le fichier?

Pour ce qui est de créer ma base de données à l'installation. J'ai pensé proposer cette solution. L'install va être longue si on doit lire et charger les ITM et BAM.

NI est très rapide mais il n'a pas besoin de charger x fichiers suite à une demande du moddeur pour avoir 'la liste de toutes les armures du jeu en icône avec la description de l'armure".

En allant même plus loin, on peut tout charger dans ce cas. Mais je pense qu'on en a pour un bon moment. A voir.
En tout cas le résultat est alléchant. Tout en base de données et les fichiers modés dans \mod, le rêve.

Near Infinity ne charge absolument aucun fichier. Sa base de données est exclusivement en mémoire, lors de l'exécution, et constitué au démarrage. Il ne précharge aucun fichier. Tout ce que font Near Infinity, DLTCEP et Shadow Keeper (qui a aussi un éditeur de créature), c'est lire le fichier chitin.key et le contenu du répertoire Override pour constituer une liste des fichiers du jeu et, pour ceux qui ne sont pas dans Override, une table d'index permettant de savoir dans quel fichier BIF et à quelle position à l'intérieur débute le "fichier" (la structure de données).
Quand Near Infinity ont besoin d'un fichier, il leur suffit de chercher dans cette table interne pour ensuite lire le contenu du fichier BIF ou le fichier sur disque. Ce temps de traitement passe généralement inaperçu.

WeiDU fait cette indexation, mais à chaque fois que tu fais appel à lui, donc potentiellement pour chaque fichier. Ce qui explique que certaines opérations puissent paraître lentes avec l'éditeur.

Se passer de WeiDU, cela veut dire savoir lire le fichier KEY et le répertoire Override, constituer la liste de fichiers dont je parlais, d'une manière intelligente pour faciliter le parcours (avec plus de 40 000 fichiers dans ToB, il vaut mieux savoir parcourir vite la liste, histoire d'éviter de tourner toutes les pages du dictionnaire pour trouver "zouave"), et enfin de savoir lire un contenu à l'intérieur d'un fichier BIF.
Ce n'est peut-être pas trivial dit comme ça mais cela me semble loin d'être aussi compliqué que la réécriture du moteur de jeu nécessaire à la vérification de la capacité d'un personnage à utiliser un objet.
Je dois avoir sur mon disque dur un programme jamais achevé pour lequel j'avais codé une bonne partie de la gestion des fichiers KEY et BIF, qui est passé aux oubliettes pour tout un tas de raisons. De sorte que je pourrai au moins répondre à tes questions pour toute la manipulation des fichiers.

Si il existe une rubrique sur les connaissances du jeu, on pourrait p.e alimenter par domaine cette dernière de nos discussions.
Je pourrais poser mes questions connaissances dessus et traiter ici uniquement les sujets liés à l'ergonomie / graphisme de l'éditeur.

Si tu le souhaites, tu peux demander à ce qu'on crée une section dédiée à ton éditeur dans Le coeur de la forge. Je peux relayer ta demande auprès des administrateurs seuls habilités à le faire. Tu serais alors modérateur de cette section, avec toute latitude pour découper les sujets comme tu le juges nécessaire.

[Cocrane]

Une pause dans mes travaux d'intérieurs (grattage, enduit, ponçage et peinture) avant la ligne droite demain dans la journée!
Tout ça pour un dégât des eaux!

> Luren
Merci pour ta participation.

Le lien n'est pas disponible:
"Ce fichier est temporairement indisponible. Ré-essayez plus tard."

> Isaya
La communication, se faire comprendre. J'ai toujours eu ce problème avec mes ex petites amies! .

InnoSetup
ok je t'envoie demain un lien demain. A noter, l'éditeur n'est pas terminé donc de nouveaux fichiers peuvent apparaître.

Equipement et sélection
Je viens de jeter un coup d'oeil à Shadow Keeper qui est pas mal.
Je propose un bouton dans la fenêtre équipement qui fait apparaître une fenêtre de recherche dans le style Shadow.

Tu filtres pour trouver l'objet que tu veux. Ensuite tu fais glisser l'icône objet sur la fenêtre équipement à la position que tu veux. (je sais c pas indispensable )

Filtres possibles:
- type d'objet
- texte contenu dans le nom de l'objet

Pour la description, le but est de choisir son objet en prenant connaissance de ses capacités.

Sélection d'objet et restriction de Kit
Je veux juste signaler ou bloquer le placement d'un objet sur une position si le Kit l'interdit comme dans le jeu.
Il se passe quoi dans le jeu si on mode un CRE qui ne respecte pas cette règle?

Test BG
Je ne connais comment installer un fichier dans le jeu. Pour moi, il "suffit" pour les CRE de le mettre dans l'override. Mais je suppose que c'est plus compliqué.

Le test a faire serait:
- d'ouvrir un CRE
- de le sauvegarder
- de l'installer dans le jeu
- de s'assurer que tout est conforme.

si quelqu'un est dispo pr faire le test, ça me va.

A noter, j'ai un doute sur la partie Effet.

Se passer de Weidu
J'ai pris note de ton explication.

Dc grace au fichier Key. Je détermine quel est le fichier BIFF à lire. Je lis les données, CRE ou autre, qui m'intéresse

De ce que je vois dans Shadow, la lecture m'a l'air très rapide. Je suis donc sans doute pessimiste sur la capacité de l'éditeur à charger et afficher les données en temps réel.

Nouvelle section
Je propose pas une section sur mon éditeur mais une section connaissance tech du jeu. On a abordé de nombreux sujets qui sont mélangés au fil des discussions.
Je me disais qu'il serait p.e intéressant de faire une base de connaissance. Sauf si elle existe déjà.

Coco

[Isaya]

J'ai pu télécharger le fichier de Luren. Peut-être devrais-tu essayer à nouveau ? Ou alors, serais-tu chez Orange, qui est en train d'échanger des coups avec Mega Upload pour savoir qui est responsable des problèmes observés par les abonnés Orange pour télécharger chez Mega Upload ?

Je ferai un essai de créature dans le jeu, ce week-end. Je te tiendrai au courant.

La section "référence technique" n'est pas facile à organiser sur un forum, qui n'est pas l'idéal pour les liens. L'idéal serait plutôt un Wiki. On peut néanmoins exploiter la section sur les outils et tutoriels pour créer des sujets de ce type.

Bonne courage pour tes travaux. J'ai connu un dégât des eaux (même deux, mais mineur la deuxième fois, à cause du chauffe-eau), c'est vraiment pénible, mais je m'en étais plutôt bien tiré (au printemps, par beau temps, j'avais pu tout faire sécher sans véritables dégâts sinon les pieds de certains meubles).

[Luren]

Cocrane :
Je me disais qu'il serait p.e intéressant de faire une base de connaissance. Sauf si elle existe déjà

Il en existe déjà une, en anglais, c'est l'IESDP (Infinity Engine Structures Database Project, téléchargable pour être facilement consultable hors ligne, sur le forume The Gibberlings Three : The Gibberlings Three Forums). Personnellement, j'en m'en suis servi de point de départ pour y réunir des infos et des notes. Elle est mise à jour à un rythme qui va decrescendo depuis quelque temps, mais est vraiment bien complète et traite tous les formats de fichier que l'on rencontre avec ce moteur.
Mais rien n'empêche d'en faire une en français, si cela peut aider les moddeurs français...

Pour les problèmes de téléchargement du fichier que j'ai mis en partage sur Mega Upload : il faut juste perséverer, et repasser un peu plus tard. C'est un problème qu'il n'est pas rare de rencontrer avec ce type serveur.

Bon courage pour tes travaux !

[Isaya]

Je ne connais comment installer un fichier dans le jeu. Pour moi, il "suffit" pour les CRE de le mettre dans l'override. Mais je suppose que c'est plus compliqué.

Le test a faire serait:
- d'ouvrir un CRE
- de le sauvegarder
- de l'installer dans le jeu
- de s'assurer que tout est conforme.

si quelqu'un est dispo pr faire le test, ça me va.

Pour installer un fichier dans le jeu, il faut le mettre dans le répertoire Override. C'est le minimum. Il peut être nécessaire de faire davantage : ajouter les textes (nom, bio, ...) au fichier dialog.tlk, ajouter éventuellement les autres fichiers qu'il exploite (par exemple de nouveaux objets du mod sur une créature du mod), etc. (si la créature a un kit perso, un doublage sonore, ...)

Je viens d'essayer, de deux façons différentes, à partir de créatures de ToB, et je fais planter l'éditeur au moment de la sauvegarde. J'ai une fenêtre indiquant "Le mécanisme de sécurité du WLanguage a détecté une erreur dans l'application BG_editeur. Contactez le fournisseur de l'application BG_editeur. Afin de l'aider à corriger l'erreur, veuillez lui transmettre les informations accessibles par le bouton 'Copier'."
Voici ces informations (identiques les deux fois, à part l'heure)

Code : Tout sélectionner

Erreur à la ligne 34 du traitement Procédure globale BG_compile.
Vous avez appelé la fonction HLitPremier.
Fichier <CRE_tmp_Header_> inconnu dans l'analyse <D:\jeux\BG\BG_editeur\BG_editeur.wdd>, ou requête ou vue non initialisée.

Informations techniques

Projet : BG_editeur

Dump de l'erreur du module <WD110HF.DLL> <11.00Dbb>.

- Appel WL :
Traitement de <Procedures globales de BG_editeur.BG_compile>, ligne <34>, thread <0>
Fonction <HLitPremier>, n° de syntaxe <3>

- Niveau : erreur fatale (EL_FATAL)

- Code erreur : 70018

- Code erreur WD55 : 18

- Pas de code d'erreur système

- Pas de message d'erreur système

- Que s'est-il passé ?
Fichier <CRE_tmp_Header_> inconnu dans l'analyse <D:\jeux\BG\BG_editeur\BG_editeur.wdd>, ou requête ou vue non initialisée.

- Infos de debug :
iehf=1001
Fonction (7,10)

- Infos attachées :
EIT_PATHWDD : <D:\jeux\BG\BG_editeur\BG_editeur.wdd>
EIT_LOGICALTABLENAME : <CRE_tmp_Header_>
EIT_DATEHEURE : 21/01/2011 22:57:48
EIT_PILEWL :
Procédure globale BG_compile (Procedures globales de BG_editeur.BG_compile), ligne 34
Procédure globale fichier_BG_enregistrer (Procedures globales de BG_editeur.fichier_BG_enregistrer), ligne 42
Procédure globale fichier_BG_enregistrer_sous (Procedures globales de BG_editeur.fichier_BG_enregistrer_sous), ligne 13
Sélection du menu de _Menu.CREATURE.CRE_Enregistrer_sous (FEN_mere._Menu.CREATURE.CRE_Enregistrer_sous), ligne 2

- Identifiant dans le .err : 70116


Assistance

Quelques détails sur ce que j'ai fait.

Dans un premier temps, j'ai chargé le fichier BALTH.CRE dans l'éditeur à partir de la "liste BASE". L'éditeur ne me permettant de sauvegarder ou de sauvegarder sous (j'ai découvert par la suite que c'était parce que je n'avais fait aucun changement), j'ai changé de fusil d'épaule. J'ai exporté ce fichier à partir de Near Infinity et je l'ai placé dans mon répertoire de mod sous le nom I=BALTH.CRE. J'ai pu l'ouvrir à partir de l'éditeur et je l'ai enregistré sous I=BALTH2.CRE, sans avoir fait de modification pourtant. C'est alors que l'éditeur s'est planté.

Pour mon deuxième essai, j'ai chargé le fichier ABAZIGAL.CRE à partir de la "liste BASE". J'ai augmenté la valeur d'XP (ajouté un 0) et ajouté 10 points de vie (passé à 300). A la sauvegarde sous le nom I=ABAZ.CRE, même crash.

Enfin, au cas où les gros boss de ToB ne soient trop particuliers (ce sont à peu-près les seuls qui exploitent vraiment les compétences martiales et les capacités de haut niveau), j'ai essayé avec un simple personnage de SoA : KPMAID01.CRE (Chanelle la servante au château d'Arnise).
Toujours à partir de "liste BASE", sans faire de modification avant d'enregister sous le nom I=CHAN.CRE. Crash également, mais cette fois, le fichier de traces diffère légèrement

Code : Tout sélectionner

Erreur à la ligne 34 du traitement Procédure globale BG_compile.
Vous avez appelé la fonction HLitPremier.
Fichier <CRE_tmp_Header_EFF_V2P0> inconnu dans l'analyse <D:\jeux\BG\BG_editeur\BG_editeur.wdd>, ou requête ou vue non initialisée.

Informations techniques

Projet : BG_editeur

Dump de l'erreur du module <WD110HF.DLL> <11.00Dbb>.

- Appel WL :
Traitement de <Procedures globales de BG_editeur.BG_compile>, ligne <34>, thread <0>
Fonction <HLitPremier>, n° de syntaxe <3>

- Niveau : erreur fatale (EL_FATAL)

- Code erreur : 70018

- Code erreur WD55 : 18

- Pas de code d'erreur système

- Pas de message d'erreur système

- Que s'est-il passé ?
Fichier <CRE_tmp_Header_EFF_V2P0> inconnu dans l'analyse <D:\jeux\BG\BG_editeur\BG_editeur.wdd>, ou requête ou vue non initialisée.

- Infos de debug :
iehf=1001
Fonction (7,10)

- Infos attachées :
EIT_PATHWDD : <D:\jeux\BG\BG_editeur\BG_editeur.wdd>
EIT_LOGICALTABLENAME : <CRE_tmp_Header_EFF_V2P0>
EIT_DATEHEURE : 21/01/2011 23:30:26
EIT_PILEWL :
Procédure globale BG_compile (Procedures globales de BG_editeur.BG_compile), ligne 34
Procédure globale fichier_BG_enregistrer (Procedures globales de BG_editeur.fichier_BG_enregistrer), ligne 42
Procédure globale fichier_BG_enregistrer_sous (Procedures globales de BG_editeur.fichier_BG_enregistrer_sous), ligne 13
Sélection du menu de _Menu.CREATURE.CRE_Enregistrer_sous (FEN_mere._Menu.CREATURE.CRE_Enregistrer_sous), ligne 2

- Identifiant dans le .err : 70116


Assistance

Remarques sur l'éditeur en mode "liste BASE" ou "liste BRUTE":

• dans l'onglet "Stats", les points de vie sont dupliqués au chargement dans la cellule appelée Armor_Class_Effect, juste en dessous de Current_Hit_Point. C'est peut-être une cause de problème : Balthazar a 280, ce qui dépasse 256 et peut causer des problèmes si le champ Armor_Class_Effect est limité à 8 bits. Mais Chanelle n'a que 7, donc ça n'explique pas le crash en soi.
• la liste des créatures est pénible à manipuler (idem en "liste BRUTE") : quand on tire le curseur de la barre de défilement, l'affichage de la liste ne suit pas et ne se rafraîchit que si on relâche le curseur. C'est donc difficile de s'arrêter là où on voudrait (viser le KPxxxx n'était pas facile )
• dans l'onglet "Script/Etat", la table des états se place à droite (est-ce une erreur) et se superpose aux "Caractéristiques" qui restent toujours affichées. Elle suit le redimensionnement de la fenêtre, contrairement au reste des affichages. Globalement cette page est en partie vide à gauche mais trop chargée à droite.
• Dans les onglets de sorts et d'objets (mode liste BRUTE), les quelques lignes d'un sort ou d'un objet sont tout en haut du tableau, mais les boutons de déplacement sont en bas à gauche et le repérage n/M en bas à droite, de sorte qu'on a du mal à se rendre compte de leur présence. Le mieux serait que tu mettes les boutons et le repérage juste au dessus de la table, ainsi tout serait rassemblé.
  C'était ce que je voulais proposer en bidouillant des captures d'écrans, mais j'ai renoncé à le faire (c'était pénible). Si ce n'est pas clair, je ferai un dessin avec des flèches pour l'expliquer.

Dans l'éditeur graphique, j'ai rencontré quelques soucis (probablement des choses non achevées) et j'ai aussi quelques remarques / suggestions

• Malheureusement, il ne semble pas possible de visualiser une créature choisie dans la liste affichée à droite.
• Cette liste contient des noms suivis d'une étoile, pourtant ces fichiers ne sont pas, comme tu l'indiquais quelque part (à tort ?), dans le répertoire du Mod. Je suppose qu'ils viennent du répertoire Override.
• La liste des classes indique Loyal bon partout et la sélection ne fonctionne pas (heureusement).
• Les tables de résistance ou de compétence en arme utilisent des boutons pour commuter entre deux pages, peu visibles et détonants. Vas-tu les remplacer par une barre de défilement (comme c'est fait dans le jeu) ?
• La page des "Etats", bien que probablement inutile , comporte une erreur : "Normal" correspond au fait qu'aucune des cases n'est cochée, ce n'est pas en soit une case à cocher (en gros, elle correspond à "désélectionner tout").
• On ne "voit" pas quel est la sélection courante dans les fenêtres de race, alignement et sexe (certes, pour ce dernier, on voit que ça bouge quand on clique, mais on n'arrive pas à repérer lequel est actuellement choisi).
• J'ai observé un bug dans les talents de voleur : j'ai pu descendre les points restants à attribuer en négatif !
• L'écran de biographie affiche la réputation et des boutons pour la modifier. D'une part, c'est bizarre de la trouver là et d'autre part, il ne sert strictement à rien de changer la réputation ! Elle est inexploitée dans le fichier CRE et ne sert que pour le personnage principal et c'est alors dans le fichier de sauvegarde (GAM). Bref, çe ne sert à rien là.

Il est toujours plus facile de voir ce qui cloche mais je n'en remarque pas moins que la partie graphique est bien intégrée et donne vraiment l'impression de marcher comme dans le jeu : les étoiles des compétences, la barre de défilement du texte dans cette même fenêtre, ...
Je n'aime pas trop la police de caractères dans la partie graphique, surtout celle des fenêtres de liste (race, compétences, ...) trop grande et trop épaisse à mon goût, et qui du coup ne colle pas bien avec ce qu'on a dans le jeu. De même, le fait que tout soit en majuscules ne m'est pas très agréable. Mais le jeu affiche aussi beaucoup de textes en petites capitales où les minuscules se distinguent peu des majuscules. Question de goût, sans doute.

Je suis à ta disposition si tu as besoin de précisions supplémentaires sur les essais que j'ai menés.

Bonne continuation.

[Cocrane]

> Luren / Isaya
Je viens te tenter une nouvelle fois de DL ton document de traduction sans succès. Je suis abonné à Orange...

Je me suis beaucoup servi de Gibberlings qui est indispensable, je pense, pour connaitre la structure des fichiers. Malheureusement, Je n'ai pas le niveau en anglais pour aider à alimenter cette base de données.

Je pense simplement que les 100 et plus échanges que nous avons eu dans cette rubrique contiennent un grand nombres d'informations techniques sur BG qu'il serait intéressant de résumer et classer. Concrètement, je n'ai pas d'idée claire sur le meilleur choix concernant la mise en forme.


> Isaya

L'éditeur te devra une fière chandelle! Cependant n'oublies pas que je ne dois pas être poursuivi par une facture!

Effectivement un certain nombre de points sont en chantier même si j'ai laissé l'accès à la plupart des menus à l'utilisateur. La version envoyée avait pour but d'avoir votre retour sur les graphismes. A savoir si c'était une bonne piste ou non. D'où la question sur l'ergonomie.

A noter, le menu 'BASE' ne sera pas conservé compte tenu que la partie graphique va afficher les mêmes champs mais de manière plus agréable.


Les Tests de sauvegarde
Visiblement, il y a une régression depuis mes derniers tests. Après recherche, j'ai fait le ménage il y a quelques temps dans les tables de ma base de données. J'ai supprimé à tord les tables CRE 'EFF' qui me semblait à ce moment là inutiles:
- CRE_tmp_Body_EFF_V1P0
- CRE_tmp_Header_EFF_V2P0

Elles sont au sens de la structure de BG inutiles:
- en version 1, on a une section Header pour l'EFF.
- en version 2, on a une section Body pour l'EFF.

On avait parlé de ce sujet, il y a déjà un moment. Par défaut, mon programme a besoin de savoir que ces tables existent même si je ne m'en sers pas. Constatant qu'elles sont vides, il passe à la section suivante.
Fonctionnement pourrait être amélioré dans mon code. Mais "le mieux est l'ennemi du bien".

Je confirme que pour moi, un fichier CRE avec effets sauvegardé avec l'éditeur présente des anomalies sur cette section. En comparant, le fichier source et sauvegardé, je constate des différences.
> il faut que j'enquête sur ce point.

J'aurais dû vérifier avant de demander un essai. Désolé pour le temps perdu.



"
dans l'onglet "Stats", les points de vie sont dupliqués au chargement dans la cellule appelée Armor_Class_Effect, juste en dessous de Current_Hit_Point. C'est peut-être une cause de problème : Balthazar a 280, ce qui dépasse 256 et peut causer des problèmes si le champ Armor_Class_Effect est limité à 8 bits. Mais Chanelle n'a que 7, donc ça n'explique pas le crash en soi.
"
> Le mauvais affichage existe uniquement dans la partie "Base" qui va disparaitre.


"
la liste des créatures est pénible à manipuler (idem en "liste BRUTE") : quand on tire le curseur de la barre de défilement, l'affichage de la liste ne suit pas et ne se rafraîchit que si on relâche le curseur. C'est donc difficile de s'arrêter là où on voudrait (viser le KPxxxx n'était pas facile )
"
>Bonne remarque. J'avais jamais fait attention. Quand je cherche, un fichier, je commence à taper son nom et le programme se place sur la bonne cellule au fur et à mesure. L'option pour afficher la cellule en cours de déplacement est activée.


"
dans l'onglet "Script/Etat", la table des états se place à droite (est-ce une erreur) et se superpose aux "Caractéristiques" qui restent toujours affichées. Elle suit le redimensionnement de la fenêtre, contrairement au reste des affichages. Globalement cette page est en partie vide à gauche mais trop chargée à droite.
"
> Partie "Base" en total bordel.

"
Dans les onglets de sorts et d'objets (mode liste BRUTE), les quelques lignes d'un sort ou d'un objet sont tout en haut du tableau, mais les boutons de déplacement sont en bas à gauche et le repérage n/M en bas à droite, de sorte qu'on a du mal à se rendre compte de leur présence. Le mieux serait que tu mettes les boutons et le repérage juste au dessus de la table, ainsi tout serait rassemblé.
C'était ce que je voulais proposer en bidouillant des captures d'écrans, mais j'ai renoncé à le faire (c'était pénible). Si ce n'est pas clair, je ferai un dessin avec des flèches pour l'expliquer.
"
> J'ai refait un test avec mon nouvel écran 23 pouces (fini le tube ), les positions ne me gênent pas. Mais je peux modifier l'agencement comme tu le proposes.

"Malheureusement, il ne semble pas possible de visualiser une créature choisie dans la liste affichée à droite.
"
> En cours comme beaucoup trop de choses.

"Cette liste contient des noms suivis d'une étoile, pourtant ces fichiers ne sont pas, comme tu l'indiquais quelque part (à tort ?), dans le répertoire du Mod. Je suppose qu'ils viennent du répertoire Override."
> Exact j'ai dit une connerie.
* Pour \Override
M Pour \Mod

"
La liste des classes indique Loyal bon partout et la sélection ne fonctionne pas (heureusement).
"
> oui, il faut que je bosse la correspondance des classes et Kit pour les PNJ. J'ai bien fait de ne pas aborder le sujet trop vite finalement car je me suis aperçu que Class.IDS est très chargé. J'ai complètement zappé les class créatures type 'monstres'.

"
Les tables de résistance ou de compétence en arme utilisent des boutons pour commuter entre deux pages, peu visibles et détonants. Vas-tu les remplacer par une barre de défilement (comme c'est fait dans le jeu) ?
"
> J'attends qu'un ami me transforme les boutons +/- rouge et des boutons de couleur 'marron'.
Pour le défilement, c'est beaucoup plus compliqué à gérer avec ascenseur et multilangues.
Donc pour garder les graphismes du jeu, j'ai opté pour des pages pour avoir un champ affichable par information à gérer.

"La page des "Etats", bien que probablement inutile , comporte une erreur : "Normal" correspond au fait qu'aucune des cases n'est cochée, ce n'est pas en soit une case à cocher (en gros, elle correspond à "désélectionner tout").
"
> Oui je m'en souviens mais j'ai zappé à la réalisation.

"
On ne "voit" pas quel est la sélection courante dans les fenêtres de race, alignement et sexe (certes, pour ce dernier, on voit que ça bouge quand on clique, mais on n'arrive pas à repérer lequel est actuellement choisi).
"
> En version de dev, tu as comme dans le jeu, le cadre orange autour du champ sélectionné après sélection ou à la réouverture si tu as mémorisé ton choix. Je viens de constater que dans le pack livré ca marche pas. Pourtant le fichier .bmp avec le cadre orange est bien dans le pack.
Je vais enquêter.

A noter, à terme, je pense qu'il serait plus intelligent d'avoir les graphismes en .jpg pour éviter une consommation de mémoire inutile.

"
J'ai observé un bug dans les talents de voleur : j'ai pu descendre les points restants à attribuer en négatif !
"
> non c'est pas un bug. Tu es simplement un très mauvais voleur!
J'ai pas mis de contôle sur les valeurs négatives. A faire.

"
L'écran de biographie affiche la réputation et des boutons pour la modifier. D'une part, c'est bizarre de la trouver là et d'autre part, il ne sert strictement à rien de changer la réputation ! Elle est inexploitée dans le fichier CRE et ne sert que pour le personnage principal et c'est alors dans le fichier de sauvegarde (GAM). Bref, çe ne sert à rien là.
"
> Tiens voilà un nouveau fichier. Le GAM. Hum hum
C'est noté que même pour le personnage principal c'est inutile de le gérer dans le CRE.
Conclusion, en gros je le supprime définitivement?


Conclusion
Il y a encore pas mal de taff sur la partie créature. Je vais essayer d'avancer sur le fichier KEY et BIFF pour voir la rapidité de gestion sur l'équipement.



Pour les dégâts des eaux, c'était juste le 3ième en 2 ans 1/2. Toujours à cause du voisinage: 2 dans la salle de bain et un dans la chambre.

Je me suis renseigné pour savoir comment mettre la pression au voisin 'salle de bain' qui a une tuyauterie qui fait peur. Dans le pire des cas, son assurance lui signalera d'en trouver une autre...

On était à 3, on a refait entièrement la chambre et le bureau en 3j. N'étant pas bricoleur, j'ai appris. C'est toujours ça de gagné.

Coco

[Luren]

Je viens te tenter une nouvelle fois de DL ton document de traduction sans succès. Je suis abonné à Orange...

J'ai mis le fichier en partage dans les section download de mon blog :
Accueil - Icewind Dale II - Retour à Havredest

[Cocrane]

> Luren
Mon nom est sur ton Site! Wouaaahouu j'suis célèbre!


J'ai jeté un oeil. C'est du super boulot. Merci

A mon avis, il va s'intégrer sans soucis. Je te fais un retour sous peu.

> Isaya
j'ai crée les tables pour recevoir les données du fichier KEY.

Le but est de cliquer sur un nom de fichier BG et d'afficher son contenu sans passer par Weidu.


Structure annoncée du fichier KEY sur iesdp
# Header
# Bif indices
# Strings referenced by Bif indices (structure non détaillée)
# Resource indices

Au niveau du header, j'ai:
Count of BIF entries 258
Count of resource entries 47977

Offset to BIF entries 24
Offset to resource entries 7712

Quelle est la bonne démarche d'après toi?

De ce que je pense avoir compris:
1- Le nom du fichier est à lire est contenu la section "resource entries" à 'Resource name'

A noter: 'Resource type' me donne des valeurs numériques comme '1014'. Je m'attendais à l'extension du nom du fichier. Il y a une table de correspondance?

2-à un 'Resource name' correspond un 'Resource locator ' qui me donne la position à lire dans Bif entries.

"
0x000a 4 (dword) Resource locator. The IE resource manager uses 32-bit values as a 'resource index',
* which codifies the source of the resource as well as which source it refers to. The layout of this value is below.
* bits 31-20: source index (the ordinal value giving the index of the corresponding BIF entry)
* bits 19-14: tileset index
* bits 13- 0: non-tileset file index (any 12 bit value, so long as it matches the value used in the BIF file)
"

Je n'ai pas compris la signification des éléments issus du découpage du champ mais on obtient un lien avec la section 'Bif entries' me permettant de connaitre le nom du fichier bif à traiter et sa localisation sur le disque.

Si je charge tout le contenu du fichier KEY, j'en ai pour un bon bou de temps. Resource entries contient plus de 47 000 lignes.

Coco

[Isaya]

Je pense simplement que les 100 et plus échanges que nous avons eu dans cette rubrique contiennent un grand nombres d'informations techniques sur BG qu'il serait intéressant de résumer et classer. Concrètement, je n'ai pas d'idée claire sur le meilleur choix concernant la mise en forme.

Le problème est toujours le même : qui va faire ce boulot de synthèse ? Si ce doit être le modérateur (i.e. moi), bof...
Il faudrait trouver une meilleure solution, d'autant qu'un forum n'est pas du tout adapté à des liens hypertextes, alors que des pages HTML ou un Wiki permettent des liens vers un chapitre particulier. Je vais en discuter avec les administrateurs.

L'éditeur te devra une fière chandelle! Cependant n'oublies pas que je ne dois pas être poursuivi par une facture!

J'ai changé d'avis sur ce point. Je vais désormais exiger un pourcentage sur les bénéfices, comme dans toute bonne startup ! Pas sûr que ça donne grand chose.

Je confirme que pour moi, un fichier CRE avec effets sauvegardé avec l'éditeur présente des anomalies sur cette section. En comparant, le fichier source et sauvegardé, je constate des différences.
> il faut que j'enquête sur ce point.

J'aurais dû vérifier avant de demander un essai. Désolé pour le temps perdu.

Je n'ai pas compris tes explications, qui sont sans doute liés au fonctionnement interne de l'éditeur. Aucune importance. L'essentiel est que tu saches comment corriger le problème.

> J'ai refait un test avec mon nouvel écran 23 pouces (fini le tube ), les positions ne me gênent pas. Mais je peux modifier l'agencement comme tu le proposes.

J'ai un 24 pouces. Et en plein écran, mes yeux doivent parcourir plus de 30 cm pour passer de l'information du sort à l'indication 1/N et presque autant pour atteindre les boutons de déplacement en bas de l'écran. Même si c'est faisable, ce n'est pas du tout ergonomique. Quoi que le programmeur (dieu) en pense !
Je t'invite à te méfier de ne pas concevoir une interface qui nécessite un 23 pouces. Tu as tout intérêt à t'assurer que ça fonctionne bien en 1280x1024 qui est encore probablement la résolution type de la plupart des gens avec des PC de bureau, voire encore moins étant donné que la moitié des ordinateurs vendus sont des portables (avec du 1280x800 ou 1366x768 selon leur âge).

> oui, il faut que je bosse la correspondance des classes et Kit pour les PNJ. J'ai bien fait de ne pas aborder le sujet trop vite finalement car je me suis aperçu que Class.IDS est très chargé. J'ai complètement zappé les class créatures type 'monstres'.

Oui, un éditeur de créature ne sert pas qu'à la création de PNJ recrutable.
Le cas échéant, tu pourrais envisager de réduire la liste aux classes "normales" si la race est une de celles qui sont jouables (voilà que je suggère des fioritures, maintenant ).

Pour le défilement, c'est beaucoup plus compliqué à gérer avec ascenseur et multilangues.
Donc pour garder les graphismes du jeu, j'ai opté pour des pages pour avoir un champ affichable par information à gérer.

Je suis un peu étonné que tu évoques une grande complication, mais je te fais confiance. Et ce n'est pas moi qui vais t'inciter à perdre du temps sur une chose dispensable.

> non c'est pas un bug. Tu es simplement un très mauvais voleur!

Bien au contraire ! Il avait réussi à s'attribuer davantage de points qu'il n'avait droit !

> Tiens voilà un nouveau fichier. Le GAM. Hum hum
C'est noté que même pour le personnage principal c'est inutile de le gérer dans le CRE.
Conclusion, en gros je le supprime définitivement?

Oui, tu peux supprimer. Un éditeur comme Shadow Keeper le fait apparaître car il faut bien qu'il permette au joueur tricheur de modifier aussi ce paramètre.
Le fichier GAM contient l'état en cours du jeu (temps écoulé, endroit où se trouve les personnages recrutables, toutes les statistiques ainsi que des structures CRE pour tous les personnages recrutables afin de garder trace de leur état au moment de la sauvegarde.
Un moddeur n'a jamais besoin d'y toucher, à moins qu'il ne veuille créer une toute nouvelle aventure avec des personnages tout à fait différent (les fameuses mais rares "Total Conversion").

1- Le nom du fichier est à lire est contenu la section "resource entries" à 'Resource name'

A noter: 'Resource type' me donne des valeurs numériques comme '1014'. Je m'attendais à l'extension du nom du fichier. Il y a une table de correspondance?

La table est tout simplement sur IESDP.
Pour constituer un index unique, il faut tenir compte du nom de ressource et de son type. Tu trouveras beaucoup de "resource name" identique : la créature, le dialogue, le script, ..., qui vont se distinguer par des types différents.

2-à un 'Resource name' correspond un 'Resource locator ' qui me donne la position à lire dans Bif entries.

"0x000a 4 (dword) Resource locator. The IE resource manager uses 32-bit values as a 'resource index',
* which codifies the source of the resource as well as which source it refers to. The layout of this value is below.
* bits 31-20: source index (the ordinal value giving the index of the corresponding BIF entry)
* bits 19-14: tileset index
* bits 13- 0: non-tileset file index (any 12 bit value, so long as it matches the value used in the BIF file)"

Je n'ai pas compris la signification des éléments issus du découpage du champ mais on obtient un lien avec la section 'Bif entries' me permettant de connaitre le nom du fichier bif à traiter et sa localisation sur le disque.

La partie "source index" indique, dans la table "KEY V1 Bif Entries", le numéro du fichier BIF (ce qui permettra d'obtenir son nom et le répertoire dans lequel il se trouve). Le fait qu'il y ait 12 bits signifie qu'on ne peut pas avoir plus de 4096 fichiers BIF (il y a de la marge).
La notion de "tileset" est lié au fichier TIS qui constitue l'image de fond d'une carte du jeu (là ou tu déplaces le groupe). Ces fichiers sont traités de façon particulière à l'intérieur des fichiers BIF. La valeur "tileset index" n'a de sens que si le fichier est de type TIS.
La valeur "non-tileset file index" sert pour tous les autres types de fichiers.

Ces deux valeurs, "tileset index" et "non-tileset file index" servent à faire la recherche de la structure dans les tables du fichier BIF, soit "BIFF V1 Tileset Entries", soit "BIFF V1 File Entries", qui correspond à ce que tu souhaites (on y retrouve cet index, qu'il faudra comparer). Un fois trouvé la structure de même valeur d'index dans le fichier BIF, cela permettra de savoir où commencent les données du fichier à extraire et leur taille dans le fichier BIF.

Remarque sur l'emplacement des fichiers : les emplacements de type CD renvoient à ce qui est indiqué pour CD1..6 dans le fichier Baldur.ini, qu'il faudra donc avoir interprété pour connaître le répertoire de départ pour la recherche. Sachant que les fichiers seront ensuite toujours dans un sous-répertoire Data ou Movies (cas particulier que tu pourras ignorer).
Tu pourras aussi sans doute ignorer le cas du bit "Cache" : je pense que c'est une donnée uniquement gérée en mémoire par le jeu, qui lui permet de savoir s'il a copié le fichier dans le répertoire cache (le jeu y copie le fichier depuis un CD ou y décompresse les fichiers de type BIFC). Il n'est probablement jamais actif dans le fichier KEY.

Si je charge tout le contenu du fichier KEY, j'en ai pour un bon bou de temps. Resource entries contient plus de 47 000 lignes.

WeiDU crée ta liste de fichiers en plusieurs secondes (environ sur ma machine). Comment crois-tu qu'il fait pour obtenir cette liste ? Ton défi est donc de faire à peu-près aussi bien que lui.
Etant entendu que charger le fichier KEY signifie juste constituer la liste des fichiers contenus dans les fichiers BIF du jeu, qu'il faudra compléter par ceux trouvés dans le répertoire Override. Inutile pour cela d'ouvrir les fichiers BIF eux-même.
L'objectif est de constituer en mémoire une table de fichiers, avec les éléments pour les trouver dans le bon fichier BIF. Le plus simple est sans doute d'avoir en mémoire une image assez fidèle du fichier KEY. Par contre, pour aller vite, il te faudrait vraiment constituer un index performant sur les noms de fichiers, donc classé alphabétiquement : quand tu charges un fichier CRE et que tu veux trouver un objet qu'il porte, il faudrait éviter de parcourir les 47000 noms de fichiers pour trouver AXE.ITM, sous prétexte que dans le fichier KEY c'était le tout dernier nom (exemple bidon, mais tu vois l'idée).

[Cocrane]

> Luren
La traduction marche nickel!

Puis je tenter de profiter lâchement de la situation et soumettre une partie de la suite?
La traduction n'est pas urgente.

> Isaya
Connaissances sur le jeu
Le but n'est pas que de proposer faire ce travail de synthèse.

Il faut continuer à réfléchir sur le sujet et je suis prêt à participer au classement des informations contenues dans nos 100 échanges et plus.


"
Je n'ai pas compris tes explications, qui sont sans doute liés au fonctionnement interne de l'éditeur. Aucune importance. L'essentiel est que tu saches comment corriger le problème.
"
En clair, il y a un bug sur la sauvegarde de créature présentant des données dans la section Effets.
=> à corriger


Taille des écrans de l'éditeur
Les écrans graphiques sont limités à 800 x 600 actuellement.

Je pense que l'étirement des écrans et la mémorisation des tailles et position est souhaitable. Pour le moment, à l'étirement, l'éditeur réagit de façon mal proportionnée;
=> à corriger si c'est possible.


"
Oui, un éditeur de créature ne sert pas qu'à la création de PNJ recrutable.
Le cas échéant, tu pourrais envisager de réduire la liste aux classes "normales" si la race est une de celles qui sont jouables (voilà que je suggère des fioritures, maintenant ).
"

Finalement avant de commencer un nouveau chantier, je vais essayer de terminer la gestion de l'affichage des données sur les créatures.

J'ai adapté la sélection des classes en tenant compte du contenu du fichier Class.IDS et de la traduction de Luren et j'ai fait un joli ascenseur.
Je ferais de même avec les Races.

Il me manque je pense:
- un p'tit filtre optionnel pour visualiser uniquement les 19 classes liées à des personnages classiquement recrutables.

- un lien avec les kits pour une éventuelle sélection.

- l'affichage de la description de la classe
La description est elle contenue dans le fichier dialog.tlk? Je pense que l'indice signalé dans le fichier IDS ne correspond pas un indice TLK.

De plus, je suppose que seule les classes pouvant être sélectionnées par le charname sont décrites.
Coco

[Isaya]

Le fichier CLASS.IDS donne une correspondance entre le nom lisible et le code utilisé dans le champ de la structure CRE ou d'autres formats de fichiers.
Pour récupérer les noms et descriptions des classes, il faut chercher dans le fichier dialog.tlk, comme je l'avais déjà fait pour les états.
Pour les kits (y compris les spécialités des mages, le mage entropique et le barbare), les noms et descriptions sont récupérables à partir des numéros dans le fichier KITLIST.2DA, les colonnes LOWER (nom en minuscule), MIXED (nom commençant par une majuscule puis minuscule) et HELP (description). Ce fichier est complété par les kits de mods une fois installés.

Les personnages recrutables ont les mêmes restrictions que celles d'un personnage qu'on crée. Une exception est qu'il est possible d'affecter à un personnage recrutable un kit non sélectionnable pour le personnage principal. Le mod Chloe le fait. Mais ceci se fait toujours par l'intermédiaire de lignes de codes bien particulières dans le fichier TP2. Il n'est pas possible d'affecter un kit du mod à une créature du même mod directement avant l'installation. L'opération d'ajout du kit au jeu va permettre d'obtenir dynamiquement le code attribué au kit (en fonction de ceux déjà utilisés), qu'il faut alors patcher dans le fichier CRE (principe similaire dans l'esprit à l'attribution du numéro du texte pour la biographie).


Quand tu auras une minute, n'hésite pas à mettre à disposition le fichier d'installation pour Inno Setup afin que je regarde si je peux te proposer une amélioration pour la désinstallation.

[Cocrane]

j'ai lancé: weidu --traify-tlk --out dialog.txt

J'ai cherché une des phrases du jeu, 'Le guerrier est un champion', dont tu as accès lorsque tu choisis ta classe:

J'obtiens:
"@9556 = ~GUERRIER
Le guerrier est un champion, une fine lame, un soldat et un bagarreur. Sa connaissance des armes et des tactiques de combat sont sa raison d'être, et de vivre. Les guerriers sont au premier rang dans toutes les batailles, luttant pied à pied avec les monstres et tous ceux qui s'opposent à eux. Un bon guerrier doit être fort et en bonne santé s'il veut espérer survivre.~
"

Peux tu me confirmer que quelque soit la langue, à l'indice @9556 , j'aurais la description de la classe guerrier?
Si oui, il me suffit de repérer l'ensemble des indices dont j'ai besoin dans dialog.tlk et de le coder en dur dans l'éditeur.
Sinon en cherchant "~GUERRIER" je retrouve la description directement. Mais c'est l'échec avec "~DRUIDE"?


J'ai aussi trouvé l'indice pour la description d'un kit par exemple le Kensai
"
@25204 = ~KENSAI
Connu aussi sous le nom de "Seigneur de l'épée", ce guerrier s'entraîne pour ne plus faire qu'un avec son arme. Il est d'une terrible efficacité, rapide et entraîné pour combattre sans être encombré.
etc...
"

Si l'indice correspondant varie d'une installation à l'autre c'est plus compliqué:
"
Pour trouver ces numéros, la seule solution est de faire une recherche dans le fichier dialog.tlk en espérant que le nom n'apparaisse qu'une fois.
Problème : cette table varie d'un jeu à l'autre et certains éditeurs (Creature Maker) veulent pouvoir se passer d'un jeu installé, donc ils ne font pas ça. Je m'étais amusé à le faire pour quelques listes dans Sword Coast Keeper (spécifique à Baldur's Gate). Ce n'est pas compliqué.
"

Je peux utiliser le fichier de traduction Excel pour mettre en dur la description selon la langue compte tenu que leur nombre est fixe.

Visiblement pour les Kits du jeu et ceux modés, le problème n'existe pas vu qu'on utilise KITLIST.2DA




Affectation d'un KIT à un CRE
Ton explication me surprend et me complique le travail.

J'ai besoin d'un petit complément d'explication.

Personnage: race pour charname ou monstre du jeu

Cas 1: personnage avec un kit du jeu proposé au charname
L'affectation dans le CRE suffit ou il faut le TP2?

Cas 2: personnage avec un kit du jeu non proposé au charname
si j'ai bien compris, il faut le TP2.

Cas 3: personnage avec un kit de moddeur proposable au charname
si j'ai bien compris, il faut le TP2.

Sa valeur et son nom ne devrait pas être dans Kit.ids et paramétré dans KITLIST.2DA?
Sa description pourrait être trouvée dans dialog.txt sans ambiguité si le nom du kit est particulier. Au pire dans le fichier de traduction.

Coco

[Isaya]

Peux tu me confirmer que quelque soit la langue, à l'indice @9556 , j'aurais la description de la classe guerrier?
Si oui, il me suffit de repérer l'ensemble des indices dont j'ai besoin dans dialog.tlk et de le coder en dur dans l'éditeur.
Sinon en cherchant "~GUERRIER" je retrouve la description directement. Mais c'est l'échec avec "~DRUIDE"?

La seule différence d'une langue à l'autre est le fichier dialog.tlk. Il faut donc forcément que les traductions d'un texte soient situées au même numéro. Pas de surprise à attendre de ce côté-là.

Tu as dû mal chercher pour druide, c'est en @9560 et ça commence bien par "~DRUIDE". Toutes les classes semblent se trouver autour de ces numéros. Ainsi que les races et les caractéristiques (force, ...).
Tu pourrais prévoir un fichier externe pour stocker l'association d'une description et du numéro où elle se trouve. Cela rendrait l'éditeur plus simple à adapter à un autre jeu ou à corriger en cas d'erreur de numéro.

J'ai aussi trouvé l'indice pour la description d'un kit par exemple le Kensai

Il vaut mieux te passer d'utiliser cette méthode pour les kits. Tout simplement parce que le fichier KITLIST.2DA te le donne dans la colonne HELP (cf mon message précédent).

Si l'indice correspondant varie d'une installation à l'autre c'est plus compliqué:

Non, c'est assez simple, il "suffit" de charger le fichier KITLIST.2DA pour y récupérer la valeur du texte.
Avec l'avantage que tu obtiendras également les kits qui sont présents sur la configuration que t'a désigné le moddeur, qui peut inclure des kits de mods. Ce qui veut dire que tu seras alors capable de visualiser les créatures de ces mods dans l'éditeur en affichant le bon kit. Chose qui sera impossible si tu crées toi-même ta liste avec ce que tu trouves dans le jeu de base.

La variation d'une installation à l'autre n'existe que pour les kits ajoutés par des mods.

Je peux utiliser le fichier de traduction Excel pour mettre en dur la description selon la langue compte tenu que leur nombre est fixe.

Vu que tu as besoin d'une installation du jeu, je pense qu'il vaut mieux exploiter les textes du fichier dialog.tlk que les recopier dans un autre fichier.



Affectation d'un KIT à un CRE

Ton explication me surprend et me complique le travail.

Je ne pense pas qu'il y ait de complication pour le travail sur les créatures. A moins que tu ne veuilles compléter l'éditeur avec un créateur de kit. Et même dans ce cas, il te faudrait toujours te plier à la façon dont WeiDU va installer le kit et affecter sa "valeur" à une créature lors de l'installation.

Cas 1: personnage avec un kit du jeu proposé au charname
L'affectation dans le CRE suffit ou il faut le TP2?

Kit de base, donc numéro de kit fixe. La valeur peut être figée dans le fichier CRE et n'a pas besoin d'être retouchée lors de l'installation.

Cas 2: personnage avec un kit du jeu non proposé au charname
si j'ai bien compris, il faut le TP2.

Il n'y a aucun kit dans le jeu de base qui ne soit pas disponible pour le personnage principal. Ce cas n'existe pas.

Cas 3: personnage avec un kit de moddeur proposable au charname
si j'ai bien compris, il faut le TP2.

Les kits de mods apparaissent tous dans KITLIST.2DA, ceux disponibles pour le personnel principal mais aussi ceux réservés à un personnage de mod. Le fait qu'un kit soit accessible au personnage principal découle d'un autre fichier 2DA modifié lors de l'installation du kit. Pour plus de détails, tu peux lire le tutorial de création de kit. Tous les fichiers 2DA concernés et leur utilité sont bien décrits.
Le numéro affecté au kit est déterminé à l'installation, en fonction de l'installation du joueur. On ne peut donc pas le connaître à l'avance, c'est la raison pour laquelle WeiDU inclut un mécanisme spécifique pour reporter aisément le numéro attribué lors de l'installation de la créature (en pratique, une variable contenant la valeur à écrire au bon offset).

Sa valeur et son nom ne devrait pas être dans Kit.ids et paramétré dans KITLIST.2DA?

KIT.IDS et KITLIST.2DA marchent ensemble et doivent être cohérents sous peine de gros problème. D'après IESDP, KIT.IDS sert seulement pour quelques fonctions particulières de scripts. La valeur écrite dans la créature est celle du fichier KITLIST.2DA. Ce numéro semble simplement correspondre au numéro de ligne dans KIT.IDS.
Cette valeur est dynamique pour les kits de mod, tout simplement parce que ça dépend de l'ordre d'installation des mods qui ajoutent des kits. C'est le même principe que pour les textes (biographie ou autre) ajoutés à l'installation et dont le numéro ne peut qu'être déterminé à ce moment-là.


PS : j'ai récupéré le fichier ISS que tu m'as envoyé. Je vais étudier ça. En principe, j'ai tous les éléments pour refaire un exécutable d'installation et le tester.

[Cocrane]

La gestion des descriptions des classes.
> suite à ton explication, je vois comment traiter le sujet.

La gestion des Kits.
Ta réponse semble indiquer que finalement on peut tout gérer en utilisant les données des fichiers .2DA et l'affectation dans le .CRE. Ce qui m'arrange.

Mais dans ton précedent mail tu parles de TP2.
"
Les personnages recrutables ont les mêmes restrictions que celles d'un personnage qu'on crée. Une exception est qu'il est possible d'affecter à un personnage recrutable un kit non sélectionnable pour le personnage principal. Le mod Chloe le fait. Mais ceci se fait toujours par l'intermédiaire de lignes de codes bien particulières dans le fichier TP2. Il n'est pas possible d'affecter un kit du mod à une créature du même mod directement avant l'installation. L'opération d'ajout du kit au jeu va permettre d'obtenir dynamiquement le code attribué au kit (en fonction de ceux déjà utilisés), qu'il faut alors patcher dans le fichier CRE (principe similaire dans l'esprit à l'attribution du numéro du texte pour la biographie).
"

Si le moddeur choisit un kit d'un mod installé. Devra t'il faire un traitement particulier avec le TP2 lors de l'installation. Sachant qu'il sait qu'il doit installer le mod kit (avant je suppose).

Coco

[Isaya]

Ta réponse semble indiquer que finalement on peut tout gérer en utilisant les données des fichiers .2DA et l'affectation dans le .CRE. Ce qui m'arrange.

Ce n'est pas si simple que ça. Ce n'est vrai que si tu choisis un des kits fournis avec le jeu de base.

Si le moddeur choisit un kit d'un mod installé. Devra t'il faire un traitement particulier avec le TP2 lors de l'installation. Sachant qu'il sait qu'il doit installer le mod kit (avant je suppose).

Pour l'affectation d'un kit provenant d'un mod, il y a deux cas, le simple et le compliqué.

Le simple, c'est si le moddeur réalise le kit et l'installe en même temps que la créature. Le tutorial que j'ai cité explique très bien comment faire avec WeiDU. Je n'y reviendrai pas ici.
Ce n'est pas très compliqué à faire pour un moddeur en suivant ce tutorial, mais ce serait assez compliqué d'envisager d'écrire un tel code à la place du moddeur à partir d'un éditeur.

Le cas compliqué consiste à vouloir affecter un kit venant d'un autre mod. Il faudrait ajouter dans le fichier TP2 un contrôle de la présence de cet autre mod, comme condition à l'installation. Ensuite, si c'est bon, il faudrait ajouter dans le TP2 un parcours du fichier KITLIST.2DA pour trouver le nom du kit ("C!Selune", dans le cas du tutorial), et alors récupérer le numéro qui apparaît en début de ligne. Ce numéro serait celui à écrire dans le champ KIT du fichier CRE lorsque le TP2 le copie dans le répertoire Override. Loin d'être infaisable pour quelqu'un qui connaît bien le langage WeiDU mais tu ne trouveras probablement aucun tutorial qui montre exactement comment s'y prendre. Là aussi, inutile d'envisager d'intégrer cette capacité à l'éditeur sans compliquer la tâche de façon démesurée.

Il ne faut pas se faire d'illusion : les opérations de TP2 qui ne sont pas de simples copies ou équivalents sont compliquées à écrire. La fonction --automate de WeiDU fait d'ailleurs essentiellement des choses simples lors de la génération de l'extrait de fichier TP2 : écrire les commandes COPY avec les SAY qui vont bien pour que les textes associés (nom d'objet, de personnage, biographie, ...) soient bien ajoutés au jeu.

[Cocrane]

Petit casse tête à 00:30.

Je ne sais pas si c'est la fatigue mais j'ai le problème suivant:

Kit.ids issue du jeu
0x00004000 TRUECLASS
0x00000001 BERSERKER
0x00000002 WIZARDSLAYER
0x00000004 KENSAI
0x00000008 CAVALIER
0x00000010 INQUISITOR
0x00000020 UNDEADHUNTER
0x00000040 MAGESCHOOL_ABJURER
0x00000080 MAGESCHOOL_CONJURER
0x00000100 MAGESCHOOL_DIVINER
0x00000200 MAGESCHOOL_ENCHANTER
0x00000400 MAGESCHOOL_ILLUSIONIST
0x00000800 MAGESCHOOL_INVOKER
0x00001000 MAGESCHOOL_NECROMANCER
0x00002000 MAGESCHOOL_TRANSMUTER
0x00004000 MAGESCHOOL_GENERALIST
0x00008000 FERALAN
0x00010000 STALKER
0x00020000 BEASTMASTER
0x00040000 ASSASIN
0x00080000 BOUNTYHUNTER
0x00100000 SWASHBUCKLER
0x00200000 BLADE
0x00400000 JESTER
0x00800000 SKALD
0x01000000 GODTALOS
0x02000000 GODHELM
0x04000000 GODLATHANDER
0x08000000 TOTEMIC
0x10000000 SHAPESHIFTER
0x20000000 BEASTFRIEND
0x40000000 BARBARIAN

Kit.ids de l'override (installation BGT)
0x4000 TRUECLASS
0x4001 BERSERKER
0x4002 WIZARDSLAYER
0x4003 KENSAI
0x4004 CAVALIER
0x4005 INQUISITOR
0x4006 UNDEADHUNTER
0x0040 MAGESCHOOL_ABJURER
0x0080 MAGESCHOOL_CONJURER
0x0100 MAGESCHOOL_DIVINER
0x0200 MAGESCHOOL_ENCHANTER
0x0400 MAGESCHOOL_ILLUSIONIST
0x0800 MAGESCHOOL_INVOKER
0x1000 MAGESCHOOL_NECROMANCER
0x2000 MAGESCHOOL_TRANSMUTER
0x4000 MAGESCHOOL_GENERALIST
0x4007 FERALAN
0x4008 STALKER
0x4009 BEASTMASTER
0x400A ASSASIN
0x400B BOUNTYHUNTER
0x400C SWASHBUCKLER
0x400D BLADE
0x400E JESTER
0x400F SKALD
0x4013 GODTALOS
0x4014 GODHELM
0x4015 GODLATHANDER
0x4010 TOTEMIC
0x4011 SHAPESHIFTER
0x4012 BEASTFRIEND
0x0000 BARBARIAN
0x0000 WILDMAGE


KITLIT.2DA
La colonne UNUSABLE a les mêmes valeurs que le fichier KIT.IDS issue du jeu.

NI
Exemple: pour l'Abjurateur il me donne la valeur '22'.


Constat:
entre le KIT.IDS du jeu et de l'override, j'ai pas les mêmes identifiants. Ceux de KIT.IDS du jeu sont les mêmes que ceux de KITLIST.2DA. Mais ces valeurs ne correspondent pas à NI qui est visiblement en cohérance avec ceux de KIT.IDS de l'override.

J'aurais tendance à me fier au couple KITLIST.2DA et KIT.IDS du jeu.

Sinon mis à part ce petit problème pour mémoriser la valeur du kit dans le CRE, l'affichage Classe + Kit + description fonctionne.

Coco

[Isaya]

La page relative à KIT.IDS sur IESDP explique que le fichier fourni avec le jeu est erroné. Elle donne la version correcte, qui doit être identique à celle que tu as trouvé dans le répertoire Override.
Apparemment la valeur indiquée dans ce fichier a pour but de permettre l'identification d'un kit via des triggers dans les scripts et n'a rien à voir avec le champ UNUSABLE (qui concerne les restrictions d'emploi des objets pour certains kits).

Pour le reste, j'ai déjà évoqué les relations entre fichier CRE, KITLIST.2DA et KIT.IDS dans ma réponse du 27 janvier. Mais mon hypothèse concernant la relation entre KITLIST.2DA et KIT.IDS est erronée.

Edwin (conjurateur) a une valeur de "kit" fixée à 128, c'est à dire 80 en hexadécimal. Ceci correspond bien à la valeur 0x0080 MAGESCHOOL_CONJURER.
Yoshimo (chasseur de prime) a une valeur de kit fixée à 11, c'est à dire B en hexadécimal. Ceci correspond à la valeur 0x400B BOUNTYHUNTER.
Valygar (traqueur) a une valeur de kit fixée à 8. Ceci correspond à la valeur 0x4008 STALKER.
Keldorn (inquisiteur) a une valeur de kit fixée à 5. Ceci correspond à la valeur 0x4005 INQUISITOR.
Korgan (berserker) a une valeur de kit fixée à 1. Ceci correspond à la valeur 0x00000001 BERSERKER.
Un personnage mage entropique a une valeur de kit fixée à 2147483648, c'est à dire 80000000 en hexadécimal.

De même, le kit du mod Chloe, s'il est installé en premier, se voit attribuer le numéro 32 (soit 20 en hexadécimal) dans KITLIST.2DA et la valeur 0x4020 dans KIT.IDS. Le personnage a la valeur de kit fixée à 32.

Bilan :

• les mages spécialisés sont certainement traités à part. Il suffirait de créer un mage spécialisé dans le jeu puis d'éditer une sauvegarde pour le confirmer pour les autres types de mages. La valeur indiquée dans le champ KIT du fichier CRE correspond non pas au fichier KITLIST.2DA mais à la valeur dans KIT.IDS.
• les dérivés de classe un peu particulier - barbare (guerrier) et mage entropique (mage) - ont également des valeurs particulières, 0x80000000 pour le mage entropique et peut-être 0x40000000 pour le barbare (à vérifier en créant un personnage).
• pour les véritables kits, la valeur du fichier KIT.IDS semble être toujours égale à 0x4000 + la valeur du kit dans KITLIST.2DA. La valeur indiquée dans le fichier CRE est celle du fichier KITLIST.2DA (de 1 à N).

Je ne sais pas comment le jeu fait pour s'y retrouver. En première approche, on pourrait penser que les valeurs différentes de celles des mages spécialisées (qui existaient déjà mais codées en dur dans Baldur's Gate) ou des deux cas particuliers des barbare et mage entropique sont considérées comme de vrais kits.
Comme on ne peut pas créer de kit de mage, la valeur 64 (40 en hexadécimal), qui pourrait désigner un abjurateur ou un kit qui aurait le rang 64, n'est plus ambiguë dès lors qu'on vérifie la classe : si c'est mage, c'est un abjurateur, sinon c'est un kit à base de la classe (guerrier, voleur, ...).

La présence des mages spécialisés dans le fichier KITLIST.2DA provient probablement du fait que le champ dédié au kit (exclusivité de BG II) dans le fichier CRE servait dans Baldur's Gate à la spécialité des mages. Il a donc fallu partager et le fait d'avoir les mages spécialisés et les nouvelles classes (barbare, mage entropiste) a permis de leur affecter une valeur UNUSABLE pour permettre de gérer des restrictions d'objet pour ces classes ou sous-classes.

[Cocrane]

Affectation de la bonne valeur au Kit
Au sujet du bon identifiant de Kit, IESDP signale, comme tu le dis, une erreur.

Version corrigée (Kit.ids dans l'override):
IDS
0x0000 SPECIAL_CLASS
0x0000 BARBARIAN
0x0000 WILDMAGE
0x0040 MAGESCHOOL_ABJURER
etc...

Donc Barbare et Entropique sont des classes spéciales. Je pense qu'effectivement il faut créer une créature de chaque type pour connaitre sa valeur. Je suppose que ces deux kits seront à coder en dur. Qui peut faire ce test?

A noter, NI propose les valeurs de KIT.IDS du jeu (mauvaise version). Je ne sais pas si les moddeurs sont finalement au courant.

Cohérence des choix de Classe et Kit
Faut il vérifier que le choix est autorisé par les règles du jeu? Je suppose que sans il y a des risques de plantage?

Les classes jumelées
Je n'ai pas encore traité ce point. Visiblement les restrictions du jeu sont les suivantes via le lien sur les Kits CDC:

- la Race doit être Humaine (d'après ce que j'ai entendu).

j'ai trouvé ce point:
"
K_C_H.2da et autres - Ces fichiers contrôlent quels kits sont disponibles pour le joueur lors de la création de personnage. La deuxième et la troisième entrée correspondent à la classe et à la race du personnage -- K_C_H détermine quels fichiers sont disponibles pour un clerc humain. KITTABLE.2da possède une table complète qui peut vous aider à déterminer quels fichiers K_*_*.2da correspondent à telle race et à telle classe. Dans le fichier lui-même, vous trouverez une colonne de chiffres croissants sur la gauche et une colonne de nombres sur la droite qui correspondent aux entrées de KITLIST.2da . Remarquez que les fichiers K_*_* ne permettent pas de passer outre les limitations codées en dur -- écrire un kit de druide dans K_D_E (kits de druide pour les elfes) ne permettra pas aux elfes de devenir des druides, car il y a des limitations de race codées en dur pour la classe de druide.
"

- la 2nd classe ne peut pas être un Kit.
"
ABDCDSRQ.2da - Ce fichier contient les caractéristiques minimales requises pour pouvoir se jumeler VERS le kit ou la classe en question. C'est plutôt inutile pour les kits, puisqu'ils ne peuvent constituer la seconde classe d'un personnage jumelé, mais ce fichier a besoin d'être mis à jour.
"

- l'alignement doit être compatible
"
ALIGNMNT.2da - Ce fichier contrôle les alignements autorisés pour un kit. Un "1" indique que l'alignement est autorisé pour le kit tandis qu'un zéro indique qu'il ne l'est pas.
"

- les compatibilités de Classe
"
DUALCLAS.2da - Ce fichier contrôle les possibilités de jumelage autorisées à un kit. Un "1" indique une classe valide vers laquelle se jumeler, tandis qu'un zéro indique que le jumelage vers cette classe n'est pas possible. En raison de limitations codées en dur, les kits des classes qui ne peuvent pas se jumeler (tels que les kits de bardes ou de paladins) provoqueront un crash du jeu si on tente de les jumeler, quel que soit le contenu de ce fichier.
"

Existe t'il d'autres limites?

Question sur la structure du CRE par rapport aux Classes et Kit
- si on est bi classé, on la classe qui le signale clairement et on a deux champs pour les LVL respectifs des deux classes.

- si on a une classe jumelée. Comment c'est géré?

Si je prends Imoen de BG2 (voleuse puis magicienne) avec NI:
- le champ Flag du CRE contient des cases possibles dont 'original class Thief'.
- la classe est signalée bi classée 'Mage Thief '
> comment ca se passe si on a une classe et un Kit pour le champ class?
Exemple:
un Assassin Clerc
champ classe: voleur + Clerc
Champ kit: Assassin

Coco

[Cocrane]

Version 2.1.2 en test disponible

setup_Editeur_Baldur_Gate_V2_1_2.exe

Mises à jours effectuées:
- plus d'animation au démarrage (j'ai échappé belle!) " "
- traduction Française mise en place.
- début d'utilisation des fichiers 2DA (pour les kits)
- visualisation possible d'une créature (double clic dans la liste tableau)
- visualisation possible avec surbrillance des choix effectués pour les races, alignements et sexe
- choix possible de la classe ou du kit.
> Reste la validation de la bonne valeur du kit et de l'affichage dans la fiche au lieu de la classe.
- possibilité de tester la gestion des équipements
* sélection d'un objet dans la liste (double clic)
* clic gauche pr placer
* clic gauche pr prendre
* clic gauche pr échanger
* clic gauche pr dans la zone sol pr s'en débarrasser.

A noter: Il n'y a aucuns contrôles de cohérence actuellement par rapport à ADD ou au moteur du jeu.

Merci aux testeurs pour leurs retours!

Coco

[Isaya]

Affectation de la bonne valeur au Kit

Donc Barbare et Entropique sont des classes spéciales. Je pense qu'effectivement il faut créer une créature de chaque type pour connaitre sa valeur. Je suppose que ces deux kits seront à coder en dur. Qui peut faire ce test?

Le mieux serait que te le fasses toi-même. Il s'agit simplement de créer un personnage, puis d'enregister une sauvegarde une fois dans le jeu, ou d'exporter le personnage. Tu peux le faire dès le début de BG II en évitant la séquence avec Irenicus, tout simplement en utilisant la technique de la pause dès que l'écran devient noir. Ensuite il suffit d'ouvrir dans Near Infinity le personnage exporté (dans le groupe Characters) ou la sauvegarde (dans Save), de sélectionner le fichier GAM et d'ouvrir le personnage sans nom (juste une étoile) qui correspond au PJ.
Par ailleurs, je t'ai déjà fourni les indications concernant le mage entropique : classe mage et la valeur de kit déjà indiquée.

A noter, NI propose les valeurs de KIT.IDS du jeu (mauvaise version). Je ne sais pas si les moddeurs sont finalement au courant.

Je ne sais pas pourquoi tu dis que Near Infinity propose la mauvaise version de KIT.IDS. Peux-tu expliquer, s'il te plaît ?

Near Infinity exploite simplement le fichier présent dans l'environnement du jeu que tu as spécifié, ou dans le répertoire courant si tu l'exécutes depuis un répertoire de jeu.
Le BG2 Fixpack, qui comporte une version corrigée du fichier, corrige également la valeur du kit dans les fichiers CRE de plusieurs personnages qui utilisent un kit (Korgan, Haer'Dalis) pour qu'ils suivent le nouveau fichier.

Pour plus de précisions sur les corrections apportées au fichier KIT.IDS et leur raison, tu peux consulter la documentation du BG2 Fixpack en cherchant le mot Kit sur la page.

Méfiance aussi avec les affichages de Near Infinity pour la valeur du kit. Dans l'exemple que j'ai pris pour un mod ajoutant un kit, Chloe, Near Infinity m'affiche une valeur de 32 (20 en hexadecimal), ce qui correspondait notamment au premier numéro libre dans le fichier KITLIST.2DA. Dans le fichier KIT.IDS, le kit de Chloe est ajouté avec la valeur 0x4020 car, comme tous les vrais kits, leur valeur commence à 0x4000 (TRUE_CLASS + la valeur attribué au kit dans KITLIST.2DA, semble-t-il). En réalité, après vérification avec l'éditeur hexadécimal, le fichier CRE de Chloe présente la valeur 0x4020 à l'emplacement de la valeur du kit. C'est contraire à l'affichage de Near Infinity.
De façon tout à fait intéressante et aussi surprenante, quand j'utilise Near Infinity avec un environnement possédant le "bon" fichier KIT.IDS et que j'observe un fichier CRE avec kit (Haer'Dalis) à l'emplacement du kit, toutes les valeurs de kit et de spécialité de mage / barbare portent les valeurs 0 à 31 dans la liste proposée, ce qui correspond plutôt aux valeurs de la première colonne du fichier KITLIST.2DA. Mais si j'observe Edwin, sa spécialité est la valeur 128 et toutes les valeurs de la liste semblent correspondre à la valeur de la colonne UNUSABLE de KITLIST.2DA ou au contenu du "mauvais" fichier KIT.IDS.
Peut-être était-ce ce que tu voulais dire par "NI proprose les valeurs de KIT.IDS du jeu (mauvaise version)" ? En tout cas, ce n'est pas exact, pas dans tous les cas.


Cohérence des choix de Classe et Kit

Faut il vérifier que le choix est autorisé par les règles du jeu? Je suppose que sans il y a des risques de plantage?

Sans le moindre doute, dans certains cas d'après les indications du tutorial sur la création de kit.
Le non-respect des minima ne devrait pas poser de problème, néanmoins. Par exemple, Anomen est jumelé alors que sa caractéristique de sagesse est insuffisante, selon les règles.
Mais à la base, la vérification de l'affectation des kits est relativement simple : la classe définit la liste de kits accessible (colonne CLASS de KITLIST.2DA). Ensuite, tu peux pousser le détail plus loin, sur la base des fichiers qui définissent les contraintes d'un kit : race, alignement, ... comme l'explique le tutorial.



Les classes jumelées

A ma connaissance, aucun éditeur ne propose de réaliser un personnage jumelé. Mais, à vrai dire, on pouvait aisément s'en passer. Il suffit de créer le personnage dans le jeu avec la première classe, de lui donner les points d'expérience (à la console ou avec un éditeur) pour lui faire atteindre le niveau souhaité, puis de le jumeler et de lui donner les points d'expérience supplémentaires. Le gros avantage est que le jeu lui attribuera ainsi correctement tous les bonus qui vont bien : compétences de voleur, capacités spéciales des kits, ... Near Infinity et Shadow Keeper permettent de créer un fichier CRE à partir d'un fichier CHR (le format d'exportation). Ces éditeurs ou le tien suffisent ensuite largement pour affiner les détails restants.

Refaire ça dans un éditeur suppose de recoder tout un moteur de jeu pour l'affectation du nombre de points de compétence, des sorts, etc. selon le niveau (exploitation de nombreux fichiers 2DA, selon la race, la classe, ...).

Existe t'il d'autres limites?

Le tutorial semble complet, donc probablement pas en ce qui concerne spécifiquement les kits.

Bien entendu, il faut vérifier les règles propres au jumelage et indépendantes des kits : la race humaine, le minimum dans la caractéristique principale de la classe de départ et de la classe d'arrivée, la liste limitée de classe de départ et d'arrivée. Le jumelage ne permet jamais de créer une combinaison impossible aux multi-classés. Une raison technique est que les deux vont utiliser la même interface de commande (accès aux capacités de voleur, aux sorts, ...).


Question sur la structure du CRE par rapport aux Classes et Kit

- si on a une classe jumelée. Comment c'est géré?

Si je prends Imoen de BG2 (voleuse puis magicienne) avec NI:
- le champ Flag du CRE contient des cases possibles dont 'original class Thief'.
- la classe est signalée bi classée 'Mage Thief '
> comment ca se passe si on a une classe et un Kit pour le champ class?
Exemple:
un Assassin Clerc
champ classe: voleur + Clerc
Champ kit: Assassin

Apparemment, un jumelé se distingue par le fait qu'il ait une classe de type bi-classé accompagnée de l'indication "original class".
Comme le jumelage interdit le choix d'un kit pour la deuxième classe, le kit éventuellement attribué est forcément pour la première classe.

Autrement dit, quand tu jumeles Imoen dans le jeu, elle passe de voleur à mage-voleur. Le jeu sait par l'indication "original classe" à quelle classe correspond le niveau indiqué dans le champ Level first class. Il indique alors comme points d'expérience de cette classe la limite pour obtenir le niveau en question et non pas le niveau réel qu'avait Imoen quand tu l'as jemelé. Et il remet à 0 les points d'expérience (donc tout ce qui dépassait par rapport à la limite de niveau dans la première classe est perdu) pour bien repartir au niveau 1.


La version 2.1.2

J'ai un gros souci avec l'éditeur : la fenêtre de paramètres des répertoires me dit que l'éditeur est installé dans mon profil ("C:\Documents and Settings\Mon nom") alors que je l'ai installé ailleurs (au même endroit que d'habitude, sachant que j'avais fait le ménage avant). A chaque lancement, la grande fenêtre de l'application, on voit dans les traces qu'il identifie et compte les fichiers du jeu puis j'obtiens une boite de dialogue avec simplement l'icône d'erreur (croix sur fond rouge) et un bouton OK, sans le moindre texte d'erreur. Je peux ouvrir la liste de créatures, ouvrir la partie graphique, mais elle a de gros défauts : pas de texte des noms de caractéristiques, bien que leur valeur soit affichées. La classe, la race et le sexe ne sont pas affichés et certains des boutons cachés derrière ces affichages (qui devraient permettre de les modifier) font planter l'application.
Vu le problème initial de configuration, je n'insiste pas. Ça ne servirait à rien de tester des détails puisqu'il peut simplement s'agir de conséquences du problème de configuration.

[Cocrane]

Isaya,
je réponds juste rapidement à ton problème d'installation. Je reviendrai sur tes explications sur mes questions précédentes.

La fenêtre avec une croix sans info est liée à l'échec de l'étape de traduction à mon avis.
J'ai pourtant mis une info d'erreur. Mais dans mes tests ca n'affichait rien en terme de retour automatique d'erreur. Vu ton problème, j'ai mis du texte en dur:

"Fichier de traduction BG non trouvé sous [chemin_base_editeur] BG_traduction.xls"

L'hypothèse se confirme avec tes infos sur les problèmes d'affichage des libellés. Tu n'as pas eu de chargement du fichier de traduction donc tu n'as pas les libellés à l'écran.

Le fichier de traduction est un fichier excel en version 2002: BG_traduction.xls. Il est présent à la racine du chemin de l'éditeur après installation.

Windev ouvre ce fichier par ses propres moyens je pense (pas de fonctions liées au pack office).

J'ai mis à jour le code et je remets à disposition une version:
- en cas d'échec pour trouver le fichier traduction, le message signale le chemin cherché.

- au niveau de l'écran équipement, mes icônes objets de test avaient un chemin codé en dur personnalisé à mon pc. J'ai corrigé les icônes objets de test. Ils sont disponibles après installation.


Lien: setup_Editeur_Baldur_Gate_V2_1_3.exe


Coco