La Couronne de Cuivre

Salut Isaya,

j'avance effectivement mais il reste beaucoup de travail.

"Pour chaque jour une brique sur le mur".

L'anglais
Ahhhhh pourquoi c'est pas le Fançais la langue internationale...
Je déteste pas mais l'effort pour apprendre cette langue ne me passionne pas. L'éditeur est très consommateur de temps, j'essaie donc de me focaliser sur sa réalisation.

Editeur internationnal
Le but est effectivement de choisir la langue pour l'affichage dans les paramètres.

Le fichier "langue" peut aussi être un csv. effectivement, ça permet de voir les données et d'écrire dans un fichier excel que l'on sauvegarde au format CSV.

J'attends donc des courageux.

Interface Graphique
Mon but est de réaliser l'éditeur un peu dans le style du jeu en respectant les couleurs et formes si possible.
On pourra toujours voir les données du fichier dans le style que je réalise en ce moment.

Le but est d'avoir l'impression que c'est l'éditeur du jeu.

La structure des fichiers
Les données en général ne sont pas expliquées. Existe t'il une documentation quelque part?

Un éditeur avec des Tutos sur le rôles de chaque champs et une fiche de savoir faire pour réaliser une action précise. Là le modding deviendrait bcp plus simple.
Chacun apportant une pierre à l'édifice. On aurait une doc de plus en plus complète.
Je suppose que le sujet a déjà était abordé.

Fichier .IDS
J'avais l'impression que pour un fichier IDS donné, c'était toujours la même chose?
Il peut changer en fonction des mods?

Données avec "exploitation Binaire"
Je me doutais de quelque chose dans ce style mais je suis très rouillé sur les conversions. Tes infos m'ont mis sur la voie.

Vu que j'ai la flemme j'ai déjà trouvé un code fait en Windev tout simple pour convertir. . Le net quelle belle trouvaille .
si on pouvait taper "Editeur BG simple et prêt à l'emploi" ça serait merveilleux

En attendant

Longue vie à BG!
Coco

J'ai installé l'éditeur hier. Il semble bien tenir compte de l'option --game d'après les listes de fichiers ou même les indications de WeiDU dans les fenêtres DOS lorsqu'elle restent visibles assez longtemps.

A première vue, l'éditeur différencie les noms en majuscules des noms en minuscules. Du coup on a d'abord les A-Z puis les a-z. Ce qui fait qu'on a l'impression qu'il manque des fichiers, tout simplement parce qu'ils sont considérés en minuscules et donc classés après le Z. C'est très perturbant. Je pense qu'un classement ne tenant pas compte de la casse serait préférable.
J'ai eu beaucoup de mal à me faire à l'affichage des créatures, en particulier dès qu'on a à faire à une table, telle que celles des sorts. J'avais l'impression que l'éditeur n'affichait que le premier, jusqu'à ce que je me rende compte qu'il y avait des boutons de parcours, mais tout en bas de l'écran. Une table des éléments en question, dans laquelle on pourrait sélectionner celui que l'on veut visualiser en détail ou modifier serait bien plus pratique que de devoir faire défiler en aveugle. En particulier, un prêtre de haut niveau a beaucoup de sorts connus et c'est long d'atteindre les derniers.

L'affichage des textes du fichier dialog.tlk semble bien fonctionner.

Je n'ai pas fait beaucoup de manipulations, en particulier aucune tentative de modification et de sauvegarde.


Passons maintenant aux autres points.

Je n'ai trouvé aucune trace des fichiers textes dont tu parlais, seulement des fichiers binaires .FIC qui contiennent les textes au milieu de plein d'autres éléments binaires. Je suppose que ce que tu as évoqué est une proposition d'évolution.
J'ai un peu peur que ton appel à traducteurs passe un peu inaperçu au milieu des autres discussions. Il vaudra mieux créer un sujet spécifique sur ce point. Toutefois, j'ai un peu peur qu'on nous laisse continuer notre discussion de peur de nous déranger...

L'interface graphique que tu évoques me rappelle celle de IEEP. Choisir l'aspect graphique du jeu, ça veut dire choisir un jeu (BG II, le plus courant pour les moddeurs) ou avoir une série de skins pour chacun des 5 jeux. Et ça veut surtout dire la capacité à traiter toutes les subtilités de chacun des jeux. On a beau parler de l'Infinity Engine, il en existe en réalité autant de variations que de jeux, sans compter des différences plus ou moins importantes entre le jeu de base et le jeu avec extension.
Comme tu travailles clairement sur une base Baldur's Gate II, tu ferais mieux de présenter l'éditeur comme un éditeur pour BG II uniquement. Rien que le format de créature que tu gères actuellement fait que l'éditeur ne peut probablement fonctionner qu'avec Baldur's Gate et Baldur's Gate II (CRE V1). Bref Editeur Baldur's Gate n'est peut-être pas le bon nom.

IESDP est la meilleure source d'information que nous ayions. Les différents tutorials peuvent parfois éclairer sur un aspect ou un autre, en particulier sur la signification des différentes valeurs d'un champ. Mais malheureusement il n'existe pas de base de données telle que tu la voudrais. Vu l'étendue à couvrir (nombre de champs x nombres de valeurs, sans oublier les éventuelles répercutions ailleurs), on pourrait se demander quelle taille elle aurait, d'ailleurs. Ce serait un travail de titan qui n'irait certes pas jusqu'à la dimension de Wikipédia, mais bien conséquent tout de même...
Il suffit de regarder le Wiki sur l'éditeur pour Dragon Age pour se rendre compte que les éditeurs ne font pas forcément beaucoup mieux que les amateurs bénévoles qui ont dû tout déterminer par eux-même. Même si le Wiki a l'énorme avantage d'être plus didactique, au détriment de l'aspect document de référence.

En ce qui concerne les fichiers IDS, je confirme la nécessité de ne pas considérer que ces fichiers sont figés. Leur nombre et leur contenu diffèrent entre Baldur's Gate II avec et sans Throne of Bhaal. Ils comportent d'énormes différences entre BG et BG II. Des mods ajoutent allègrement des entrées dans certains fichiers : sorts, combinaisons d'états, pour n'en citer que deux.
A un moment ou à un autre, tu seras probablement également amené à manipuler certains fichiers 2DA, qui sont également la "proie" des mods (ajout de kit, de PNJ, ...).

A plus

Cocrane a écrit :Fichier .IDS
J'avais l'impression que pour un fichier IDS donné, c'était toujours la même chose?
Il peut changer en fonction des mods ?

Je connais au moins un mod qui modifie un fichier .IDS : L'ex mod Improve Battle qui a été remplacé par le mod Revised Battle.

Dans ses deux mods, c'est le même fichier qui est remplacé : STATS.IDS.

De ce faite, je pense que tu vas devoir considérer que les fichiers IDS peuvent varier suivant l'installation du joueur.

Gestion des installations Mods
Ca marche! Enfin

Affichage des fichiers dans les tableaux
Oui le tri par défaut est sensible aux Majuscules/Minuscules. Je vais voir pour ne pas être sensible à la casse.

Gestion des tables et affichages
Je n'ai pas bien compris ton problème.

Tu as un tableau listant les fichiers disponibles. Si tu double-clique sur l'un des fichiers, les données s'affichent dans les différents onglets sur ta droite.
Les onglets représentent les "sections" décrites dans la structure du fichier. Si la section se répète pour un fichier ouvert tu as un indicateur sur le coté.
Ex: 1/5. 1 Pour la position en cours et 5 pour la position max.

Si tu veux ouvrir un fichier particulier, tu peux taper son nom dans une cellule du tableau ou faire défiler le tableau.

Des liens seront mis en place entre les fichiers. Par exemple, un fichier CRE fait référence à un fichier de dialogue notamment. En cliquant sur un lien, la fenêtre de dialogue s'ouvrira et affichera les données du dialogue de la créature concernée.
NI le fait déjà et c'est tout à fait logique de procéder ainsi.

Fichiers texte
Ces fichiers sont utilisés par des fenêtres de développement (importation des structures des fichiers).
Je peux fournir ces fichiers si quelqu'un est près à bosser sur le sujet. Mais d'une manière générale, on a des lecteurs mais pas de personnes qui participent. Je suis sur qu'on passe à coté d'informations très utiles. Dommage...

La structure des fichiers est très proche de la présentation de Gibber:
J'ai fait un copier coller dans un fichier et mis quelques règles de présentation pour permettre d'intégrer le contenu. C'est très pratique pour éviter de tout copier à la main dans la base de l'éditeur et pour éviter les fautes d'orthographes.

"un bon informaticien est un informaticien faignant! "

Les fichiers .FIC et .NDX sont des fichiers de base de données de Windev. Un nom de fichier par table.

L'interface graphique
L'éditeur a pour but de gérer la Trilogie BG. D'après ce que j'ai vu c'est les mêmes version de fichier pour les trois à quelques exceptions sans doute.

Par exemple, le fichier EFF v1 et V2 qui est utilisé par les trois.
C'est d'ailleurs l'origine de mon décalage de données dans les CRE avec données EFF.
A corriger.

Il est assez 'facile' de charger tous les fichiers à partir du moment où lire un fichier binaire n'est plus un problème. La difficulté pour le moment réside dans la répétition des sections qui sont pilotés par des noms de champs spécifiques à chaque fichier. Tout ceci n'étant pas expliqué, il faut le déduire de la structure et du résultat obtenu par NI.

Ensuite le gros soucis, c'est les règles liées à ces fichiers qui diffère d'un jeu à un autre.
Là c un peu trop lourd à gérer pour le moment pour les autres jeux.

Donc pour moi, c'est bien un Editeur pour BG.

J'ai peut être raté une contrainte?

Les fichiers IDS

Isaya, Dédalus c'est noté.

Je suis en train de faire une fonction standard qui charge les fichiers IDS un par un. Ce chargement pourrait être une option paramétrable avec pour valeur par défaut "Oui".

On aura donc n ouvertures de fichier IDS par Weidu au démarrage. Ce chargement pourrait être une option dans les paramétrages avec pour valeur "Oui" par défaut.

Tous les fichiers IDS ne se présentent pas pareil. Cependant du moment que le Moddeur respecte la syntaxe du fichier IDS qu'il modifie, il n'y aura pas de soucis.

La prochaine version n'arrivera pas je pense avant 15j-3 semaines. Un grand we se profile à l'horizon.

Bon courage à tous les moddeurs!

Franchement, venez parler de vos besoins, c'est le moment.

Retour sur la question des tables

Je vais tâcher d'être très clair. Quand j'ouvre une créature qui est un prêtre de haut niveau, par exemple ANOMEN12.CRE, et que j'ouvre l'onglet "Know_Spells", j'ai à faire à un seul sort. Mais, en bas à droite de l'écran, soit à l'autre bout du monde sur mon écran 24 pouces puisque l'éditeur s'ouvre en plein écran, j'ai une indication "1/7". En soi, ça semble erroné, car même un prêtre de niveau 1 connaît plus de 7 sorts. Si je clique plusieurs fois sur >, j'obtiens d'ailleurs "8/7" puis si je clique sur >> , "78/". Bref, il y a un défaut d'affichage de cette information. Par ailleurs, elle serait bien mieux placée à proximité des boutons de parcours, voire même au milieu (cf Near Infinity).

Dans tous les cas, mon propos principal est que j'aimerais bien avoir simplement une table de tous les sorts, de façon à ce que je puisse en choisir un avant d'accéder aux détails du type "Spell_Level_1" et "Spell_type". Autrement dit, avant d'avoir les détails, j'aimerais bien, comme avec la liste des créatures, avoir simplement le nom du sort (ici SPPRxxx). Parce que 78 éléments (et ce n'est pas le maximum), ce n'est pas pratique à parcourir un par un pour retrouver un élément en particulier.

Idéalement, à terme, ce serait bien d'avoir le nom du sort (Soins mineurs) et non le nom du fichier sort (SPPRxxx). Mais pour cela, il faudrait que tu mettes en place un moyen d'accéder directement aux informations du jeu sans avoir besoin de WeiDU à tout bout de champ. On pourra en reparler, mais ce n'est pas prioritaire.


Les fichiers IDS

WeiDU sait parfaitement exploiter les expressions régulières (ou rationnelles) pour manipuler des fichiers. Tu trouveras d'ailleurs des exemples d'utilisation avec --biff-get dans le chapitre 6 de la documentation WeiDU.
Dans le cas des fichiers IDS, tu peux facilement récupérer tous les fichiers IDS depuis les fichiers BIF en utilisant la commande :

"X:\Chemin WeiDU\WeiDU" --game "Y:\Chemin jeu" --biff-get .*\.IDS --out "X:\Chemin editeur\Editeur_Baldur_Gate\Tmp"

Comme pour les autres fichiers, il se peut qu'il y ait dans le répertoire Override des versions plus récentes de ces fichiers, voire d'autres fichiers IDS. Il te faudra donc recopier dans le répertoire Tmp (dans mon exemple, libre à toi de les stocker ailleurs, histoire de ne pas mélanger avec les autres fichiers manipulés) tous les fichiers IDS du répertoire Override, en n'oubliant pas que la liste peut alors devenir plus importante.

En principe, le créateur de mod ne doit pas être autorisé à modifier directement un fichier IDS dans ton éditeur. Depuis l'apparition de WeiDU, il ne faut plus écraser un fichier donné mais au contraire écrire un patch pour le modifier ou le compléter. Un éditeur "idéal" autoriserait le moddeur à modifier le fichier mais créerait alors un patch (une séquence d'instruction WeiDU) permettant d'obtenir le résultat final à partir du fichier de départ. Sauf que cet "idéal" est inatteignable, sauf cas très particulier, parce que le fichier de départ n'est pas forcément celui qu'avait le moddeur dans son environnement de travail et que le joueur a probablement installé des mods que n'a pas le moddeur. Par conséquent, le moddeur devra toujours écrire lui-même à la main les instructions WeiDU de patch.


Textes à traduire

A vrai dire, je n'ai pas compris ce que tu voulais dire. Le contenu du fichier FIC est-il le résultat de l'exploitation du fameux fichier texte, où le nom du champ dans la base de donnée serait celui donné par IESDP ?


La compatibilité avec la trilogie

Le terme trilogie est particulièrement ambigu : si tu te réfères à BGT, alors tu n'es compatible qu'avec BG II + ToB et rien d'autre !
Il y a déjà des divergences entre Baldur's Gate et son extension TotSC : le format EFF est apparu avec l'extension, donc seule elle s'en sert. Par ailleurs les triggers et les commandes de script évoluent toujours à chaque sortie de jeu ou d'extension. Cela se répercute notamment sur les fichiers IDS dont certains font la liste de ces éléments.

Ne serait-ce qu'au niveau des fichiers CRE, BG II a modifié considérablement la gestion des compétences martiales (épée, arc, ...) : on est passé de 6 dans BG et TotSC à 17 dans BG II. La façon de mémoriser cela a changé : alors que dans BG et TotSC les 6 catégories se trouvent directement dans la structure CRE, dans BG II ces 6 catégories sont a priori ignorées (ou le moteur gère "en dur" une conversion vers les 6) et les points de compétence sont mémorisées sous forme de structures EFF avec un numéro d'effet particulier qui signifie compétence martiale.
Dans la présentation de l'éditeur de créature, il faudra bien que tu sois capable de gérer correctement ces 6 ou 17 compétences (selon le jeu visé). Un moddeur aimerait bien pouvoir indiquer simplement la compétence en épée longue de son guerrier sans avoir à ajouter le bon EFF avec le bon paramètre pour désigner la catégorie épée longue. C'est ce qu'impose DLTCEP. Mais de son côté Creature Maker propose bien les catégories du jeu.
Puisque tu veux faire l'outil idéal, tu peux déjà noter cette suggestion.
De même, un personnage de ToB pourra avoir des compétences de haut niveau (tornace d'acier, ...), là aussi gérés par des structures EFF. L'idéal serait là-aussi de pouvoir les ajouter plus facilement. Mais cet aspect-là est encore plus particulier que la gestion des compétences martiales, spécifique à ToB, et nécessiterait en plus de tenir compte de la classe du personnage.

Sur ces deux points, les joueurs et moddeurs ont souvent reproché que les adversaires dans le jeu exploitaient très peu voire pas du tout la description des compétences martiales de BGII ou les compétences de haut niveau. On peut penser que l'éditeur de Bioware n'était pas bien doté non plus pour paramétrer ce genre de choses.

Gérer ces spécificités suppose que tu mettes en place un moyen d'identifier le type de jeu. Certains éditeurs le font tout seul, en fonction du contenu du répertoire désigné. Mais la plupart demandent au moddeur d'indiquer le jeu correspondant, en distinguant toujours le jeu de base et avec son extension (s'il y en a une).
Ce n'est pas non plus prioritaire. Mais il est bon de garder à l'esprit qu'au delà des formats de fichier, il faudrait également avoir des tables d'informations ou du code conditionné par le jeu et l'extension visés.


Garde à l'esprit que mes remarques ne sont pas toutes de la même importance. Je te suggère de viser en priorité BG II avec ToB car c'est la base exploitée par la plupart des mods, y compris ceux qui ne se déroulent qu'en Amn.
En ce qui concerne les capacités de l'éditeur en terme de fichiers, plutôt que de proposer plein de types de fichiers de façon trop complexe à manipuler (type Near Infinity), il vaudrait mieux que l'éditeur sache d'abord manipuler parfaitement un ou deux types de fichiers. En tout cas, c'est mon opinion.
Les créatures sont un bon exemple de domaine à améliorer : Creature Maker a quelques bonnes idées mais semble buggé tandis que DLTCEP ou Near Infinity exigent de bonnes connaissances du moteur de jeu (pour les compétences).

Dernier post avant Mardi soir.

Les sorts d'ANOMEN
Pour Anomen12, tu devais voir '1/8' à l'écran. La réalisé c'est '1/80'. J'ai agrandi le tableau contenant la liste des créatures pour gérer l'affichage de '*' dans le cas d'un fichier d'OVERRIDE. Cet agrandissement a décalé les onglets et l'affichage du compteur '1/80'. Du coup, le zéro ne s'affichait plus.
> c'est corrigé.

Pour la liste des sorts, c'est noté. Compte tenu du peu d'information de cette section, on peut faire un tableau listant les sorts du pnj. En cliquant dessous, on affichera la fenêtre des sorts sur le sort en question.

Pour afficher le nom du sort lié au nom du fichier, c'est plus délicat. Le vrai nom est lié à une référence présente dans le fichier SPL si je raisonne bien. Et cette référence permet dans le fichier dialog.TLK d'avoir le nom du sort.
Effectivement ça fait beaucoup de fichiers à ouvrir quand on se nomme Anomen. Si tu as une solution plus pratique, je t'écoute.

Les fichiers IDS
Oui je compte me servir de la liste des fichiers IDS obtenu par WEIDU pour charger l'ensemble des fichiers IDS du jeu. Je n'avais pas pensé à consulté l'OVERRIDE.

Par contre, tu m'annonces qu'on peut avoir de nouveaux fichiers IDS liés à des mods!
Ca c'est de la nouvelle.
Je ne comprends pas comment c'est possible, si le fichier IDS n'est pas connu à l'origine comment le moteur du jeu peut l'utiliser?
De plus, je charge les structures dans des tables que j'ai déclaré dans ma base. Si le cas se confirme, je dois travailler avec des tables temporaires. Mon code 'IDS' sera à revoir dans ce cas.

Fichier Texte
1- je vais sur le site Gibber et je choisis un fichier où je veux voir sa structure
2- je copie colle la page dans un fichier txt que je renomme
3- je fais quelques modifications de présentations mineures
4- je lance une importation du contenu du fichier dans l'éditeur ligne par ligne.
> une table Type se remplit ligne part ligne avec les champs suivants:
- extension (ex: CRE)
- Version (Ex: V1.0)
- nom du champ (Ex: Long_name)
- type de variable (Ex: strref)
- taille de la variable (Ex: 4)

On pourrait ici ajouter un champ Nom par langue que l'on veut gérer. Après il faut l'alimenter par un fichier d'entrée.

Le contenu de la table Type_CRE.fic est crée. C'est l'équivalent de la description du fichier mais en base de donnée. C'est plus pratique à utiliser dans le code.
Les .fic sont spécifiques à Windev.

La compatibilité avec la trilogie
Je prends note de tes informations et remarques. A terme mon but, c'est que l'on puisse modder sur la version que l'on veut de BG. De ce que j'ai vu BG1 est peu utilisé en Mod. A voir si ca en vaut la peine finalement.

D'une manière générale:
-soit le moddeur devra signaler son environnement (ce qui me parait à chaud sage comme choix)

-soit selon le type de fichier utilisé

- soit une autre solution?

Un moddeur BG1 qui veut utiliser un PNJ de TOB peut donc se retrouver avec un beau plantage. Il y a p.e un refus à mettre en place ou une conversion descente/ascendante.

A réfléchir pour ma part.

Merci de tes retours.
Coco

Les noms de sorts

Pour moi, la solution viable serait d'intégrer à terme la capacité à accéder à un fichier sans avoir besoin de WeiDU. Manipuler le fichier chitin.key et les fichiers BIF n'est pas insurmontable. Il faut cependant avoir la possibilité de lier à ton programme la bibliothèque Zlib (elle existe en DLL) si jamais WinDev n'offre pas déjà la capacité de décompression de cette bibliothèque (même méthode que le format zip).
Near Infinity fait ça sans difficulté et avec célérité. Et sans DLL, en pur java manifestement (ou la capacité est incluse dans la machine virtuelle).
On pourra en reparler : ce n'est pas prioritaire mais ce serait pénalisant de ne pas avoir cette capacité en version finale.


Fichiers IDS

Je n'ai pas écrit que les mods en ajoutaient (je n'en suis pas sûr), simplement qu'au moins un fichier IDS, MusicList.IDS pour être précis, n'existe pas dans les fichiers BIF (en tout cas n'est pas extrait des fichiers BIF par WeiDU avec la commande que je t'ai indiquée).
Dans ce cas, l'explication est "simple" et connue : le fichier ne gère que des noms de fichiers sur 8 caractères. En particulier l'index constitué par le fichier chitin.key ne prévoit que 8 caractères par nom de fichier à l'intérieur d'un fichier BIF. La présence du fichier MusicList.IDS dans le répertoire Override s'explique par le fait qu'il fait 9 caractères et qu'il ne pouvait donc pas être intégré dans un fichier BIF.

C'est probablement la seule exception. Mais de toute façon, il te faudra appliquer systématiquement, pour tous les types de fichiers, le principe d'exploiter en priorité la version d'un fichier se trouvant le répertoire Override par rapport à celle se trouvant éventuellement dans un fichier BIF.
En tout cas, des mods vont modifier des fichiers IDS, donc la version se trouvant dans le répertoire Override.


Fichiers texte

J'ai compris le mécanisme. Il faudrait donc que tu fournisses ces fichiers textes, puis que tu reprennes tout le code des bases de données une fois que ce sera traduit. Ouch !
Je ne sais pas si WinDev comporte des mécanismes simples pour gérer des applications multi-langues. Si oui, il vaudrait mieux séparer les textes à traduire de ta structure de base de données et exploiter la capacité de WinDev à traiter les textes d'IHM avec capacité multi-langues. Parce que le fait de devoir reconstruire tous tes fichiers de "base de données" est vraiment pénalisant pour un "simple" ajout de traduction.


Compatibilité

Il existe des moyens de détection automatique. Near Infinity se débrouille tout seul. En gros, le principe est de détecter la présence de certains fichiers : .ini (baldur.ini, icewind.ini, ...), .exe ou autre. Pour BG et BG II, le .ini est le même. La présence des extensions peut se vérifier par l'existence de certains fichiers BIF.
A moins qu'un vicieux ne crée un fichier bidon du même nom que celui testé, ça devrait éviter de laisser faire des choses inappropriées.

Bon week-end.

Les noms de sorts
A voir sur le plan technique.
Je suis d'accord que le but final est de ne pas être dépendant de Weidu.

Fichiers texte
L'intégration n'est pas brutale. Juste à copier le fichier au bon endroit et ensuite je clique sur le fichier à lire.

Je donnerai un fichier pour le CRE dans ma prochaine livraison de l'éditeur. On peut aussi envisager la solution la plus viable dans le temps qui était de partir sur un support tableur.
Chaque colonne correspondant à une langue.

Fichiers IDS
Je vais tenir compte de du répertoire Mod, de l'override et du jeu dans cet ordre de priorité.

2 questions:
- existe t'il une ligne de commande WEIDU permettant d'extraire en une fois les fichiers .IDS du jeu. Cela évitera d'avoir de lancer Weidu pour chaque fichier et d'avoir n écran WEIDU.
J'ai testé une commande du type: weidu.exe --bif -get *.IDS --out 'chemin de sortie'
Ca ne fonctionne pas. J'ai testé avec des %,? etc... d'après les termes possibles signalés.

- tous les fichiers IDS n'ont pas la même structure
un chiffre seul en première ligne? c'est l'équivalent du None?

une ligne du type "0x00000000 STATE_NORMAL " où l'on a la valeur du BIT suivi de la valeur.

Une ligne du type "145 ELEMENTAL" avec une valeur numérique suivi du nom du champ

Une ligne du type "0x001D DAGGER" avec une valeur de type Hexa apparamment.

C'est assez surprenant de voir autant de diversité.


Compatibilité
si je comprends bien un fichier version TOB est pris en charge sans soucis dans un MOD BG1?
A voir.

Coco

Cocrane a écrit : Fichiers texte
L'intégration n'est pas brutale. Juste à copier le fichier au bon endroit et ensuite je clique sur le fichier à lire.

Je donnerai un fichier pour le CRE dans ma prochaine livraison de l'éditeur. On peut aussi envisager la solution la plus viable dans le temps qui était de partir sur un support tableur.
Chaque colonne correspondant à une langue.

Ma proposition de fichier type CSV ne visait qu'à rendre les séparations de colonnes plus lisibles et à éviter tout problème avec l'incapacité à distinguer un espace d'une tabulation dans un éditeur de texte, augmentant le risque que le traducteur ne fasse une erreur et qu'il manque une tabulation de séparation ou qu'il y en ait de trop.
On peut déjà essayer avec le format que tu manipules pour le moment.

Cocrane a écrit :Fichiers IDS
Je vais tenir compte de du répertoire Mod, de l'override et du jeu dans cet ordre de priorité.

2 questions:
- existe t'il une ligne de commande WEIDU permettant d'extraire en une fois les fichiers .IDS du jeu. Cela évitera d'avoir de lancer Weidu pour chaque fichier et d'avoir n écran WEIDU.
J'ai testé une commande du type: weidu.exe --bif -get *.IDS --out 'chemin de sortie'
Ca ne fonctionne pas. J'ai testé avec des %,? etc... d'après les termes possibles signalés.

Je te prends en flagrant délit : tu n'as pas bien lu mon avant-dernier message avant ta réponse !
Je t'avais indiqué la commande à utiliser pour extraire tous les fichiers IDS, en insistant bien sur le fait que WeiDU utilisait les expressions régulières et non pas les jokers MS-DOS ! La forme .*\.IDS que j'ai employée est très importante ! Elle signifie de 0 à une infinité de caractères quelconque (. désigne un caractère quelconque dans une expression régulière) suivi d'un véritable point (le \ qui précéde le point indique qu'on veut changer la signification "régulière" du point et qu'on veut rechercher un véritable point). Pour plus de détails, suis le lien que j'avais indiqué. Il donne des exemples.

Cocrane a écrit :- tous les fichiers IDS n'ont pas la même structure
un chiffre seul en première ligne? c'est l'équivalent du None?

une ligne du type "0x00000000 STATE_NORMAL " où l'on a la valeur du BIT suivi de la valeur.

Une ligne du type "145 ELEMENTAL" avec une valeur numérique suivi du nom du champ

Une ligne du type "0x001D DAGGER" avec une valeur de type Hexa apparamment.

C'est assez surprenant de voir autant de diversité.

Les fichiers IDS ont des objectifs très différents et n'utilisent donc pas un formalisme unique. Quoi de commun entre une liste des sorts de prêtre/mage/innés (SPELL.IDS) et la liste des codes de compétence martiale () ?
En pratique, la forme est quasiment tout le temps la même (il y a très peu d'exceptions, comme ANISND.IDS) : la première colonne est un nombre, la seconde l'élément textuel qui correspond à la valeur de la première colonne. Peut importe que le nombre soit exprimé en hexadécimal (Ox----) ou en décimal. Au final la première colonne est un nombre qui désigne la valeur associée.
Ainsi les fichiers TRIGGER.IDS et ACTIONS.IDS donnent les codes associés aux triggers et aux actions une fois le script compilé sous forme BCS. ALIGN.IDS indique les valeurs possibles pour l'alignement dans le champ correspondant d'un fichier CRE, CLASS.IDS les valeurs possibles pour un champ de classe de personnage...
Beaucoup de champs de structures CRE, ITM, ... font référence à des valeurs qui doivent forcément faire partie d'une table dans un fichier IDS.
En fait, en plus des définitions de taille et de nom associé à un champ d'une impulsion, il te faudrait pratiquement ajouter un paramètre supplémentaire pouvant indiquer à quel fichier IDS le champ se rapporte (mais il n'y a pas toujours de relation). Je pense qu'un éditeur comme Near Infinity a codé cette correspondance en dur. Mais il est flagrant qu'il s'en sert pour proposer les listes de valeurs possibles.

Cocrane a écrit :Compatibilité
si je comprends bien un fichier version TOB est pris en charge sans soucis dans un MOD BG1?

Ah non, je n'ai pas du tout voulu dire ça ! Ce serait même complètement faux. Dans le meilleur des cas, le jeu le plus évolué, ToB, pourrait lire des fichiers d'origine BG1, à supposer que ToB utilise de son côté une version plus évoluée (mais beaucoup de fichiers ont un format unique de BG1 jusqu'à ToB). Mais BG1 est absolument incapable de comprendre des formats de fichiers propres à ToB, qui n'existaient probablement même pas encore dans la tête des concepteurs quand ils réalisaient Baldur's Gate !

Isaya a écrit :La forme .*\.IDS que j'ai employée est très importante ! Elle signifie de 0 à une infinité de caractères quelconque (. désigne un caractère quelconque dans une expression régulière) suivi d'un véritable point (le \ qui précéde le point indique qu'on veut changer la signification "régulière" du point et qu'on veut rechercher un véritable point). Pour plus de détails, suis le lien que j'avais indiqué. Il donne des exemples.

Ce n'est pas le point d'interrogation qui désigne un caractère quelconque dans une expression régulière ?

Bonne continuation Cocrane, je fais partie de ceux qui lisent régulièrement tes posts, mais c'est un peu trop technique pour moi...

Salut,

Fichiers texte
A réfléchir mais je pense que créer un standard dés maintenant serait une bonne chose pour le futur.

Sachant que pour l'instant, on en est pas encore à la gestion de langue utilisée dans l'éditeur.

Fichiers IDS
Arf je suis pris la main dans le sac de "trou de mémoire" et de grand WE. Le pire c'est que je me suis pris la tête en gros une heure à chercher une combinaison qui pourrait marcher. Elle était sous mon nez.

Une question: Comment fait ton pour se passer d'Isaya?

Fichiers IDS
C'est noté.

Je suis en train de terminer le chargement en base de ces 51 fichiers en automatique.
Que BG est dur avec ceux qui veulent en avoir la maîtrise!

Compatibilité
Ce que je veux dire. C'est si un moddeur est intéressé par un personne de TOB. Il veut le faire "jouer" dans BG1, il ne peut donc pas faire "juste" un copier coller.
Il y a des adaptations à prévoir.

Reste plus qu'a bosser l'éditeur!

Graoumf, j'ignore si tu moddes mais si tu as des fonctions qui te manquent dans les éditeurs actuels c'est le moment d'aborder le sujet.

Coco

Graoumf a écrit :Ce n'est pas le point d'interrogation qui désigne un caractère quelconque dans une expression régulière ?

Arg ! Un autre flagrant délit de lecture trop rapide !

On appelle expression régulière un motif qui décrit un ensemble de textes possibles. A ma connaissance, cela provient du monde Unix. Leur utilisation va bien au delà de la capacité à désigner un ensemble de fichiers. De nombreux éditeurs Unix ou des langages de manipulation de texte s'en servent également abondamment : sed, awk, perl, php.

Les formes ? et * sont d'origine MS-DOS (voire peut-être de l'ancêtre CPM). Ils ne servent à priori que pour la manipulation de fichiers. Ils sont complètement incompatibles (comprendre que chaque caractère joker a un sens différent) avec les expressions régulières. Les éditeurs type Notepad++ qui manipulent des expressions régulières utilisent tous la forme Unix.

Cocran a écrit :Ce que je veux dire. C'est si un moddeur est intéressé par un personne de TOB. Il veut le faire "jouer" dans BG1, il ne peut donc pas faire "juste" un copier coller.
Il y a des adaptations à prévoir.

Je ne connais pas d'éditeur qui se soit intéressé à la conversion d'un fichier d'un jeu à un autre. Même avec un format assez bien partagé comme le ITM V1, c'est un cauchemar à cause des effets qui n'existent pas dans tous les jeux ou dont le code peut différer d'un jeu à l'autre.
Bref, ce genre de capacité ne devrait pas constituer une priorité. Sachant que probablement 95 % des mods au moins sont pour BGII et ToB (c'est le moteur de jeu le plus riche et aussi le plus souple), autant viser le gros du marché !

Salut,

j'ai le problème suivant sur l'équipement du personnage (fichier CRE)

on a un fichier SLOTS.IDS qui a le contenu suivant:
"0 SLOT_AMULET
1 SLOT_ARMOR
2 SLOT_BELT
3 SLOT_BOOTS
4 SLOT_CLOAK
5 SLOT_GAUNTLETS
6 SLOT_HELMET
7 SLOT_RING_LEFT
8 SLOT_RING_RIGHT
9 SLOT_SHIELD
10 SLOT_FIST
11 SLOT_AMMO
15 SLOT_MISC
35 SLOT_WEAPON
11 SLOT_AMMO0
12 SLOT_AMMO1
13 SLOT_AMMO2
14 SLOT_AMMO3
15 SLOT_MISC0
16 SLOT_MISC1
17 SLOT_MISC2
18 SLOT_MISC3
19 SLOT_MISC4
20 SLOT_MISC5
21 SLOT_MISC6
22 SLOT_MISC7
23 SLOT_MISC8
24 SLOT_MISC9
25 SLOT_MISC10
26 SLOT_MISC11
27 SLOT_MISC12
28 SLOT_MISC13
29 SLOT_MISC14
30 SLOT_MISC15
31 SLOT_MISC16
32 SLOT_MISC17
33 SLOT_MISC18
34 SLOT_MISC19
35 SLOT_WEAPON0
36 SLOT_WEAPON1
37 SLOT_WEAPON2
38 SLOT_WEAPON3
"
On a donc la liste des positions des objets sur le corps. Le but est déterminer quel objet est à quel endroit. A noter, les positions sont pas dans l'ordre et certaines sont répétées...

Je prends le cas de DRIZZT qui a 8 objets en sa possession.
liste
0 S1-12 Crane???
1 DRIZZTS Crane???
2 BOOT01 Bottes de rapidité
3 SW1H15 Cimeterre de glace +3
4 SW1H16 Cimeterre gardien +5
5 CHAN06 Cottes de mailles +4 Mithril
6 BOOTDRIZ Bottes de rapidité
7 BGHELM15 Casque

Position du Corps
0: objet 7 soit une casque sur 'SLOT_AMULET' ???
1: objet 5 soit une armure sur 'SLOT_ARMOR'
3: objet 4 soit un Cimeterre sur 'SLOT_BOOTS' ???
etc...

En gros ça n'a pas l'air de coller.

NI a un ordre différent mais ça ne colle pas non plus. A priori c'est celui de IESP:
"
* Helmet
* Armor
* Shield
* Gloves
* L.Ring
* R.Ring
* Amulet
* Belt
* Boots
* Weapon 1
* Weapon 2
* Weapon 3
* Weapon 4
* Quiver 1
* Quiver 2
* Quiver 3
* ?
* Cloak
* Quick item 1
* Quick item 2
* Quick item 3
* Inventory item (1 to 16)
..."

L'AMULET en position 7 recupère un cimèterre...

Qui aurait un ordre fiable?
Pourquoi le fichier IDS présente des n° qui se répète.

C'est déjà difficile de coder mais en plus BG fait des trucs bizarres.

Coco

Dure est la vie du Moddeur, surtout quand la documentation insuffisante que nous avons nous induis en erreur.

Sur le banc des accusés, j'appele "iesdp".


La description du format EFF V2.0 est pour moi fausse sauf si mon niveau d'anglais est en cause:
je cite
"
EFF V2.0
Overall structure:
# Header
# Body

EFF V2.0 Header

Offset Size (data type) Description
0x0000 4 (char array) Signature ('EFF ')
0x0004 4 (char array) Version ('V2.0')

EFF V2.0 Body

When an effect is called via an eff, several of the fields (including duration and timing mode) are overriden by the calling SPL/ITM. Other fields are copied directly from the calling SPL/ITEM and overwrite the values defined in the EFF.

Offset Size (data type) Description
0x0008 4 (char array) External EFFs - the field is the same as the signature field from the header
Embedded EFFs - this field is zeroed out
0x000c 4 (char array) External EFFs - the field is the same as the version field from the header
Embedded EFFs - this field is zeroed out
0x0010 4 (dword) Opcode number
0x0014 4 (dword) Target type

* 0=None
* 1=Self (pre-projectile)
* 2=Pre-target
* 3=Party
* 4=Everyone (inc. party)
* 5=Everyone (excl. party)
* 6=Everyone matching specific value of caster (or Party if cast by party member)
* 7=Everyone matching specific value of target
* 8=Everyone (excl. caster)
* 9=Self (post-projectile)

0x0018 4 (dword) Power

ETC...
"

En lisant, cette document je comprends que l'on a une section Header de taille 8 (4+4) suivi d'une section Body d'une taille de 264.

Si je lis un fichier CRE ayant des Effets, j'obtiens des valeurs bizarres. C'était le cas pour Abazigal notamment. Après recherche, la section Header de 8 n'existe pas.
En l'enlevant, j'obtiens les mêmes valeurs lues que NI pour Abazigal.

Conclusion: soit mon niveau d'anglais est trop mauvais pour comprendre 'iesdp' soit il y a une erreur dans cette documentation à corriger!

Conclusion2: il ne me reste plus qu'à corriger mon code!

Coco

Le problème est plus vicieux que prévu. On s'en aperçoit lorsque l'on a plusieurs Effect pour une créature.

La correction de la structure du fichier EFF est la suivante (valeur des offets à corriger)

EFF V2.0 Body

When an effect is called via an eff, several of the fields (including duration and timing mode) are overriden by the calling SPL/ITM. Other fields are copied directly from the calling SPL/ITEM and overwrite the values defined in the EFF.

Offset Size (data type) Description
0x0008 Champ dont le rôle est inconnu (tj à blanc à priori)
Embedded EFFs - this field is zeroed out
0x0010 4 (dword) Opcode number
0x0014 4 (dword) Target type

* 0=None
* 1=Self (pre-projectile)
* 2=Pre-target
* 3=Party
* 4=Everyone (inc. party)
* 5=Everyone (excl. party)
* 6=Everyone matching specific value of caster (or Party if cast by party member)
* 7=Everyone matching specific value of target
* 8=Everyone (excl. caster)
* 9=Self (post-projectile)

Etc...

"

En résumé:
- la section Header n'existe pas
- il y a un champ en trop dans la structure du body sur les 2 premiers champs. On a un seul char array de 4.

Avec cette correction: je colle parfaitement au résultat NI et les données sur l'équipement de la créature ne sont pas décalées.

Qui peut proposer la correction à IESP

Coco

Mon post ne sera d'aucune aide... Je me permets juste de t'encourager dans ta démarche, et te féliciter pour ton opiniâtreté

Je pense que tu es le mieux placé pour proposer la correction d'IESDP, Cocrane. Si tu veux, tu peux attendre l'avis d'Isaya avant (il devrait revenir ce soir ou demain), mais comme c'est toi qui as trouvé le pb, c'est plus juste que ce soit toi qui le signale. D'autre part, ça touche à un niveau de programmation qui n'est pas maitrisé par le commun des joueurs/moddeurs.
La personne à contacter est igi, le mainteneur de l'outil. Sinon, il y a le forum sur G3.

Edit : je t'invite toutefois à le contacter par mp/mail car il passe de façon très irrégulière sur le forum G3 - ses absences peuvent durer plusieurs mois.

C'est noté pour le destinataire.

La correction n'est pas urgente sauf si il y a un autre moddeur qui bosse un éditeur sur le sujet ou un éditeur actuel qui n'a pas vu l'erreur.

Coco

Fichier CRE et l'équipement

J'en ai déjà parlé dans ce message.
A mon avis, tu n'as pas compris à quoi correspondaient les valeurs qui précédent le nom du fichier ITM. En réalité, ce nombre est simplement un index, qui s'incrémente avec chaque objet de la liste. C'est juste un élément de lisibilité proposé par Near Infinity afin que le mécanisme de lien, qui indique pour chaque slot s'il y a un objet associé et lequel, soit plus lisible.
En effet, il y a une table de 40 éléments qui correspond aux 37 slots plus 3 cas particuliers. Chaque élément est un entier de 2 octets (16 bits), qui indique le numéro d'index de l'objet qui se trouve dans le slot correspondant ou qui prend la valeur -1 pour indiquer que l'emplacement est inoccupé.
Il faut considérer ce -1 dans le codage d'un entier signé. Si tu lis la valeur comme un nombre non signé, elle prendra alors la valeur 65535.
Bref, la table des 40 slots (Item Slots) permet de pointer dans la table des noms d'objets (Items Table), qui la précède dans le fichier CRE.
Le fichier IDS n'est pas exploité dans le fichier CRE, sinon pour donner en principe l'ordre des slots dans la table Item Slots. Le fichier IDS sert surtout vis à vis des scripts permettant par exemple d'affecter un objet à une créature en la plaçant à l'emplacement souhaité. Cela permet d'écrire un truc du genre GiveItem("DRIZZT","CEINT",SLOT_BELT). Remarque : le nom de la fonction et la suite est bidon, c'est juste un exemple car je n'ai pas le temps de chercher la vraie commande et syntaxe.

Drizzt a donc, dans l'emplacement "Boots" l'objet numéro 6, qui correspond à BOOTDRIZ.ITM, "Bottes de rapidité".
Les "cranes" sont des noms souvent affectés par défaut à des objets de type "patte de naturelle monstre", "anneau de protection donnant les immunités adaptées à une liche", ... Ce sont des objets qui ne tombent pas au sol à la mort d'un personnage. Ils ne font pas l'objet d'un nom ou d'une description car ce sont juste des éléments cachés du jeu pour apporter les avantages propres à un type de créature, par exemple.



Le format EFF V2.0 et son utilisation dans les fichiers CRE

La description de IESDP n'est pas fausse en elle-même, mais elle manque d'une précision importante en ce qui concerne la façon dont les structures EFF se retrouvent dans un fichier CRE (ou autre). Les descriptions concernent les différents formats de fichiers. Hors pour un fichier EFF, il y a bien une redondance entre la partie header et les deux premiers mots de Body. Dans le cas d'un effet inclus dans un fichier CRE, l'en-tête semble effectivement être absent : on peut penser qu'il ne sert à rien, puisqu'on est dans un fichier CRE, la signature et la version du fichier CRE englobant tout son contenu.
L'amélioration à apporter à IESDP serait donc de faire préciser explicitement que le header n'est présent que dans le cas où il s'agit d'un fichier EFF indépendant et non d'une structure d'effet incluse dans un autre format de fichier. Ceci pourrait également être précisé dans la description du format CRE.

Pour le reste, je ne partage ton analyse du dernier message : seul le header disparait. Les deux premiers champs de Body sont neutralisés, Near Infinity ne les affiche pas dans le cas d'une structure intégré à un fichier CRE. Mais on voit bien qu'ils sont présents si on demande à Near Infinity d'afficher les offsets de chaque champ par rapport au début du fichier (menu Options, Show Hex Offsets). Chaque effet du fichier ABAZIGAL.CRE fait bien 264 octets, ou 108 en hexadécimal. D'ailleurs, c'est bien la conclusion à laquelle tu étais arrivé la première fois : l'organisation en 264 octets se répète bien.


Je ne vais pas être vraiment disponible dans les deux semaines à venir. En particulier, je n'aurai pas accès à un jeu installé ou à des outils (je n'ai pas ça sur mon PC du boulot ). Mais je tâcherai de suivre la discussion si tu as d'autres points à aborder. Bonne continuation.

Salut Isaya,

Fichier CRE et l'équipement
je ne suis pas sur qu'on se comprenne bien.

Je parviens à lister les objets et la valeur numérique annoncée pour la position. C'est le libellé annoncé pour la position qui ne colle pas pour moi.
Quand je regarde NI c'est pareil.

Pour Drizzt, NI annonce que l'emplacement "AMULET" contient l'item "SW1H15" qui correspond à un cimeterre...

J'ai donc des doutes sur l'ordre des libellés de BG et de la correction IESP utilisé à priori dans NI. Armand m'a fait un CRE avec toutes les cases des emplacements remplies par un objet. Je devrais avoir pouvoir trouver le bon libellé pour chaque position.

Le format EFF V2.0 et son utilisation dans les fichiers CRE

Citation
"Pour le reste, je ne partage ton analyse du dernier message : seul le header disparait. "
Oui c'est exact, je m'en suis aperçu plus tard en cours de journée. J'avais 4 offset en trop. J'ai conclu trop vite. Une erreur dans ma reprise de la structure IESP.
L'erreur a été trouvée et corrigée ce soir.

Je suis d'accord sur ta remarque sur la précision à signaler sur une structure présente dans un CRE. Je suis tombé dans le piège et j'ai encore perdu des cheveux à comprendre!


Ce We je tente les fichiers BAM.

Il faudra qu'on discute de la DLL à utiliser en direct. Windev accepte les DLL à ma connaissance. Mais j'ai pas encore testé. Je suppose qu'il y a des fonctions ou commandes à utiliser contenues dans la DLL.

Coco

Fichier CRE et l'équipement

Effectivement, j'avais lu un peu vite et sauté hâtivement à la conclusion que tu interprétais mal les structures sans vérifier.
De même que j'avais imaginé un peu vite (tout comme toi, semble-t-il) que le fichier IDS était exploité pour l'ordre dans la table. Hors la description du format CRE est sans ambiguité

IESDP a écrit :There are 38 slots, and they are not the same as the order specified in SLOTS.IDS. The actual order is:

Bref, il ne faut surtout chercher à exploiter le fichier IDS pour les positions dans le fichier CRE. L'ordre à utiliser est défini dans la description du format CRE dans IESDP.
Morale : la précipitation est mauvaise conseillère et je tâcherai de réfléchir un peu plus avant de te répondre la prochaine fois. ]La DLL[/color]

A vrai dire, je n'ai jamais utilisé la DLL Zlib mais j'ai employée la bibliothèque en statique en C. L'usage est très simple, même si je n'en garde aucun souvenir précis. Il me semble que la documentation fournie était particulièrement claire sur la façon d'utiliser la fonction permettant de décompacter un buffer, qui est celle à exploiter pour lire les fichiers BIFC.
Si les fichiers BAM utilisent la même méthode de compression, ce sera pareil. A moins que tu ne veuilles aussi écrire ce genre de fichier, tu n'auras pas à te préoccuper de la fonction inverse.

Fichier CRE et l'équipement

L'ordre proposé dans IESP marche mais dans le cas de DRIZZT le résultat est pour moi pas cohérant. Le problème est p.e lié au fichier et à contenu.

DLL Zlib
J'ai jeté un oeil sur le net: j'ai trouvé ce lien: zlib 1.2.5 Manual
Visiblement son utilisation est axée sur du C ou C++ et la documentation est en anglais. :-(.
Quel version il faut prendre?

Ysaya, peux tu lister les actions qui pourront être faites si on utilise cette DLL?
"- décompression pour accéder à ?"

Dans la documentation Windev, j'ai ce mot clé:
<Résultat> = API(<Nom de la DLL>, <Nom de la fonction> [, <Paramètre 1> [, <Paramètre 2> [,...]]])
"
Exécute une fonction présente dans une DLL externe 32 bits. Cette fonction peut être une fonction de l'API Windows. Les fonctions accessibles par API sont par exemple les fonctions des librairies standard 32 bits de Windows (USER32, KERNEL32, GDI32, etc.). La fonction peut être identifiée par son nom ou par son numéro.
"

Détails des paramètres
<Résultat> : Entier

Résultat de l'exécution de la fonction <Nom de la fonction>. Ce résultat peut être un code d'erreur. Ce résultat dépend de la fonction exécutée. Consultez la documentation de cette fonction pour obtenir plus de détails.
Si le résultat de la fonction ne correspond pas à un entier, il ne pourra pas être récupéré.

<Nom de la DLL> : Chaîne de caractères

Nom de la librairie (DLL) qui contient la fonction à exécuter.

<Nom de la fonction> : Chaîne de caractères

Nom de la fonction à exécuter. Cette fonction doit être présente dans la DLL spécifiée.

<Paramètre 1> : Type correspondant au paramètre

Premier paramètre à passer à la fonction. Ces paramètres doivent être du même type que les paramètres attendus par la fonction. Sont utilisables :
- les types "simples" (voir Notes),
- un nom de procédure WLangage. Cette procédure sera rappelée par la fonction de la DLL (voir Notes).

<Paramètre 2> : Type correspondant au paramètre

Second paramètre à passer à la fonction. Ces paramètres doivent être du même type que les paramètres attendus par la fonction. Sont utilisables :
- les types "simples" (voir Notes),
- un nom de procédure WLangage. Cette procédure sera rappelée par la fonction de la DLL (voir Notes).
"

Ca me semble jouable si j'identifie les fonctions Zlib à utiliser selon l'action à réaliser.


Le fichier BAM

Je suppose que je suis obligé de charger les données et de les "traduire" pour afficher l'image du sort etc... ainsi que les données liées à l'image?
En gros, la même démarche que pour les autres fichiers.


Coco

Fichier DRIZZT

Le jeu s'accommode assez bien d'un peu n'importe quoi parfois. Le fichier DRIZZT et les C6DRIZZx présentent tous ces mêmes bizarreries (cimeterre en casque, ...). Il doit être affaibli par l'impossibilité d'utiliser ses armes, ce qui doit certainement aider à le vaincre si on décide de l'attaquer. Etrange, tout de même. Avec un tel ramassis de bêtises, ces fichiers sont grandement visés par le BG2Fixpack, avec les commentaires

// creatures with items not assigned

// items to be deleted

Zlib

La seule fonction digne d'intérêt pour décompresser est (surprise) : uncompress. Comme indiqué dans la doc (je sais, en anglais, mais c'est technique, donc plus compréhensible pour un programmeur ), la plupart des gens se contentent des "Utility Functions". Les autres n'existaient dans la version 1.x que j'avais utilisée.
Il faut impérativement être en mesure d'utiliser des pointeurs ! Ou des zones de mémoire allouées avec la bonne taille. La taille destLen du buffer une fois décompressé est connue : elle est toujours indiquée dans l'en-tête de structure version compressée. Il faut au moins que le buffer dest soit de cette taille (en octets, sans doute).
En sortie dest est renseigné, ainsi que destLen (en principe ce dernier devrait toujours valeur ce que tu avais indiquée, à moins qu'il n'y ait eu une erreur). Le code de retour indiquera si tout s'est bien passé.
A première vue, en dehors de la question des pointeurs dest et source et de la façon de passer une variable entière qui va être modifiée (destLen), ça devrait bien coller avec ce que tu as copié de ta documentation. Pour les pointeurs et la variable à modifier destLen, je ne sais pas t'indiquer comment procéder car c'est vraiment propre à WinDev.

Tu pourras trouver vers la fin de cette page des exemples d'utilisation de Zlib pour les fichiers compressés dans l'Infinity Engine (BIF, BAM, MOS, SAV).


Fichier BAM

Oui, il faudrait traduire le contenu sous forme d'image manipulable par WinDev. Le plus simple est probablement le BMP. Je n'ai aujourd'hui aucune connaissance sur ce sujet, ne m'y étant jamais intéressé.

J'ai pas eu le temps de travailler des masses mais j'ai quelques questions:

* Il y a deux versions de BAM:
- BAM
- BAMC
Quel est l'utilisation de chacun?

* Le fichier BAM est compressé par défaut? Il faut que j'utilise Zlib avant de traduire le fichier?

Pour lire les exemples, l'outil microsoft C# se propose mais mon install date et il me demande maintenant une clé d'identification... Existe t'il un outil "correct' pour lire l'exemple qui ne soit pas chiant à l'install?

La description du fichier BAM n'est pas trés claire pour moi sur la fin... J'espère en sortir vivant. Je ne suis pas sur non plus que Windev sache créer un fichier.bam.
Je sens qu'il va y avoir du sport.

Coco

Les formats BAM et BAMC

Le format BAMC a dû apparaître avec BG II, pour gagner de la place sur les CD. Mais beaucoup de fichiers dans Baldur's Gate sont encore au format BAM non compressé. J'ignore s'il y a clairement une séparation dans l'usage des deux. Les fichiers BAM servent un peu à tout ce qui est graphique : icône de sort, d'objet, boutons de l'interface, animations (d'où la notion de cycle et de frame), icônes de la carte du monde, ...

Un fichier BAMC contient simplement un en-tête suivi d'une version compressé du fichier BAM. On les distingue simplement par la signature. Si c'est un BAMC, on le décompresse avec Zlib. Ensuite on a un fichier BAM normal. C'est ce que fait l'exemple : créer un fichier BAM à partir du BAMC.

Après la manipulation du fichier BAM reste entièrement à faire (pas d'exemple).


Les exemples

Pour lire les fichiers d'exemple en langage C, un éditeur tel que Notepad++ suffit amplement. Il dispose de modèles de surlignage pour le langage C. Il fera aussi un bon remplaçant pour le bloc-notes. Cela dit, le bloc-notes devrait aussi faire l'affaire pour un fichier C.

Si tu veux pouvoir compiler le programme pour l'essayer, il te faudra un environnement de développement. Les versions Express de Visual Studio sont gratuites. Tu peux les trouver sur ce site. Elles présentent des restrictions mais pas pour ce genre de programme très simple, en principe.
Pour comprendre comment les programmes exploitent le contenu du fichier BAM (l'exemple ne concerne que la décompression d'un BAMC en BAM), il faudrait étudier le code source de programmes tels que Shadow Keeper ou DLTCEP (liens dans les forums de Baldur's Gate II pour le premier, dans l'épinglé des outils ici même pour le second). Ils sont écrits en C++. La version Express devrait accepter de charger le projet complet par import d'un fichier projet ancien. Par contre, il me semble qu'il faudrait récupérer une version 6 de Visual Studio pour pouvoir les compiler car les versions Express gratuites étaient connues pour ne pas inclure la bibliothèque MFC (ensemble graphique), en tout cas jusqu'à la version 2008. Il y a longtemps, on pouvait en récupérer une version allégée mais suffisante de Visual Studio 6 avec un livre de formation. J'ignore si c'est encore trouvable quelque part.
Tu peux trouver d'autres fichiers sources pour voir comment sont gérées les données : le code source de Near Infinity (en Java) ou celui d'Infinity Explorer (en Delphi). Pour le premier, les outils Eclipse ou NetBeans sauront visualiser et compiler le projet. Pour le second, tu peux trouver des versions gratuites, équivalentes aux versions Express de Visual Studio. En particulier sur ce site.

J'ai téléchargé l'exemple permettant de décompresser un fichier BAM de type BAMC. Je ne suis pas expert en C mais le code à l'air bon et vu qu'il est sur ce site, je me dis que c'est le cas.

Un bon informaticien est un par définition un faignant:
- pourquoi réécrire un code qui marche et qui convient parfaitement à mon besoin???

Windev acceptant les DLL externes, je me dis:
"si on peut faire une DLL avec ce fichier .C, je devrais juste appeler la fonction "void unBamc( const char *filename )"."
Cependant la fonction ne renvoie rien... Elle écrit les données décompressées dans un buffer. Je suppose qu'il faudrait que je l'adapte soit pour récupérer l'adresse du buffer ou pour écrire les données dans un fichier au lieu d'un buffer.

J'ai ouvert le fichier .c avec microsoft visual c#. Je n'ai pas vu de proposition pour en faire une DLL.

Un bon informaticien est avant tout pragmatique. S'embêter à créer une DLL dont la fonction ajoute juste trois lignes de codes (je schématise à peine) pour appeler une autre DLL, c'est peu efficace et certainement pas un gain de temps. Tu peux sans difficulté recoder en WinDev tout le code autour de l'appel à Zlib, vu que tu sais déjà manipuler des fichiers CRE. La principale différente est cette gestion de buffer que tu n'avais probablement pas pour les fichiers CRE, mais elle ne te serait de toute façon pas épargnée pour autant ailleurs, notamment pour manipuler le fichier BAM non compressé lui-même.

De toute façon, tu ne pourras rien tirer de Visual Studio Express version C#. Ce langage n'est pas compatible avec le C, donc il te faudra réinterpréter du code. Autant le faire en WinDev, que tu connais bien.
Avec C#, tu ne pourras sans doute jamais écrire de DLL non plus. Une DLL suppose a priori de coder en langage natif, c'est à dire de compiler en langage machine du processeur. Hors C# est comme Java un langage dont la compilation produit un code qui est exécuté par une machine virtuelle, celle du framework .Net.

Le code qui précède et suit l'appel à Zlib est vraiment simple, une fois que tu décodes ce qu'il fait. Pour ça, c'est vrai qu'il faut connaître les bibliothèques C pour comprendre. Voici donc un décryptage :

• ouvrir les fichiers (le compressé et celui qui contiendra la version décompressée)
• lire la signature (les 8 octets habituels)
• lire la taille du buffer une fois décompressé (offset 8)
• appeler la fonction d'extraction :
  • déterminer la taille restante du fichier au-delà de l'en-tête (les deux appels à fseek et ftell) : tu peux le coder de façon plus simple, sans doute, car ça revient à calculer "taille du fichier - 12"
  • allouer les buffers : version compressé (dont on vient de calculer la taille) et version décompressée (taille fournie dans l'en-tête)
  • lire le reste du fichier compressé dans le premier buffer
  • appeler la décompression (Zlib)
  • écrire le buffer décompressé
  • libérer les buffers
• fermer les fichiers

Je pense que tu dois pouvoir faire tout ça en WinDev sans te casser trop la tête, sauf peut-être pour cette histoire de buffer. Mais si WinDev s'interface avec des DLL, il a forcément le moyen d'en gérer.

Comme tu ne peux pas savoir si un fichier BAM est compressé sans avoir lu la signature, tu n'as de toute façon pas le choix de ne pas ouvrir le fichier et de commencer à le lire avant de savoir s'il faut appeler unbamc(). Sinon, en cas de fichier non compressé, ton chargement va faire absolument n'importe quoi : considérer comme taille la valeur à l'offset 8, qui a une signification toute autre dans un fichier compressé. Donc, à mon avis, autant continuer la lecture en WinDev en suivant l'algorithme ci-dessus.

Salut Isaya,
Merci de ton retour.

j'ai proposé une DLL pour une 2nd raison.

Lorsque je regarde le code C de l'exemple, je vois "#include <zlib.h>". Pour moi c'est la bibliothèque permettant d'utiliser uncompress.

Le problème c'est que Windev attend une DLL pas un .h.

Je n'ai pas encore fait l'essai mais je pense que je vais avoir un message d'erreur sur ce point. D'où l'idée d'obtenir une DLL.

Coco

D'après que j'ai trouvé sur Internet à propos de l'utilisation de DLL avec WinDev (notamment ceci ou cela), on dirait que Windev se débrouille pour découvrir tout seul l'interface des fonctions de la DLL (les noms et les paramètres des fonctions). Par conséquent j'ai l'impression que tu aurais autant de facilité à exploiter directement la version DLL de Zlib qu'à exploiter ta DLL intermédiaire.

Pour le C ou le C++, le fichier zlib.h définit tous les noms de fonctions de la bibliothèque Zlib ainsi que leurs paramètres et leurs valeurs de retour. C'est la raison de son inclusion dans le code C. Comme Windev semble capable de se débrouiller sans définitions des fonctions d'une DLL, il est tout à fait possible qu'il n'y ait rien d'autre à faire pour remplacer zlib.h (et l'edition de liens du C avec zlib.lib) que d'exploiter les fonctions de chargement de la DLL dans Windev.

Essaie la version DLL de Zlib pour vérifier si tu arrives à l'appeler dans Windev.
Tu pourras comparer le résultat de ton extraction de fichier BAM avec celle que peut réaliser Near Infinity avec son bouton Export.

Original:
Bon c pas top...

j'ai installé microsoft visual C++ pour faire une DLL à partir de Zlib.h.

Pas de tuto clair et en cherchant sur l'outil, j'ai rien fait de propre.

Existe t'il une bonne âme dans le coin?

Merci
Coco

V2:
Rhhaaa tu pourrais prévenir Ysaya quand tu réponds .

Je lis ton msg et vois ce que je peux faire.

La bonne âme était déjà sur mes traces sacrebleu!

Coco V2