La Couronne de Cuivre

Merci Isaya pour le lien DLL. C'était logique de chercher la DLL avant d'essayer de la faire soit même mais ça ne m'est pas venu à l'esprit.

"Pourquoi faire compliquer quand on peut faire simple?"

J'ai codé la décompression de la BAMC en BAM ca colle sur un fichier testé. Je vais intégrer la fonction à l'éditeur maintenant. Ca devrait marcher.

Deux questions:
1- Un moddeur veut rajouter une BAM.

Il suffit de mettre la BAM crée dans l'override?

Je suppose que l'on est pas obligé d'en faire une BAMC.

2- Structure du fichier BAM

"//Frame Entries
* Cycles may share the frames, which is accomplished by using a layer of indirection. Instead of specifying which frames belong to a given cycle, each cycle has a list of frame indices.
0x0000 2 (word) Frame width
0x0002 2 (word) Frame height
0x0004 2 (signed word) Frame center X coordinate
0x0006 2 (signed word) Frame center Y coordinate
0x0008 4 (dword) Offset frame data|Compressed
* bits 30-0: Offset to frame data
* bit 31: 0=Compressed (RLE), 1=Uncompressed
"
je vois le terme 'Compressed (RLE)', il y a à nouveau une décompression RLE potentielle à faire?


La description du fichier BAM sous iesdp est Anglais et j'ai du mal. D'autant plus qu'il y a des liens entre les sections. Qui pourrait me traduire la description?
Je pourrais jeter un oeil sur le code des autres éditeurs mais rien ne dit que le code sera clair.

Conclusion pour le moment je suis dans la grotte 'BAM' avec un pauvre briquet.
Qui peut m'apporter une torche?


Coco

Personne pour me filer un coup de main?

Coco

Ajout de fichier BAM

Comme tout fichier de ressource graphique ou sonore, il suffit effectivement de copier le fichier BAM dans le répertoire Override. Comme il n'y a pas dans IESDP d'indication de l'usage préférentiel de fichier compressé dans telle ou telle partie du jeu, je suppose qu'il sait s'accommoder de n'importe quel type de fichier BAM quel que soit l'objet manipulé (icône d'objet, animation de créature, ...).

A moins que tu ne veuilles faire un éditeur qui couvre aussi les aspects graphiques, tu as tout intérêt à laisser le problème de la compression aux outils spécialisés. Je pensais que tu cherchais à lire les fichiers BAM uniquement pour être en mesure d'afficher les icônes d'objets ou de sorts. Je me trompe ?


Format BAM

Je n'ai jamais manipulé ce format de fichier. Et Near Infinity ne propose pas de vue "Edit", ce qui rend d'autant plus compliqué toute recherche profane à son sujet. Je peux t'aider à comprendre l'anglais de la description mais pas forcément à en comprendre le sens exact vis à vis des fichiers et de leur contenu.
Le fait qu'il y ait un indicateur de compression RLE signifie qu'au moins un jeu basé sur l'Infinity Engine comporte au moins un fichier BAM qui exploite cette capacité. Sinon on n'aurait jamais découvert la signification de ce bit. Mais cela ne signifie pas que c'est le cas général. J'ignore si c'est fréquent. J'aurais tendance à croire le contraire, vu l'existence de certains outils de manipulation des fichiers BAM. En effet il existe un outil basé sur WeiDU et son langage permettant de manipuler les fichiers BAM. Il s'appelle BAM Batcher. Il permet notamment d'extraire un fichier BAM sous forme d'image(s) BMP, une par cycle / frame.
Comme à la base WeiDU n'est pas fait pour manipuler des contenus de fichiers BAM ou des compressions RLE, j'en conclus que l'auteur a dû coder en WeiDU toutes les opérations que tu cherches à faire de ton côté. Ce serait donc intéressant que tu y jettes un coup d'oeil. Je ne suis pas convaincu que le langage WeiDU soit plus lisible que du C ou du Java, mais ceci est une autre histoire. Au moins, tu peux faire fonctionner l'outil, qui se présente comme un mod avec des composants qui effectuent une des actions décrites dans la documentation.

Voici une traduction des principaux textes de la description, sans les structures proprement dites.


Description générale

Ce format de fichier décrit des graphismes animés. Ce genre de fichieres sert aux animations (aussi bien les animations de créatures que les animations d'objets ou de sorts), aux éléments de l'interface graphique (par exemple les boutons) et pour les collections logiques d'images (par exemple les polices de caractères). Les fichiers BAM contiennent de multiples séquences d'animations, jusqu'à un maximum de 255.

Remarque : bien que le format BAM autorise des dimensions d'image très élevées, le moteur de jeu n'affichera les images que jusqu'à une certaine taille. La taille maximum varie selon la version du moteur de jeu.


BAM V1 Entrées d'images

Les cycles peuvent se partager les images (frames). Le format y parvient par le biais d'une couche d'indirection. Au lieu d'indiquer quelles images appartiennent à un cyle donné, chaque cycle possède une liste d'indices d'image.


BAM V1 Entrées de cycle

Ces entrées font référence à un intervalle d'indices dans la table de correspondance (lookup table) des images, qui de son côté pointe sur les véritables images. Notez que les entrées de table de correspondance d'image peuvent aussi être mises en commun entre les cyles.


BAM V1 Table de correspondance des images

C'est un tableau d'indices d'image. Un cycle désigne une séquence d'entrées dans cette table. Par exemple, une animation peut commencer à l'élément 0 de ce tableau et se poursuivre sur 6 images. Alors l'animation suivante commencerait typiquement à l'élément 6 et se poursuivrait sur un certain nombre d'indices.
Si les 6 premières entrées de la table étaient { 0, 1, 1, 2, 3, 4 }, l'animation afficherait l'image n°0, suivie de l'image n°1 pendant deux intervalles de temps, suivie par les images 2, 3 et 4 dans cet ordre. Pour trouver le nombre d'entrées de cette table de correspondance, cherchez la valeur maximale de la somme début (index) + nombre (count) dans la table des entrées de cyle.


BAM V1 Données d'image

S'il ne s'agit pas d'une image compressée, il s'agit simplement de largeur * hauteur octets, qui désignent les valeurs pour chaque pixel à l'aide de la palette définie juste avant.
S'il s'agit d'une image compressée, les données sont compressées suivant un principe Run-Lenght-Encoding. Ce principe est le suivant :
- tout octet qui diffère de l'index de transparence défini dans l'en-tête représente sa propre couleur
- l'index de transparence suivi d'un octet x représente (x + 1) copies de l'index de transparence


Remarque : le principe du codage RLE est notamment expliqué ici. Il ne présente aucune grosse difficulté de codage dans le cas présent. Il s'agit simplement de répéter x + 1 fois un pixel de la couleur transparente.

Le point important non explicité est le fait que la palette comporte 256 couleurs, puisque la couleur de chaque pixel est codée sur 8 bits.
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 mieux comprendre les fichiers BAM, en particulier comment interagissent les images et les cyles, le mieux serait que tu installes un outil de création de fichiers BAM tel que BAMWorkshop. Tu peux le trouver sur ce site. Il existe deux versions, réalisées par des auteurs différents et sur des bases différentes. Il semble que les deux aient des points forts et des points faibles.
Ensuite, charge des fichiers BAM plus ou moins complexes, de l'icône d'objet à une animation de créature ou d'élément de décor (feu qui flambe, porte, ...). Il te faudra d'abord les extraire avec Near Infinity ou WeiDU car l'éditeur ne va pas lire dans les fichiers BIF. Le site IESDP explique notamment comment sont nommés les fichiers BAM des animations de créature dans cette page.

Bonne continuation.

Salut Isaya,
je te remercie de répondre toujours présent lorsque j'ai besoin d'une lanterne pour m'éclairer.

Je constate que tu es le seul. Je trouve cela décevant compte tenu que j'essaie de rendre la vie de moddeur plus simple à tout le monde. Ca consomme beaucoup de temps. Je me demande, si les moddeurs ne sont pas tous morts ou originaires d'autres pays.

Objectif des BAM dans l'éditeur
Le premier objectif est effectivement de pouvoir gérer les BAM sans animation tel que les portraits, images des objets et sorts.

Si j'arrive à traduire une BAM animée, je proposerai de les créer ou de les modifier mais cette partie n'est pas prioritaire.

Ce fichier est de loin le plus complexe à traduire que j'ai eu à faire. Je n'ai pas encore compris la logique du découpage du fichier. Je vais poursuivre le travail sur le sujet maintenant que j'ai de nouvelles pistes.

Coco

Bon. Les fichiers BAM c bien pénible.

Je travaille sur une image sans animation et c'est pas simple.

IMISC2J.BAM
Header
Signature BAM
version V1
Count of frames 2
Count of cycles 2
compressed color index 0
offset frame entries 24
offset palette 56
offset frame lookup table 1080

Frame_Entries
Frame width 25 28
Frame Height 24 25
Frame center X coordinate -4 11
Frame center Y coordinate -5 11
Offset frame Data / Compressed 1084 1568

taille des images:
image1= 25 * 28= 700
image2= 24 * 25= 600

2 frames car "count of frames = 2".

Je ne comprends pas le rôle des coordinate d'autant plus qu'elles sont négatives.
J'ai comparé la taille des images annoncées à celle de BamWorkshop 2 en prenant les positions avec la souris:
image 1: 35 * 35 -> 1225 pixels
image 2: 24 * 23 -> 552 pixels soit 1777 pixels pour les deux images.

A ce niveau j'ai donc un doute sur la qualité de ma lecture du fichier.

Cycle_Entries
Count of frame indices in this cycle 1 0
Index into frame lookup 1 1

Palette
Le RGBQUAD est expliqué sur le net, j'en déduis donc une structure ce type.
1 (byte) rgbBlue
1 (byte) rgbGreen
1 (byte) rgbRed
1 (byte) rgbReserved

En affichant les couleurs, j'obtiens des couleurs du type proposé dans Bamworkchop.
Je ne suis pas sur que l'ordre soit respecté à la lettre. Je commence bien à l'offset 56 et je lis 4 par 4.

En testant plusieurs fichier, j'ai constaté que la palette présente tj une taille 1024. Soit 256 couleurs (/4).

Lookup Table
Là ca se corse. Je n'ai aucune description de la structure à lire.

Pour le fichier BAM en cours le tableau d'indices a une taille de 4. Si je lis octet / octet, j'obtiens: 1 0 0 0. Je ne vois pas trop quoi faire de ces valeurs.

En prenant une image animée: ABIRG1 (aigle qui tourne dans le ciel).
J'obtiens les mêmes valeurs que BamWorkshop si je lis les octets 2 / 2.

Suite à la traduction et au test sur image animée, c'est donc une succession de chiffres liées aux images. Je ne vois pas trop comment l'exploiter.

Data

La taille du fichier est de 2131 octets. L'offset des data a pour valeur 1084 puis 1568.
image1: 1568 - 1084= 484 octets.
image2: 2131 - 1568= 563 octets.

Ca ne correspond ni a mon calcul ni à celui pris dans Bamworkshop.

De plus je ne vois pas comment lire cette section data même avec la traduction:
- coordonnée du pixel?
- valeur de la couleur du pixel en relation avec la palette de couleur?

En lisant, 2 octets par 2 octets, j'obtiens des valeurs qui ne dépassent pas 256. Je me demande si la valeur ne fait pas référence à une position dans la palette et on affecte ensuite la couleur de cette dernière pour le pixel en cours.

Voilà où j'en suis pr l'instant.

Coco

Les moddeurs se fichent bien des détails de l'implémentation des fichiers. Ils utilisent des outils comme BAMWorkshop ou autres pour travailler leurs fichiers. Ta problématique est celle du créateur d'outil. Tu te retrouves un peu seul, en tout cas dans l'environnement francophone. Les autres personnes qui s'intéressent aux formats sont les "découvreurs" des formats, prêts à farfouiller tous les fichiers pour comprendre comme le jeu exploite telle ou telle valeur, ainsi que les personnes qui écrivent l'émulateur GemRB.

Pour les portraits, j'ai une bonne nouvelle : ce ne sont pas des BAM mais de simples BMP.

Décodage du fichier BAM IMISC2J.BAM

J'ai utilisé un éditeur hexadécimal très puissant, Hex Workshop, qui permet de définir des structures puis de le plaquer sur un fichier binaire. Bien évidemment, l'éditeur est payant. Mais dans un contexte de travail poussé sur des fichiers binaires, son prix n'est plus un frein face à l'énorme gain de temps que cette capacité apporte (quand je l'ai acheté il coûtait presque deux fois moins cher, à vrai dire). Il m'a rendu bien des services dans mon travail.
Le mainteneur d'IESDP avait écrit des définitions de structures pour certains formats (CRE, SPL, ...) mais pas le BAM. Je viens d'écrire rapidement les structures permettant de décoder au moins le début du fichier, jusqu'à la palette.

Je ne retrouve pas les mêmes résultats que toi et je m'interroge sur la façon dont tu as obtenu tes résultats dans les Frame Entries.
La première Frame Entry me semble bonne :
Frame width 25
Frame Height 24
Frame center X coordinate -4
Frame center Y coordinate -4
Offset frame Data / Compressed 1084 (compression RLE utilisée puisque valeur inférieure à 2 000 000 000)

Pour la seconde, j'obtiens :
Frame width 36
Frame Height 36
Frame center X coordinate 14
Frame center Y coordinate 18
Offset frame Data / Compressed 1577 (compression RLE utilisée puisque valeur inférieure à 2 000 000 000)

Je ne comprends pas comment tu as obtenu tes valeurs. Tu sembles avoir bon pour 25, 24 et -4. Mais je ne comprends pas d'où sort subitement ton -5 alors que le 1084 est bon. Ensuite, c'est tout faux pour la deuxième Frame entry. Les valeurs 28 et 11 n'apparaissent pas du tout dans le fichier dans cette zone entre les positions 24 et 56.

Ensuite, les valeurs pour Cycle Entries sont bonnes, mais mal rangées.

J'obtiens :
Cycle entry 1
count 1
index de début 0

Cycle entry 2
count 1
index de début 1


Palette

Elle fait forcément 256 couleurs (j'en avais déjà parlé, en tant que valeur implicite). Comme chaque couleur de pixel dans les Frame Data est sur 8 bits, il faut forcément 256 valeurs dans la palette pour les définir.


Lookup Table

Comme la donnée FrameCount est codée sur deux octets, on peut penser que chaque valeur dans la lookup table est codé sur deux octets. Sinon le lien indiqué dans la table ne permettrait pas d'accéder à plus de 256 images, donc FrameCount pourrait être limité à un seul octet.
Par ailleurs, la description de la table de correspondance indique

Pour trouver le nombre d'entrées de cette table de correspondance, cherchez la valeur maximale de la somme début (index) + nombre (count) dans la table des entrées de cycle.

Quand on regarde les deux cyles, on se rend compte que la somme index + count du premier vaut 1 et que celle du second vaut 2. Donc la table de correspondance a une taille de 2.
Compte tenu du contenu de la table, cela nous donne :
première position : 1
deuxième position : 0

Le cycle 1, qui utilise pour départ l'adresse 0 de la table de correspondance (index de début = 0), utilise 1 seule image (count = 1), donc la numéro 1.
Le cycle 2, qui utilise pour départ l'adresse 1 de la table de correspondance (index de début = 1), utilise 1 seule image (count = 1), donc la numéro 0.

Comme il n'y a pas de compression RLE dans aucune des images, le décodage des images est simple.
La première commence à l'adresse 1084 et comporte 24 lignes de 25 pixels, soit 600 octets. Grâce à la compression RLE, on constate que seulement 493 octets ont été nécessaires (1577 - 1084).
Le seconde commence à l'adresse 1577 et comporte 36 lignes de 36 pixels, soit 1296 octets. Grâce à la compression RLE, on constate que seulement 684 octets ont été nécessaires (taille du fichier, 2261, - 1577).

D'après ce que je comprends de la description des datas (il est écrit width * height), il faut considérer les pixels sur la première ligne, puis sur la suivante et ainsi de suite. Cela correspond à l'utilisation typique d'un FAX (il scanne par ligne, compresse en RLE ligne par ligne). Pour la première image, cela donnerait 25 pixels pour la première ligne, suivis de 25 pixels pour la deuxième ligne et ainsi de suite jusqu'à la 24ème ligne.
Il ne faut pas oublier que la décompression RLE vaut augmenter le nombre de pixels obtenus à partir des 493 ou 684 octets.
Chaque octet donne, pour son pixel, la position de la couleur dans la palette de couleur.

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.

Pour décompresser la partie image, je te suggère de travailler sur une table de taille width * height. Tu lis octet par octet la zone affectée à l'image compressée.

• Si la valeur est différente de la couleur compressée, tu recopies dans la table décompressée et tu passes à la position suivante.
• Si la valeur est la couleur compressée, tu lis l'octet suivant (disons qu'il vaut N) et tu recopies N + 1 fois la couleur compressée dans la table décompressée.

Et ainsi de suite jusqu'à la fin de la zone affectée à l'image compressée. En principe, tu auras alors atteint la dernière position dans la table décompressée également.
Ensuite, tu peux découper cette table par bloc de witdh pixels pour les affecter à chaque ligne de l'image.
Pour connaître la véritable couleur d'un pixel, il te suffit de prendre la valeur RGB dans la palette à l'index indiqué par la valeur du pixel.

J'espère que je ne me suis pas trompé dans mon analyse de l'exploitation de l'image compressée. Je n'ai pas vraiment le temps d'écrire un programme pour réaliser ça et l'éditeur hexadécimal n'est d'aucun secours pour convertir ne serait-ce que 493 octets en 600 en appliquant même un algorithme aussi simple.
Si tu jettes un coup d'oeil au code WeiDU de BAM Batcher, tu retrouveras peut-être cet algorithme. Mais il risque d'être assez illisible, WeiDU n'étant pas un modèle de lisibilité pour écrire du code de ce type. Je suis d'ailleurs sidéré de voir que l'auteur ait utilisé WeiDU autant à contre emploi. C'est vraiment du codage de gourou de WeiDU, même si on arrive quand même à peu-près à le lire quand on sait ce qu'on cherche.

Salut Isaya,
je vois que tu es toujours plein de ressources.

Hier j'arrivais à sortir toutes les couleurs dans un quadrillage quelconque. J'avais prévu de relire ton mail ce soir mais celui que tu as écrit cette nuit m'a permis de trouver la solution rapidement.

Mes deux images prisent pour l'exemple pris apparaissent bien à l'écran: ENFIN!

Samedi dernier, je commençais sérieusement à douter de la possibilité d'arriver à afficher le dessin des portraits, objets et sorts. Donc c'est Top. Ca me redonne de l'énergie. Il me reste à voir pour la Lookup table pour clore le sujet sur les BAM.

Les outils BamWorkShop ont l'air bien réalisé etau vu de ce qui est fait, je ne vois plus l'intérêt de tenter de faire une partie évoluée sur les BAM. L'éditeur va se contenter d'afficher les images suivant les types de fichiers manipulés.

Encore une fois grand merci à toi. Lorsque l'éditeur sera réalisé, je te devrais "une fière chandelle". Heureusement que tes services sont gratuits!

Heuuu j'ai un doute là. Pourrais tu avoir l'obligeance de déclarer aux yeux de tous que tes services sont bien gratuits, qu'une facture n'est pas cours d'édition et qu'elle ne va pas se mettre à me poursuivre?

Au sujet des dimensions des images, on n'a effectivement pas les mêmes valeurs. Les deux Bamworshop nous donnent raison selon celui qu'on utilise. En utilisant, le format que j'annonce, j'obtiens deux images qui correspondent à ceux de BamWorkshop.

Je suis toujours intrigués par "Frame center X/Y coordinate " que je n'utilise pas. Sont ils utilisés par BG? Mystère...

Dans un précédent mail, tu m'expliquais qu'il était important d'accéder facilement aux fichiers Biff. Je ne sais plus dans quel contexte c'est utile?

Si je voulais, par exemple, afficher tous les dessins des armes existantes. Suis je obligé de lire tous les fichier ITM? Les fichiers Biff peuvent ils éviter ce problème?

Coco

Faire payer mes services ne m'était pas venu à l'esprit, mais puisque tu en parles, je vais sérieusement y réfléchir. D'autant que ça m'aiderait à justifier à certaines personnes pourquoi j'y consacre autant de temps.

En principe la lookup table ne devrait pas présenter un gros problème à gérer, une fois que tu as compris le principe et que tu sais quelle est la taille de chaque élément dans la table. Pour ce qui concerne un simple affichage des objets et de sorts, ce sera de toute façon très standardisé. C'est surtout pour les animations que la situation sera un peu plus changeante.

Je n'ai pas compris ta remarque sur les dimensions de l'image. Les deux versions de BAMWorkshop me donnent bien exactement les informations que je t'ai indiquées pour les largeurs, hauteurs et décalages. Si par contre, tu regardes les indications de position de curseur à droite et en bas, si le logiciel compte à partir de 0, c'est certain que tu vas obtenir 1 en moins sur la largeur et la hauteur. Mais pour réserver une zone mémoire assez grande pour décompresser le RLE, il n'y a pas d'autre choix que tenir compte des vraies largeur et hauteur.

Les notions de "center coordinate" servent probablement surtout pour les animations, notamment de sort. Les images peuvent varier en taille dans le cycle d'animation (un effet de sort qui s'étend, comme une boule de feu) et pas toujours dans la même direction. Dans ce cas, il est important de pouvoir positionner le centre de l'image par rapport à sa dimension (ce ne sera pas toujours au milieu si l'image est décentrée).


En ce qui concerne les fichiers BIF, l'idée est avant tout de pouvoir se passer de WeiDU pour extraire un fichier, et donc gagner un temps fou. Pour accéder aux images des sorts ou des objets d'un personnage, il faut d'abord lire les sorts / objets (première extraction) puis lire les fichiers BAM. Et ce pour chaque objet / sort du personnage. Soit pour un prêtre de haut niveau, pas loin de 100 sorts / objets et au moins autant d'images. Même en optimisant au maximum, ça va faire au moins deux appels à WeiDU (un pour tous les objets et sorts, l'autre pour toutes les images que tu y trouveras) avec à chaque fois une grosse liste de fichiers à extraire. Tout ça pour afficher un personnage. Tu risques d'attendre un très gros paquet de secondes juste pour afficher un personnage.

J'avais une envie de graphisme et j'ai pas pu résister. J'ai donc commencé cette partie.

Je me pose des questions sur les classes:
- la liste est contenue dans le fichier IDS en anglais.
- la liste contient les classes & spécialisations.
- je dois les afficher selon la langue sélectionnée.
- je dois afficher les classes et selon la classe séléctionnée les spécialisations proposées.
- je dois afficher le txt en décrivant la classe.
- la liste doit être évolutive vu que certains moddeurs ajoutent des kits.

Comment je fais le lien entre le nom de la classe en Anglais et celle en Français? BG y arrive grace a une biff?

Un kit est toujours une spécialisation?

Mes graphismes attendent de pied ferme vos réponses!

Coco

Les classes sont limitées par le moteur de jeu. On ne peut pas en ajouter. Certains diront "mais si, des mods l'ont fait" mais c'est une bidouille et ça ne change pas le fait que les classes applicables aux personnages jouables sont limitées.

Attention à ne pas confondre classes et kits. Les kits sont des spécialisations de classe mais bien des choses s'appuient sur la classe pour déterminer ce que les kits offrent au personnage. On peut ajouter des kits et leur donner le nom qu'on veut. Les classes étant figées, leurs noms le sont aussi. Les éditeurs qui sont "ergonomiques" sur le nom de la classe (j'entends par là qu'ils ne se contentent pas d'afficher le code ou le nom du fichier IDS) ont une table de correspondance "en dur" et affichent de l'anglais quel que soit la langue de ton jeu. Pour faire mieux, il faudrait qu'ils fassent, comme le jeu sans doute, une table de correspondance entre les classes et les numéro de textes (nom, description) dans le fichier dialog.tlk. 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é.
Si tu veux travailler avec le fichier dialog.tlk pour faire des recherches, le plus simple est d'exporter ce fichier sous forme d'un gros fichier texte. La commande pour le faire avec WeiDU est (à partir du répertoire du jeu ou avec l'option --game en plus) : Du côté des kits, le numéro du texte pour le nom et la description figurent dans le fichier Kitlist.2DA, donc il est possible de s'en servir sans difficulté. Ce sont les numéros des colonnes LOWER MIXED HELP. La classe est indiquée dans la colonne CLASS et renvoie au fichier CLASS.IDS, qui liste toutes les classes (y compris des monstres).
La classe et la spécialisation sont dans deux champs différents de la structure CRE. Ce qui ne veut pas dire que les deux ne doivent pas être cohérents (ton éditeur devrait y veiller).

Toutes les classes n'ont pas de kits. Le choix de kit ne devrait donc être ouvert qu'à certaines. Là où ça peut se compliquer, c'est qu'il y a des exceptions ou des règles particulières. En particulier si tu veux proposer de créer des personnages jumelés (bien plus complexe), on peut choisir certains kits comme première classe et ensuite c'est forcément une classe simple. Par ailleurs certains kits ne peuvent pas être jumelés (il y a un champ du fichier 2DA du kit qui permet de l'interdire). Le tutoriel de création de kit donne les explications à ce sujet.
Une spécialité de mage est assimilable à un kit. L'information est d'ailleurs dans le champ de kit dans le fichier CRE. Mais ça ne signifie pas pour autant qu'on peut en créer (c'est en dur).
Dans un cas très particulier (gnome), un guerrier-mage (multi-classé) est forcément de spécialité illusionniste.

Si tu veux voir des graphismes rapidement, je te suggère de commencer par une simple visualisation de créature. Avec toutes les règles pour éditer un fichier CRE (on n'a sûrement pas tout passé en revue), cela risque de prendre du temps.

Bonnes fêtes.

Salut Isaya,
j'ai pris note de tes infos.

Graphiquement (aspect visuel), les premières briques sur la partie créature correspondent à mon objectif. Ca me plait! C'est du temps à passer mais techniquement c'est moins difficile que le décorticage des fichiers.

Je vais avoir pas mal de boulot sur les règles de gestion tel que les classes, kit, compatibilité de race et d'alignement: en gros les règles ADD!
Existe t'il un lien sympa sur le sujet?

Je suis quand même curieux. BG fait comment pour lier un kit à une classe?
Je suppose qu'en allant voir le tuto j'en saurais plus. Il est où ce tuto?
(difficile d'être au four et au moulin)

Pour les incompatibilités race, alignement, caractéristiques trop faibles par rapport à un choix de Classe, BG se base sur des fichiers?
J'ai noté qu'un fichier 2DA pouvait servir à gérer les incompatibilités pr les classes jumelées.

Je vais creuser pour faire une table de correspondance pour les langues. J'ai commencé à faire mes graphismes pour être compatible au niveau de la langue.
Une mise à jour sera nécessaire si vous utilisez de nouveaux kit (présent ds le fichier IDS) en:
- manuel via un menu de l'éditeur.
- automatique via un patch.

Je vais faire une liste des champs du fichier CRE dont je ne vois pas quoi en faire au niveau graphique.

Coco

Cocrane a écrit :Je suis quand même curieux. BG fait comment pour lier un kit à une classe?
Je suppose qu'en allant voir le tuto j'en saurais plus. Il est où ce tuto?
(difficile d'être au four et au moulin)

Il est là.

Cocrane a écrit :Je vais avoir pas mal de boulot sur les règles de gestion tel que les classes, kit, compatibilité de race et d'alignement: en gros les règles ADD!
Existe t'il un lien sympa sur le sujet?

Difficile de nos jours de trouver des sites qui traitent de la deuxième édition de AD&D. Il y a eu 3 nouvelles éditions depuis : 3, 3.5 et 4.
D'un autre côté, tu n'as pas besoin de réimplémenter les règles mais plutôt de t'assurer de suivre celles mises en place dans le jeu (ça colle pour l'essentiel).

Cocrane a écrit :Je suis quand même curieux. BG fait comment pour lier un kit à une classe?

Je l'ai indiqué dans ma réponse précédente. La classe du kit est dans la colonne CLASS du fichier Kitlist.2DA.

Cocrane a écrit :Pour les incompatibilités race, alignement, caractéristiques trop faibles par rapport à un choix de Classe, BG se base sur des fichiers?
J'ai noté qu'un fichier 2DA pouvait servir à gérer les incompatibilités pr les classes jumelées.

Effectivement, j'avais oublié cet aspect de minima de caractéristiques. Vu la complexité de la chose, il vaudrait mieux ne pas bloquer le choix de kit en fonction des caractéristiques du personnage (l'utilisateur ne comprendrait pas pourquoi) mais plutôt faire un système de contrôle avant sauvegarde qui ferait une synthèse de ce qui ne convient pas.
Il y a plusieurs fichiers 2DA qui gèrent ces contraintes. Le tutorial sur les kits les couvrent probablement tous.

Cocrane a écrit :Je vais creuser pour faire une table de correspondance pour les langues. J'ai commencé à faire mes graphismes pour être compatible au niveau de la langue.

Je ne suis pas sûr de ce que tu veux faire. Gérer les langues dans l'éditeur est différent de reprendre les intitulés (classe, ...) à partir du fichier dialog.tlk. Les deux peuvent parfaitement diverger (éditeur en anglais et jeu donc intitulés en français, par exemple).

Cocrane a écrit :Une mise à jour sera nécessaire si vous utilisez de nouveaux kit (présent ds le fichier IDS) en:
- manuel via un menu de l'éditeur.
- automatique via un patch.

Les kits ne sont pas dans un fichier IDS (généralement peu modifiés par les mods) mais dans un fichier 2DA (plus fréquemment modifiés).
Je ne saisis pas où tu veux en venir. Dans une session de travail de l'éditeur, il n'y a pas de raison qu'ils changent.

Bonne continuation. Je vais te laisser tranquille (ou mariner sans réponse de ma part ?) pendant deux semaines.

Rhâââ ... les Kits ... Mmmmh .

les règles ADD!
Existe t'il un lien sympa sur le sujet?

IcI :
http://dnd.ezael.net/portail/articles.php?lng=fr&pg=118
Donjon du Dragon, le site du mouvement OldSchool Francophone (sic)

Ceci étant, pour rappel :
Baldur's Gate - Wikipédia
Système de jeu :
"Baldur's Gate a la particularité d'utiliser la licence des Royaumes oubliés, un décor de campagne créé par Ed Greenwood pour Donjons et dragons et de se conformer aux règles de la seconde édition d'Advanced Dungeons & Dragons (bien que certains éléments aient été modifiés pour permettre au jeu d'être exécuté en temps réel), l'un des jeux de rôle les plus connus. Baldur's Gate se situe donc dans un monde déjà créé."

P.S. :
Merci beaucoup pour ce Super Topic ...
& Bonne Fêtes à Tous . .

Je travaille sur la correspondance des champs du jeu avec la structure du fichier CRE (créature).


Dans le sens ECRAN -> Fichier CRE
- Furtivité? = 0x0068 1 (byte) Stealth (minimum value: 0)?
- Biographie (bif?)


Dans le sens Fichier CRE -> ECRAN
- les couleurs pr l'apparence. Dans NI, les valeurs vont de 0 à 146. D'où viennent t'elle?

0x023f 1 (byte) Morale
> valeur moral actuel?
0x0240 1 (byte) Morale break
> valeur seuil où le personnage panique?
0x0242 2 (word) Morale Recovery Time
> durée de la panique?
0x0066 1 (byte) Lore (0-100)
0x0276 1x5 (bytes) OBJECT.IDS references
0x027c 2 (word) Global actor enumeration value
0x027e 2 (word) Local area actor enumeration value
> localisation du personnage?
0x0280 32 (char array) Death Variable (set SPRITE_IS_DEADvariable on
Tracking skill (0-100) 'Suivi de compétences'

De même pour la spécialisation dans les armes, le CRE signale:
"
0x006e 1 (byte) Large swords proficiency (unused in BG2) (Proficiencies maybe be packed into 3-bit chunks for the primary and secondary classes)
0x006f 1 (byte) Small swords proficiency (unused in BG2) (Proficiencies maybe be packed into 3-bit chunks for the primary and secondary classes)
0x0070 1 (byte) Bows proficiency (unused in BG2) (Proficiencies maybe be packed into 3-bit chunks for the primary and secondary classes)
0x0071 1 (byte) Spears proficiency (unused in BG2) (Proficiencies maybe be packed into 3-bit chunks for the primary and secondary classes)
0x0072 1 (byte) Blunt proficiency (unused in BG2) (Proficiencies maybe be packed into 3-bit chunks for the primary and secondary classes)
0x0073 1 (byte) Spiked proficiency (unused in BG2) (Proficiencies maybe be packed into 3-bit chunks for the primary and secondary classes)
0x0074 1 (byte) Axe proficiency (unused in BG2) (Proficiencies maybe be packed into 3-bit chunks for the primary and secondary classes)
0x0075 1 (byte) Missile proficiency (unused in BG2) (Proficiencies maybe be packed into 3-bit chunks for the primary and secondary classes)
"
Si ce n'est pas dans ces champs que l'on renseigne les spécialisations, c'est où?

Coco

Une réponse rapide et un peu en vrac car il y a beaucoup de questions.

- Stealth : correspond au déplacement silencieux

- Biographie : c'est l'un des numéros de texte (renvoi vers dialog.tlk) de la table "4*100 (Strref*100)", on retrouve facilement lequel en ouvrant un fichier CRE de personnage recrutable dans Near Infinity (il est appelé EXISTANCE5, et 74 BIOGRAPHY_TEXT dans le fichier SNDSLOT.IDS de BG II décrit dans IESDP)

- les couleurs font référence à des palettes de couleurs qui se trouvent, il me semble, dans des fichiers BAM. Reste à retrouver lesquels. Les éditeurs existants doivent pouvoir aider à retrouver ce lien. A suivre...

- Morale & co : ce point est très dynamique (la valeur actuelle est gérée par le jeu) et hormis la valeur initiale, qui peut déterminer si un personnage est naturellement résistant aux effets de la peur ou des sorts équivalents, je ne crois pas qu'on puisse faire grand chose là-dessus. Il faut bien se rappeler que les structures contiennent aussi des données qui n'ont de sens que dans leur aspect dynamique, en cours de jeu, et que leur présence dans la structure est nécessaire pour la continuité qu'on veut avoir en reprenant une sauvegarde.

- Lore : appelée Connaissances en français (sert à identifier les objets)

- OBJECT.IDS references : doivent faire partie des données dynamiques dont je parlais (apparemment ça sert aux scripts). A priori, pas besoin de les montrer ni de les saisir. En cas de doute, DLTCEP devrait permettre de savoir si cette information est utile. Au contraire de Near Infinity, qui affiche tout (notamment pour éditer les sauvegardes), DLTCEP est un éditeur avant tout pour créer des mods.

- XXX enumeration value : aucune idée, sans doute donnée dynamique (voir ci-dessus)

- Death variable = script name : super important ! C'est un nom unique pour le personnage. Comme indiqué dans la description, la variable SPRITE_IS_DEADdeathvariable avec une valeur autre que 0 indique au jeu que le personnage est mort (test fait notamment dans les dialogues pour récompenser une fois le méchant tué). Dans les scripts, notamment les cinématiques, c'est via ce nom qu'on fait agir le personnage (d'où le besoin d'unicité également). Nom théoriquement limité à 32 caractères, mais il ne faut pas dépasser 18 (SPRITE_IS_DEAD en fait déjà 14 et une variable ne peut pas non plus dépasser 32 caractères, donc il est impératif que tous les "script name" soit uniques sur les 18 premiers caractères)

- Tracking skill : compétence de pistage du rôdeur

- compétences martiales : dans BG II, il y en a 17, donc ça ne tenait pas avec 6 ou 8. Elles sont gérées via des effets affectés à la créature, plus exactement l'effet "Modify proficiencies" tel qu'il est appelé dans Near Infinity (apparaît dans l'onglet View) ou "Stat: Proficiency Modifier" dans IESDP (code 233).
Là on tombe sur un des gros cas spécifiques à un jeu que j'avais déjà évoqués : même si la version de CRE est identique entre BG et BG II, l'usage est malgré tout différent.

A bientôt

Merci de ton retour Ysaya.

L'interface graphique avance. Ce soir je planche sur l'état du personnage (state.ids), j'ai fait la traduc suivante:

0x00000000 STATE_NORMAL Normal
0x00000800 STATE_DEAD Mort
0x00000400 STATE_ACID_DEATH acidifié
0x00000200 STATE_FLAME_DEATH enflammé
0x00000100 STATE_EXPLODING_DEATH explosée
0x00000080 STATE_STONE_DEATH statufié
0x00000040 STATE_FROZEN_DEATH congelé
0x00000020 STATE_HELPLESS paralysé
0x00000010 STATE_INVISIBLE invisible
0x00000008 STATE_STUNNED absourdi
0x00000004 STATE_PANIC paniqué
0x00000002 STATE_BERSERK enragé
0x00000001 STATE_SLEEPING endormi
0x00001000 STATE_SILENCED silencieux
0x00002000 STATE_CHARMED envouté
0x00004000 STATE_POISONED empoisonné
0x00008000 STATE_HASTED accéléré
0x00010000 STATE_SLOWED ralenti
0x00020000 STATE_INFRAVISION vision nocturne
0x00040000 STATE_BLIND aveuglé
0x00080000 STATE_DISEASED infecté
0x00100000 STATE_FEEBLEMINDED abruti
0x00200000 STATE_NONDETECTION indétectable
0x00400000 STATE_IMPROVEDINVISIBILITY invisibilité amélioré
0x00800000 STATE_BLESS béni
0x01000000 STATE_CHANT chant
0x02000000 STATE_DRAWUPONHOLYMIGHT "ETABLIR LE SAINT POURRAIT"
0x04000000 STATE_LUCK chanceux
0x08000000 STATE_AID soigné
0x10000000 STATE_CHANTBAD ?
0x20000000 STATE_BLUR flou
0x40000000 STATE_MIRRORIMAGE image miroir
0x80000000 STATE_CONFUSED confus
0x00000FC0 STATE_REALLY_DEAD mort définitiviment

Qui peut m'améliorer cette correspondance?

Merci
Coco

La signification des différents bits est fournie sur cette page d'IESDP relative à BG II. Certains bits ont un effet inconnu et leur nom peut s'avérer trompeur.

Pour le reste, j'ai récupéré les textes affichés lorsqu'un sort qui applique cet effet est lancé sur le personnage. Je n'ai pas pu tout trouver car certains textes affichés par le jeu suite à l'application d'un effet à un personnage ne proviennent pas du sort mais de la gestion intrinsèque des effets par le moteur de jeu. J'ai indiqué entre parenthèse le numéro du texte dans le fichier dialog.tlk, ce qui pourrait servir à "traduire" dans la langue du jeu installé.

0x00000000 STATE_NORMAL Normal
0x00000800 STATE_DEAD Mort
0x00000400 STATE_ACID_DEATH Mort par l'acide - Pas exploité par l'effet de mort
0x00000200 STATE_FLAME_DEATH Mort par le feu - Pas exploité par l'effet de mort
0x00000100 STATE_EXPLODING_DEATH Mort par explosion - Pas exploité par l'effet de mort
0x00000080 STATE_STONE_DEATH Pétrifié (14665)
0x00000040 STATE_FROZEN_DEATH Mort de froid
0x00000020 STATE_HELPLESS ?
0x00000010 STATE_INVISIBLE Invisible (14020 ou 14773) - Pas exploité par l'effet d'invisibilité
0x00000008 STATE_STUNNED Etourdi - Pas exploité par l'effet d'étourdissement
0x00000004 STATE_PANIC Panique (14007)
0x00000002 STATE_BERSERK Enragé
0x00000001 STATE_SLEEPING Sommeil (14001)
0x00001000 STATE_SILENCED Silence (14002)
0x00002000 STATE_CHARMED Charmé ou Dominé
0x00004000 STATE_POISONED Empoisonné
0x00008000 STATE_HASTED Sous l'effet de la hâte (14023)
0x00010000 STATE_SLOWED Ralenti (14668)
0x00020000 STATE_INFRAVISION Infravision (14060)
0x00040000 STATE_BLIND Aveuglé (14674)
0x00080000 STATE_DISEASED Malade (?) - N'aurait rien à voir selon IESDP, pourtant utilisé par le script de la deva ou du planaire pour décider de lancer une guérison des maladies
0x00100000 STATE_FEEBLEMINDED Débilité mentale (22612)
0x00200000 STATE_NONDETECTION Non-détecté (14777)
0x00400000 STATE_IMPROVEDINVISIBILITY Invisibilité majeure (?)
0x00800000 STATE_BLESS Bénédiction (14123)
0x01000000 STATE_CHANT Cantique (14124) : sort Cantique
0x02000000 STATE_DRAWUPONHOLYMIGHT Modification de la force (14042) : sort Puiser dans la puissance divine
0x04000000 STATE_LUCK Chance (14019)
0x08000000 STATE_AID Aide (14122) : sort Aide (bénédiction + PV)
0x10000000 STATE_CHANTBAD Victime de cantique (?)
0x20000000 STATE_BLUR Flou (14062) - Pas exploité par l'effet de flou
0x40000000 STATE_MIRRORIMAGE Image miroir (14774) - Pas exploité par l'effet d'image miroir
0x80000000 STATE_CONFUSED Confus (14782) : sort Confusion

0x00000FC0 STATE_REALLY_DEAD Vraiment mort (terme utilisé par opposition à STATE_DEAD)

:!: Ce champ combine potentiellement tous les bits. On peut être tout à la fois ralenti, aveuglé, soumis au silence et sous l'effet de cantique (par exemple).
Ce qui veut dire que tu devrais afficher l'ensemble des bits et surligner ceux qui sont actifs, comme le fait par exemple Shadow Keeper. Du coup, il devient difficile, sauf à ajouter une synthèse en plus (applicable uniquement dans certains cas), de mettre en avant des états synthétiques comme STATE_REALLY_DEAD ou les autres proposés par IESDP.

Cela dit, après réflexion, je ne pense pas que tu aies vraiment besoin de te préoccuper de ce champ dans la structure CRE. Il s'agit avant tout d'une structure qui fournit l'état à un instant t d'une créature. Autrement dit, à moins de vouloir réaliser un éditeur de sauvegarde, l'intérêt d'afficher l'état instantané d'une créature est quasi-nul. Quand tu crées un personnage ou un monstre en vue d'un mod, il est toujours "au repos", donc avec l'état à NORMAL. Indiquer des états autres que celui-ci risque de poser des problèmes : la durée des effets (et donc de certains états) dépend avant tout des effets appliqués à la créature. Il n'est même pas certain qu'indiquer un état sans au moins un effet qui apporte cet état avec les bons paramètres temporels (actif à l'instant actuel dans le jeu) fonctionne.
Autrement dit, si un moddeur voulait affecter des effets particuliers à un personnage, il aurait intérêt non pas à les figer dans la créature mais à lui attribuer un script qui déclencherait les effets opportuns au moment de la rencontre avec le personnage.

L'état sert surtout aux scripts, pour vérifier la synthèse des effets appliqués à un personnage pour le faire réagir (se soigner, par exemple) ou faire réagir ses amis ou ses opposants.

Isaya est difficile à "coller". Il a réponse à tout. Je soupçonne Isaya d'être tombé dedans quand il était petit!

Je suis surpris par le fait qu'il est risqué de créer une créature et de lui mettre un état particulier dans le CRE. Cette l'interface est faite à 80%. J'avais prévu de chercher les icônes correspondants aux états.

L'interface graphique est pas mal avancée sur la partie créature. il me reste:
- le lien entre une créature sélectionnée et son affichage à l'écran.
> Valable uniquement pour le moment par le biais de l'interface 'tableau' (non graphique)

- la prise en compte des mises à jour.
> Valable uniquement pour le moment par le biais de l'interface 'tableau' (non graphique)

- la gestion des règles ADD pour les classes et script. La partie graphique est bien avancée.

- le lien entre la maîtrise des armes et le fichier EFF.

- le lien entre la couleur sélectionnée et sa valeur pour l'apparence. Après création de l'interface, je me dis qu'avoir l'animation dans cet écran serait cool.

- quelques champs à placer dans l'interface (je ne sais pas trop quoi en faire )

- toute la partie Equipement
> ca sera une grosse partie car je veux essayer de tout gérer graphiquement.
Icône des objets, glisser/coller etc... comme dans le jeu.

- toute la partie sorts des Clercs et Mages.
> idem que l'équipement. A voir pour le choix de l'écran (sorts à choisir ou le livre)

- toute la partie son.

- je pense faire un bouton on/off sur l'utilisation des règles ADD. En mode On, une liste de contrôle sera fait sur vos données.
Exemple:
un voleur ne pourra pas lancer de sorts etc...

la CA sera calculée par les règles ADD et non déterminée par la valeur mise par le
moddeur.

D'après certains moddeurs, ils veulent pouvoir avoir une totale libertée mais je trouve génant de ne pas respecter les règles et il y a un risque que le moteur BG bloque sur les données non cohérentes.

J'en oublie sans doute.

Bon ben avec tout ça, vous devez vous dire:
" t'aurais mieux fait de nous dire ce que tu as fait"

Moi je vous réponds, le mieux c'est d'aller voir par vous même! (Et toc!)

Je vais finir deux trois bricoles et je mettrai demain soir une version disponible.

Compte tenu que j'ai aucune expérience en Modding, j'ai vraiment besoin d'avoir un retour de moddeurs pour que l'outil soit le plus intuitif possible.

En tout cas, Grand merci à Isaya qui ressemble de plus en plus au "vieux sage du village' qui porte en lui la connaissance de toute une vie! (non non je ne te cherche pas des noises! )

A demain soir donc!
Coco

Salut,

Vous pouvez télécharger la version "graphique" sous


setup_Editeur_Baldur_Gate_V2_1_1.exe

Il faut aller dans le menu créature | Graphisme .

Comme je l'ai dis dans mon précédent message, le travail n'est pas terminé.

Voici l'écran principal pr ceux qui n'ont pas le courage de jeter un oeil sur l'ensemble des écrans:





Merci de vos retours sur l'aspect opérationnel des fenêtres graphiques!
PROBLEME CORRIGE

Coco

Biographie

"
- Biographie : c'est l'un des numéros de texte (renvoi vers dialog.tlk) de la table "4*100 (Strref*100)", on retrouve facilement lequel en ouvrant un fichier CRE de personnage recrutable dans Near Infinity (il est appelé EXISTANCE5, et 74 BIOGRAPHY_TEXT dans le fichier SNDSLOT.IDS de BG II décrit dans IESDP)
"

Je reformule d'après tes infos et ce que j'ai vu:
-SNDSLOT.IDS: signale que la 74 ième position dans le champ de type "Strrefs pertaining to the character" du CRE donne le numéro permettant d'accéder à la biographie du personnage. La biographie étant localisée dans le fichier dialog.tlk.

J'arrive à lire et afficher la bio.

Quel est le nombre de caractères max? il y a 4 octets. Je ne sais plus comment on fait pour savoir.


Par contre, le sens inverse me parait "vicieux" dans un cadre d'installation multi-mod. Si plusieurs mod mettent à jour ce fichier, il y a un risque de conflit et d'écrasement des données bio ou autre du mod précédent?

Je suppose que Weidu gère ce problème mais comment gérer correctement le problème si je veux me passer de Weidu?

Coco

Cocrane a écrit :Isaya est difficile à "coller". Il a réponse à tout. Je soupçonne Isaya d'être tombé dedans quand il était petit!

Il y a un défaut dans ton analyse : je n'ai pas grandi tant que ça !

Cocrane a écrit :Je suis surpris par le fait qu'il est risqué de créer une créature et de lui mettre un état particulier dans le CRE. Cette l'interface est faite à 80%. J'avais prévu de chercher les icônes correspondants aux états.

Je n'ai pas dit que c'était risqué, juste supposé qu'il y avait peu de chance que ça fonctionne comme attendu. En effet, comme partout, un état est la résultante d'une série d'événements. On ne peut pas être malade si on n'a pas attrapé une maladie, qui va durer un certain temps puis disparaître. Donc il faut avant tout imposer l'effet de maladie, avec la date de fin, pour qu'elle disparaisse bien à terme. Et comme cette fin est indiquée (dans l'effet ajouté au fichier CRE) à une date précise et non avec un délai par rapport à l'instant courant (même si c'est avec ce calcul que le jeu détermine la date de fin), il n'est pas possible de créer un fichier CRE avec de tels effets : tu ignores à quelle date le personnage va effectivement croiser la route du joueur.

Cocrane a écrit :- le lien entre la maîtrise des armes et le fichier EFF.

Ce n'est pas un fichier EFF, juste un effet appliqué avec validité permanente à la créature et dont un paramètre définit la compétence et son niveau. Il va y avoir autant d'effets que de compétences.

Cocrane a écrit :- le lien entre la couleur sélectionnée et sa valeur pour l'apparence. Après création de l'interface, je me dis qu'avoir l'animation dans cet écran serait cool.

- quelques champs à placer dans l'interface (je ne sais pas trop quoi en faire )

- toute la partie Equipement
> ca sera une grosse partie car je veux essayer de tout gérer graphiquement.
Icône des objets, glisser/coller etc... comme dans le jeu.

- toute la partie sorts des Clercs et Mages.
> idem que l'équipement. A voir pour le choix de l'écran (sorts à choisir ou le livre)

- toute la partie son.

C'est sacrément ambitieux, en particulier les histoires de mise en couleur, voir d'animation ! Ça revient à recoder une partie non négligeable du moteur de jeu.

Cocrane a écrit :- je pense faire un bouton on/off sur l'utilisation des règles ADD. En mode On, une liste de contrôle sera fait sur vos données.
Exemple:
un voleur ne pourra pas lancer de sorts etc...

la CA sera calculée par les règles ADD et non déterminée par la valeur mise par le
moddeur.

D'après certains moddeurs, ils veulent pouvoir avoir une totale libertée mais je trouve génant de ne pas respecter les règles et il y a un risque que le moteur BG bloque sur les données non cohérentes.

Dans le cas de la CA, ce choix serait une grosse bêtise. Les monstres ont une CA naturelle autre que 10. Ils ne sont pas dotés d'une pseudo-armure pour leur donner cette CA.
Par ailleurs, la CA afffectée à la créature est sa CA nue, sans équipement. Donc le jeu fait de toute façon le calcul. Mettre une armure à un loup le rendrait encore mieux protégé (CA naturelle + bonus d'armure), à supposer que le moteur de jeu accepte (sans la faire apparaître sur son animation).

Cocrane a écrit :En tout cas, Grand merci à Isaya qui ressemble de plus en plus au "vieux sage du village' qui porte en lui la connaissance de toute une vie! (non non je ne te cherche pas des noises! )

Entendu, je vais donc considérer ça comme un compliment.

J'attends ton feu vert pour jeter un coup d'oeil à la nouvelle version.

Feu VERT! le lien est mis à jour dans le post.

Oui, c'est un compliment!

Ok, pour la CA. En conclusion, si l'idée du mode règles ADD est à conserver, il faudra déterminer la liste des infos à contrôler.

Au niveau de la couleur, je veux pouvoir faire ce que fait le jeu à la création et pendant le jeu. Choisir la couleur de sa peau etc... NI propose des valeurs modifiables. Je suppose donc que ca fonctionne.

Ok, pour l'état. A voir, si tous les champs ne sont pas à paramétrer à la création de la créature.

Cette semaine je vais essayer de bosser la partie Classe/profil et niveau. Il y a pas mal de règles à gérer!

"Il y a un défaut dans ton analyse : je n'ai pas grandi tant que ça !"

Hum hum. Tu fais quelle taille mon petit ?

Coco

C'est sacré projet dans lequel tu te lances, Cocrane...

Penses-tu le développer seulement pour Baldur's Gate ou crois-tu possible de l'étendre aux autres jeux qui utilisent le même moteur (Icewind Dale, Planescape... mais cela voudrait dire prendre en compte les différentes versions des formats de fichiers, ce qui ferait j'imagine pas de boulot en plus) ?

En tout cas bon courage !

Cocrane a écrit :Je reformule d'après tes infos et ce que j'ai vu:
-SNDSLOT.IDS: signale que la 74 ième position dans le champ de type "Strrefs pertaining to the character" du CRE donne le numéro permettant d'accéder à la biographie du personnage. La biographie étant localisée dans le fichier dialog.tlk.

J'arrive à lire et afficher la bio.

Quel est le nombre de caractères max? il y a 4 octets. Je ne sais plus comment on fait pour savoir.

Je ne crois pas qu'il y ait un nombre maximum de caractères bien défini. Le jeu lui-même n'est pas homogène sur ce point, comme l'a en son temps montré le crash provoqué uniquement dans l'écran de choix des sorts à la création d'un personnage dans BG II suite à l'installation de BG2 Fixpack avec une description du sort Familier qui dépassait 4096 caractères (alors que l'affichage du parchemin ou du livre de sort ne posait pas de problème).
Dans ton cas, tu pourrais déterminer la taille en faisant la différence entre deux offsets successifs dans le fichier tlk (les textes se suivant bien, à ma connaissance).

Cocrane a écrit :Par contre, le sens inverse me parait "vicieux" dans un cadre d'installation multi-mod. Si plusieurs mod mettent à jour ce fichier, il y a un risque de conflit et d'écrasement des données bio ou autre du mod précédent?

Je suppose que Weidu gère ce problème mais comment gérer correctement le problème si je veux me passer de Weidu?

Le principe de WeiDU, lors de l'installation, est d'ajouter les nouveaux textes à la suite des existants, ce qui leur attribue des numéros à la suite du dernier. C'est ce nouveau numéro que WeiDU va alors mettre à jour à l'endroit qui va bien dans le fichier CRE, ITM, SPL, ... Cet "endroit qui va bien" est celui indiqué sous la forme SAY NAME @1, où NAME désigne l'offset de la référence de texte pour le nom d'un objet ou d'une créature.

Si l'éditeur devrait aisément se passer de WeiDU (bien que tu puisses aussi utiliser la ligne de commande WeiDU pour ajouter un texte au fichier dialog.tlk), l'emploi de WeiDU sera inévitable pour distibuer le mod. La préparation du fichier d'installation TP2 sera responsable de ça, sachant que WeiDU dispose aussi de l'outil "--automate" pour faciliter la vie du moddeur dans cette phase.

Dans l'éditeur, quand le moddeur va modifier un texte d'une créature existante ou quand il va créer une nouvelle créature, il faudra forcément que l'éditeur ajoute ces textes modifiés à la fin du fichier dialog.tlk (et aussi, au même numéro, dans dialogF.tlk), et référence ce nouveau numéro dans le fichier CRE à l'endroit qui va bien. C'est la solution la plus simple. Lors de la création du mod, peu importe que l'éditeur duplique plein de textes à la fin du dialog.tlk, même s'il vaut mieux que tu vérifies si le texte a vraiment été changé avant d'en ajouter un nouveau dans dialog.tlk.

Pour le reste, j'ai récupéré l'éditeur. Je te donnerai un premier retour dans quelques jours.


Luren : si tu as le courage de lire les messages depuis le début, tu verras que nous avons abordé le sujet. Malheureusement c'est plus compliqué de gérer plusieurs jeux. Même ceux qui utilisent le même format (BG et BG II) présentent déjà des différences sur la gestion des compétences martiales, par exemple. Au-delà du format, Icewind Dale II est d'autant plus particulier que son système de règles est fortement différent car inspiré de D&D 3.
Sans oublier que la belle IHM que nous a montrée Cocrane tomberait complètement à plat.
Cela dit, l'intérêt de travailler en binôme entre vous pourrait contrebalancer le travail supplémentaire à réaliser. Surtout s'il est ciblé sur quelques types de fichiers du jeu.

En tout cas, bon courage pour ton projet ambitieux, lui aussi (je posterai ultérieurement dans le sujet que tu as ouvert).

Salut Luren,
C'est un projet que j'ai commencé en Mars/Avril 2010. Mon but est de créer un éditeur qui soit le moins technique possible pour permettre au plus grand nombre de modder. J'ai aucune envie que des jeux comme BG disparaissent.

De plus, j'ai un scénario qui attend derrière et j'ai pas le courage de le faire avec les outils actuels.

Pour ta question, Isaya a répondu. Quand l'éditeur sera fait et si il est à la hauteur de mes espérances, le code source sera à disposition. C'est codé en WINDEV. J'ai essayé d'être souple mais les graphismes sont effectivement BG.

J'ai joué à ICEWIND 1 il y a fort fort longtemps, avide de continuer à jouer sur un Univers "BG". Le scénario "Baston 99%" m'a usé. J'ai pas joué du coup au 2!
Hormis le scénario que préfères tu à IceWind?

Je profite de cette parenthèse: je suppose qu'il est possible de récupérer un tas de fichiers de IceWind pour enrichir BG? (CRE, ANIME, ITM? SPL). Quelqu'un a t'il fait un mod de ce type?

Coco

Salut Cocrane,

J'aurais du mal à te contredire sur le côté bourrin d'Icewind Dale, vu que c'est ce qui m'a le plus déçu dans ces opus (outre l'absence des coéquipiers recrutables, avec toutes les possibilités scénaristique que cela permet) MAIS (car il y a quand même un mais) j'ai vraiment aimé la qualité des graphismes. Les extérieurs sont très beaux : Havredest, le col de Kuldahar... rien à voir avec les Baldur's Gate ! dont les décors ressemblent à des maquettes. J'aimerais bien me replonger dans l'univers des BG, mais vraiment je bloque sur les graphismes.
Icewind Dale II est malheureusement très bourrin lui-aussi. L'interface est superbe et bien pensé (comme par exemple la possibilité de changer de combinaison d'armes très rapidement : génial pour commencer un combat à distance à l'arc et passer en un clic au combat rapproché) et les décors sont là encore vraiment superieurs à ceux des BG, même si du côté des personnages, rien n'a changé, et si la plupart des monstres sont des reprises de Baldur's Gate, voire de Planescape Torment.
Mais je ne "préfère" pas Icewind à Baldur's Gate (mon meilleur souvenir de jeu restera le premier, pour la liberté dont on disposait). Simplement, c'est celui qui m'a donnée envie de développer un mod, car de la série, c'est le seul dans lequel j'aimerais encore me promener (ce qui n'est hélas plus le cas pour Baldur's Gate I & II...)


Pour la récupération des fichiers oui, c'est possible pour certains. Les créateurs de mod de BG ne se sont d'ailleurs pas privés en général de reprendre des extérieurs d'ICWD !
En général pour tout ce qui est lié au images et au sons, ça se fait assez bien. Pour les autres types de fichiers (créature .cre, scripts, areas) non, les versions étant souvent différentes (les fichiers .cre par exemple n'ont pas la même structure : une grande partie qui servait à paramétrer des sons spécifiques à une créature - et qui d'ailleurs étaient peu usités - sert, sous ICWD2 à indiquer des dons/compétences). De mêmes les scripts sont construits avec des syntaxes différentes (il suffit de comparer les fichiers action.ids et trigger.ids pour s'en rendre compte)

Luren, merci pour la réponse détaillée.

Mes souvenirs remontent à loin mais je me rappele pas avoir vu dans ICWD1 des graphismes nettement meilleurs.

Sais tu si il y a un mod qui existe, reprennant tout ce qui peut être pris des ICWD pour BG.


Biographie / dialog.tlk et TP2
j'écris proprement une entrée dans dialog.tlk. Exemple la bio d'un perso.

C'est assez vicieux qd même car toutes les sections sont impactées. Il ne suffit pas de copier le header, les entrées, de rajouter sa nouvelle entrée puis les textes existants et enfin son nouveau txt.
=> le header évolue et toutes les positions présentes dans la section entrées sont décalées de 26.

Ca marche. Mais je me pose des questions sur la partie dite 'tp2'

Exemple de situation:
- Tu as deux mods.
- Le fichier dialog.tlk utilisé pour chaque mod est le même
- Chaque mod rajoute une seule entrée dans dialog.tlk, c'est la bio. Elle a donc la même position de référence. Exemple: 1000.
- cette référence est inscrite dans le CRE de chacun des mods.

- le joueur veut installer les deux mods et jouer.

Si j'ai bien compris, au final.
On a le CRE du mod 1 qui pointe sa bio sur la ref 1000 de dialog.tlk.
Et on a le CRE du mod 2 qui ne pointe plus sur 1000 mais sur 1001. Et sur 1001 on a bien sa bio.

Si mon éditeur est capable de faire la même chose sans une seule ligne de code à taper, est ce que ca vaut le coup que je travaille sur ce sujet?
Il faudra juste dire: je veux installer mon mod dans le jeu via un clic par exemple.

Information sur les ITM
Existe t'il un autre moyen que de lire chaque fichier itm pour connaitre:
- nom de l'objet
- nom de la BAM associé
- type d'objet (arme etc...)
- ref dialog.tlk décrivant l'objet

j'ai besoin d'avoir une liste des ces informations dans l'éditeur. J'ai une idée mais j'attends les vôtres!

"Euhhh non je ne crois pas au père noël mais je crois que je peux me retrousser les manches! "

Coco

Cocrane a écrit :C'est assez vicieux qd même car toutes les sections sont impactées. Il ne suffit pas de copier le header, les entrées, de rajouter sa nouvelle entrée puis les textes existants et enfin son nouveau txt.
=> le header évolue et toutes les positions présentes dans la section entrées sont décalées de 26.

Comme pratiquement tous les types de fichier, il faut charger intégralement le fichier tlk en mémoire pour faire des modifications, qui ont toujours tendance à décaler tout ou partie du contenu. Dans les fichiers CRE, ajoute un sort dans le livre et tout le reste du fichier est décalé. Le fichier tlk est bien moins "vicieux" que les autres car il n'a que 3 sections et seule la section des textes est décalée.
En réalité, l'en-tête (header) n'évolue pas en taille, juste l'indication du nombre d'entrées et l'offset du premier texte. Mais le nombre d'entrée augmente et comme une entrée occupe 26 octets, tu obtiens bien ce décalage pour le début du premier texte.

Il faut impérativement veiller à impacter les deux fichiers à la fois, dialog.tlk et dialogF.tlk, en tout cas lors de l'installation d'un mod (WeiDU le fait). Même si le second n'est employé que pour les dialogues, il doit avoir le même nombre d'entrées que le premier, donc il ne faut pas laisser de décalage.
Beaucoup d'éditeurs, écrits par les anglo-saxons qui n'ont pas de dialogF.tlk (pas besoin pour eux) ne le font pas. Heureusement, personne ne fait la bêtise de travailler sur son mod dans le même environnement que celui où il installe des mods, et le temps est désormais bien loin où on ajoutait des dialogues via des éditeurs. Donc le processus d'installation avec WeiDU garantit d'éviter des décalages entre dialog.tlk et dialogF.tlk.

Ces remarques m'amènent à réagir à

Cocrane a écrit :Si mon éditeur est capable de faire la même chose sans une seule ligne de code à taper, est ce que ca vaut le coup que je travaille sur ce sujet?
Il faudra juste dire: je veux installer mon mod dans le jeu via un clic par exemple.

Mon conseil : oublie toute idée de "faire concurrence" à WeiDU pour installer un mod. Tu ne pourras jamais rattraper les presque 10 ans de développement de l'outil. Et jamais tu ne pourras proposer une interface graphique ayant ne serait-ce que 10 % des capacités. Ce serait comme espérer avoir un environnement de développement te permettant de réaliser ton éditeur uniquement dans un outil IHM, sans avoir à écrire la moindre ligne de code. Personne en recherche informatique ne court plus après ce rêve, à ma connaissance.
A titre d'exemple, il existait des éditeurs pour créer des dialogues pour le jeu. Ils proposaient une interface à la Infinity Explorer pour créer l'arbre des possibilités. Problème : ils étaient incapables d'offrir un mécanisme de "patch" pour ajouter des choses dans un dialogue existant sans le recopier (et donc l'écraser) intégralement. Seul le langage mis en oeuvre dans WeiDU a permis de dire dans un mod "je veux ajouter une réponse à la réplique numéro N" (cas simple) ou "je veux que mon personnage intervienne après la réplique N de tel méchant pour mettre CHARNAME en garde en lui disant 'bla-bla', le tout sans empêcher que Jaheira ou je ne sais qui y mette aussi son grain de sel comme d'habitude" (cas plus complexe mais encore très simple).

Cocrane a écrit :Ca marche. Mais je me pose des questions sur la partie dite 'tp2'

Exemple de situation:
- Tu as deux mods.
- Le fichier dialog.tlk utilisé pour chaque mod est le même
- Chaque mod rajoute une seule entrée dans dialog.tlk, c'est la bio. Elle a donc la même position de référence. Exemple: 1000.
- cette référence est inscrite dans le CRE de chacun des mods.

- le joueur veut installer les deux mods et jouer.

Si j'ai bien compris, au final.
On a le CRE du mod 1 qui pointe sa bio sur la ref 1000 de dialog.tlk.
Et on a le CRE du mod 2 qui ne pointe plus sur 1000 mais sur 1001. Et sur 1001 on a bien sa bio.

Oui. Mais pour ça, il faut bien que tu penses, au moment où tu veux recopier le fichier CRE, qu'il te faut d'abord ajouter le texte à la fin du dialog.tlk, puis mettre ce numéro dans la case BIO du fichier CRE et enfin écrire le fichier dans Override.

A mon avis, tu as sauté trop vite à l'installation et tu as négligé un truc très important pour la phase de création de mod (le but de ton éditeur) : où gardes-tu tes textes (bio et autres) entre deux sessions d'édition de ton mod ? Dans le fichier dialog.tlk de ton installation du jeu (comme le font les éditeurs existants) ou bien comptes-tu créer ailleurs un fichier mod.tlk pour les nouveaux textes propres au mod ? Ou bien un fichier tra (comme font les moddeurs, à la main) ?
Seule la première méthode (le fichier dialog.tlk) permet de tester à tout moment ta créature, ton sort, ton objet, dans le jeu, sans avoir à t'embêter à réaliser très vite une procédure d'installation de ton mod embryonnaire avec son propre fichier TP2, en pertpétuelle construction (à compléter à la main à chaque fois que tu ajoutes une nouvelle créature, ...). Ce mode de fonctionnement est vital pour le moddeur qui essaie de mettre au point son objet ou son sort.
Une fois qu'il est au point, oui, il vaut mieux l'intégrer dans un fichier TP2, avec les textes dont il a besoin. C'est la meilleure méthode de sauvegarde que tu puisses imaginer. Elle rassemble, en un minimum de fichiers (TP2, un ou plusieurs tra, les CRE, ITM, ... du mod) tout ce qui est propre au mod, sans se taper un fichier de 10 Mo (le dialog.tlk) juste pour quelques textes.
Sinon, qu'adviendra-t-il si le moddeur perd le dialog.tlk pour une raison ou pour une autre ?

Ta préoccupation pour l'éditeur devrait être de traiter un mod, celui qui est en création. Non de savoir comment installer plusieurs mods de façon respectueuse. Il faut que le créateur de mod respecte un certain nombre de règles permettant d'offrir une compatibilité optimale (mais pas forcément parfaite, car la perfection ne peut pas exister) avec les autres mods (de façon générale) ou avec un mod en particulier (si les deux modifient à leur sauce un aspect du jeu). Ton éditeur pourra au mieux éviter de ruiner les efforts du moddeur. Mais il ne pourra jamais vraiment aider le moddeur à favoriser la compatibilité : même un moddeur chevronné ne pourrait pas le faire, tant c'est complexe. WeiDU lui-même se contente de mettre des outils à disposition pour ça via son langage.

Je pense que tu as largement assez de temps à consacrer à des éditeurs de créature, d'objet et de sort (des formats "simples") pour y passer probablement plus de temps que tu ne sembles imaginer. Même en renonçant à des fioritures que tu as évoquées (glisser-déposer, contrôle des règles, animations, ...). Alors inutile de vouloir jouer déjà à Monsieur Plus !

L'éditeur actuel

Avec toutes mes palabres, je n'ai pas encore eu le temps de te communiquer mes premières impressions après 1 petite heure passée dans l'éditeur. Je le ferai ce week-end.
Je n'ai pas rencontré de véritable problème. Il y a plusieurs choses qui ne semblent pas fonctionner sans pour autant avoir un message indiquant que ce n'est pas réalisé. Je suppose que c'est normal (fenêtre affichée mais beaucoup de champs ne sont pas renseignés).
Il me faudra passer un peu de temps à bidouiller des captures d'écran pour te suggérer des réaménagements de l'IHM. Dans les écrans non graphiques, il y a à la fois des fenêtres très chargées (trop, voire même beaucoup trop) et d'autres un peu vides (à raison) mais qui dispersent les boutons dans tous les coins (on fait des kilomètres à la souris).
Dans la partie graphique, j'ai à me "plaindre" de lenteur de réaction dans l'affectation des points de talent (heureusement que je n'en ai pas 250 à affecter, comme au début de SoA ) : pourtant j'ai un quad-core (l'éditeur dit qu'il charge les fichiers de ToB en 5 s) aussi je pense qu'il s'agit peut-être d'un réglage à améliorer dans la réaction des boutons ou d'un mécanisme de maintient appuyé à ajouter.
Par ailleurs, je n'aime toujours pas le "splash screen" non débrayable qui occulte tout mon écran pendant plusieurs secondes.

Les détails, plus tard.

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?

Comptes tenu que je travaille sur la partie création, je suis obligé de me demander comment ces informations doivent être transmises pour être installée dans le jeu.

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.

-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.

- A la réouverture de l'éditeur et de la visualisation d'un fichier avec mention*, je consulte \mod. L'étoile signifie que le fichier provient du mod en cours. Sinon je lis le fichier en provenance du jeu.

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.

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.

Editeur actuel
La version mis à disposition est en chantier.

Je l'ai transmise dans le but de vous montrer la partie graphique afin de savoir si cette présentation vous plait et si c'est la bonne piste.

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 menu 'liste base' est effectivement en total 'bordel' car c'est une fenêtre de test pour mes accès au fichiers IDS notamment. Elle ne sera pas conservée.

Point de talents
C'est noté pour la lenteur. 2nd retour sur le sujet. Je pense que c'est une maladresse que je devrais pouvoir corriger.

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!

Coco