CRE et ITM

[Cocrane]

Je travaille sur l'utilisation possible de l'objet sélectionné par le personnage.

Il y a 3 critères à retenir:
- race
- alignement
- classe

Le champ '0x001e 1x4 (char) Usability' du fichier ITM permet de lister les cas via les critères ci dessus pour l'objet est inutilisable.

Pour la lecture des valeurs c'est vu.Je dois donc comparer les valeurs obtenues sur l'objet par rapport à ceux du CRE.

Existe t'il un fichier IDS contenant l'équivalent des infos IEDSP ou il faut écrire en dur cette correspondance.

Extrait IEDSP / ITM
Header Usability

Bit Byte 1 Byte 2 Byte 3 Byte 4
0 Chaotic... Cleric/Mage Fighter/Mage/Thief Dwarf
1 ...Evil Cleric/Thief Fighter/Thief Half-Elf
2 ...Good Cleric/Ranger Mage Halfling
3 ...Neutral Fighter Mage/Thief Human
4 Lawful... Fighter/Druid Paladin Gnome
5 Neutral... Fighter/Mage Ranger Monk
6 Bard Fighter/Cleric Thief Druid
7 Cleric Fighter/Mage/Cleric Elf Half-Orc

Coco

[Isaya]

C'est en dur, pour autant que je sache. Et dans le cas contraire, cela ne changerait rien puisque le contenu correspondrait forcément à ce qui est décrit là et ne serait pas modifiable.
De toute façon, il te faudra faire des conversions entre la valeur de classe ou race et le numéro du bit à vérifier. Et ce sera forcément en dur, à moins que tu ne construises une table dans un fichier de données propre (rempli en dur et fourni avec l'éditeur).

Ta liste des contraintes est tout à fait incomplète. Il faut également tenir compte de :
0x0024 1 (char) Min Level
0x0026 1 (char) Min Strength (unused in BG1)
0x0028 1 (char) Min Strength Bonus (unused in BG1)
0x0029 1 (char) Kit Usability 1
0x002a 1 (char) Min Intelligence (unused in BG1)
0x002b 1 (char) Kit Usability 2
0x002c 1 (char) Min Dexterity (unused in BG1)
0x002d 1 (char) Kit Usability 3
0x002e 1 (char) Min Wisdom (unused in BG1)
0x002f 1 (char) Kit Usability 4
0x0030 1 (char) Min Constitution (unused in BG1)
0x0032 1 (char) Min Charisma

Les parties Kit sont comparables au cas des classes pour les spécialités de mages et les kits. C'est en rapport avec la colonne UNUSABLE qui est défini pour chaque kit dans le fichier KITLIST.2DA.

Je profite de l'occasion de te féliciter pour le travail accompli que l'on peut constater via les captures d'écran que tu as postées. Ton silence signifiait simplement que tu travaillais comme un fou !

[Cocrane]

Bon bah, ca va être en dur alors!

J'avais vu que j'avais zappé les kits mais les minimas de carac, là j'avoue ça m'est passé au dessus de la tête.

Oui ça fait un bail que j'avais pas posé une question technique ou une version. Vu que je n'étais pas bloqué, j'étais la tête dans le guidon!
En décembre, je n'étais pas sur de pouvoir simuler la gestion de l'équipement du jeu. Le rendu me plait!

A la fin du mois,vous aurez une version à tester pour rouspéter sur les défauts!

Coco

[Cocrane]

Il me reste le filtre sur les KITS.

Dans la structure du fichier ITM, on peut voir les imcompatibilités avec les Kits existants:
Bit Byte 1 Byte 2 Byte 3 Byte 4
0 Cleric of Talos Stalker Ranger Diviner Beserker Fighter
1 Cleric of Helm Beastmaster Ranger Enchanter Wizardslayer Fighter
2 Cleric of Lathlander Assassin Thief Illusionist Kensai Fighter
3 Totemic Druid Bounty Hunter Thief Invoker Cavalier Paladin
4 Shapeshifter Druid Swashbuckler Thief Necromancer Inquisiter Paladin
5 Avenger Druid Blade Bard Transmuter Undead Hunter Paladin
6 Barbarian Jester Bard All (no kit) Abjurer
7 Wildmage Skald Bard Ferlain Conjurer

Les Kits issues d'un mod ne sont pas pris en compte. Je suppose donc que c'est une piste imcomplète.

Dans KITLIST.2DA, on peut avoir la liste de tous les kits si le moddeur ajoute son Kit.

La colonne UNUSABLE est visiblement à utiliser.

J'ai jeté un oeil puis les deux au tuto de Lothringen
"
- UNUSABLE est une valeur hexadécimale qui fait correspondre le kit aux indicateurs d'inutilisabilité dans les fichiers d'objets. Les objets ont une série d'indicateurs qui déterminent quelles classes et quels kits peuvent les utiliser. Une des valeurs non-listée est 0x00004000, qui donnera au kit les mêmes restrictions que sa classe-mère (c'est à dire qu'un kit de guerrier pourra utiliser les mêmes objets qu'un guerrier pur).

Il faut également noter qu'il est possible d'ajouter ces valeurs (en utilisant une calculatrice hexadécimale si vous n'êtes pas familier avec ces nombres) pour combiner les restrictions. Si vous voulez un kit qui a les restrictions d'objets d'un Cavalier et d'un Métamorphe (Dieu sait pourquoi), il vous faudra ajouter leurs valeurs inutilisables respectives: 0x00000008 + 0x10000000 = 0x10000008.
"

On a donc une valeur Hexa qui liste les restrictions. Comment traduire cette valeur en une liste exploitable?

Par exemple:
- les armes de trait sont autorisés au niveau de la classe mais pas au niveau du kit?
- l'utilisation de parchemin est non autorisé au niveau de la classe mais pas au niveau du kit?

Coco

[Cocrane]

De même au niveau de la gestion des quantités.

La structure du CRE est la suivante:
"
//Items Table (This section details which items the character has. It consists of an array of entries formatted as follows:
0x0000 8 (resref) Resource name of the ITM file
0x0008 1 (byte) Item expiration time_creation_hour(replace with drained item)
0x0009 1 (byte) Item expiration time_elapsed_hour(count divided by 256, rounded down) + 1 (replace with drained item)
* When the game hour and elapsed hour count for the current
game time exceed these values, the item is removed.
0x000a 2 (word) Quantity/Charges 1
0x000c 2 (word) Quantity/Charges 2
0x000e 2 (word) Quantity/Charges 3
0x0010 4 (dword) Flags
* bit 0: Identified
* bit 1: Unstealable
* bit 2: Stolen
* bit 3: Undroppable
"

Pourquoi avons 3 types de quantité? (max et la quantité actuelle et ? )

Coco

[Isaya]

Les Kits issues d'un mod ne sont pas pris en compte. Je suppose donc que c'est une piste imcomplète.

Dans KITLIST.2DA, on peut avoir la liste de tous les kits si le moddeur ajoute son Kit.

La colonne UNUSABLE est visiblement à utiliser.

Il n'y a pas besoin de prendre en compte les kits ajoutés par les mods. Pour la bonne et simple raison que le seul choix qu'a un créateur de kit, c'est d'utiliser la même série d'interdits qu'un kit "officiel" ou de combiner les interdits de plusieurs.

On a donc une valeur Hexa qui liste les restrictions. Comment traduire cette valeur en une liste exploitable?

L'exemple que tu as cité est parlant :

"Il faut également noter qu'il est possible d'ajouter ces valeurs (en utilisant une calculatrice hexadécimale si vous n'êtes pas familier avec ces nombres) pour combiner les restrictions. Si vous voulez un kit qui a les restrictions d'objets d'un Cavalier et d'un Métamorphe (Dieu sait pourquoi), il vous faudra ajouter leurs valeurs inutilisables respectives: 0x00000008 + 0x10000000 = 0x10000008.
"

Si un kit combine (0x10000008) les interdits d'un Cavalier (0x00000008) et d'un Métamorphe (0x10000000), alors il faut que tu lui refuses les objets interdits au "Cavalier Paladin" (Byte 4, bit 3) et du "Shapeshifter Druid" (Byte 1, bit 4).
D'un point de vue binaire, c'est trivial : 0x10 correspond au bit 4 d'un octet, 0x08 correspond au bit 3 d'un octet (on part toujours de 0). Donc les deux premiers chiffres du UNUSABLE (poids fort, juste après le 0x) correspondent au Byte 1 de la structure ITM, les deux derniers (poids faible) correspondent au Byte 4 de la structure ITM et ainsi de suite pour les deux octets intermédiaires.
On vérifie facilement que ceci est vrai pour toutes les valeurs de UNUSABLE du fichier KITLIST.2DA.

Pour exploiter ces valeurs, puisque tu fais un gestionnaire d'inventaire et que tu connais donc parfaitement la classe ou le kit du personnage, il faudrait que tu constitues les 4 valeurs correspondant aux masques binaires à appliquer aux valeurs Byte 1 à 4 des objets pour vérifier si le personnage peut s'en servir.
Si le personnage n'est pas barbare, mage entropique ou mage spécialisé, il n'y a rien à contrôler dans ces 4 octets, le contrôle s'effectue uniquement sur les 4 octets relatifs aux interdits de classe. Mais si le personnage est d'une de ces classes ou s'il a un kit, tu découpes la valeur du UNUSABLE associé au kit pour constituer les masques binaires qui permettent de trouver rapidement si un objet est interdit.

Dans l'exemple ci-dessus, le masque pour Byte 1 serait 0x10 et le masque pour Byte 4 serait 0x08. Il suffit de faire les opérations :
(Byte 1 de l'item) ET_BINAIRE (0x10)
(Byte 2 de l'item) ET_BINAIRE (0x00)
(Byte 3 de l'item) ET_BINAIRE (0x00)
(Byte 4 de l'item) ET_BINAIRE (0x08)
et de vérifier que le résultat vaut 0 pour les 4 calculs pour s'assurer que l'objet n'est interdit dans aucun des cas qui concernent le kit du personnage (ici Cavalier + Métamorphe).

- les armes de trait sont autorisés au niveau de la classe mais pas au niveau du kit?

Ceci entre dans le cadre évoqué.

- l'utilisation de parchemin est non autorisé au niveau de la classe mais pas au niveau du kit?

Cas impossible à ma connaissance. Aucun kit ne peut s'affranchir d'un interdit de sa classe mère.

De même au niveau de la gestion des quantités.

Pourquoi avons 3 types de quantité? (max et la quantité actuelle et ? )

Les charges en quantité multiple servent uniquement pour les objets magiques multi-fonctions, afin de gérer les charges respectives des différentes fonctions. Dans le jeu, cela se présente sous la forme de plusieurs icônes accessibles à partir de l'étoile quand l'objet est en main ou dans une case d'objet rapide, et chaque icône de fonction indique alors son niveau de charge restant.

Pour des objets simples comme des flèches, par exemple, seule la première valeur est exploitée et indique le stock actuel.

[Cocrane]

OK pour l'explication détaillée. Je vois comment faire la comparaison.

Cependant j'ai la question suivante:
- la valeur Kit du CRE est liée à la valeur du fichier Kit.ids.
- les restrictions sont dans Kitlist.2DA

Je peux faire une correspondance de nom entre les deux fichiers.
Sommes nous sur que les nouveaux kits sont aussi signalés dans Kit.ids?

Coco

[Isaya]

L'ajout de kit modifie à la fois KIT.IDS et KITLIST.2DA. Je ne suis pas certain à 100 % du lien entre les deux. Néanmoins c'est un sujet que nous avons déjà abordé à un moment quand nous n'avions qu'un seul sujet de discussion (j'ai pointé sur le premier message sur ce point).

L'hypothèse que je faisais alors, à savoir qu'il y a un lien direct entre le résultat du calcul (1ère colonne de KIT.IDS) - 0x4000 qui donne, une fois converti en décimal, le numéro de la première colonne de KITLIST.2DA, fonctionne aussi avec une installation de TDD.

[Cocrane]

Le lien m'a permis de me rafraichir la mémoire!

Dc on a:
CRE -> kit information -> indice de ligne dans le fichier Kit.ids
Kit.ids -> indice de ligne = valeur de la colonne unusable de Kitlist.2da

Conclusion, on a besoin soit de Kitlist.2da ou de Kit.ids pour tester les restrictions objets.

Coco

[Cocrane]

Quelques questions sur la gestion des quantités de l'équipement.

1-La 1ière quantité désigne la qté de l'objet. Comment connaître la valeur max?
Exemple:
pour une flèche le nombre est limité. Où est cette information?


2-Si dans mon équipement j'ai deux ITM billes, je vois dans le CRE 1 seul cas pour l'objet dans la section 'Items Table'.
Comment signaler dans ce cas mon 1ier objet bille contient 15 billes et le 2nd 20?

Le jeu y arrive pourtant!
Exemple: ANOMEN6.CRE

Visiblement NI signale aussi un seul objet bille.

Coco

[Isaya]

La quantité maximum est 65535. Tout simplement parce que c'est la capacité maximum d'un entier sur 2 octets.
Il n'y a pas de limite accessible dans le jeu. Le fait est qu'à chaque fois que tu as un lot de flèche dans un conteneur, que ce soit un coffre ou un magasin, c'est l'information présente dans la structure des charges (qui est similaire entre les créatures, les conteneurs et les magasins) qui déterminent le nombre. Comme un magasin vend toujours le même genre d'objets, c'est ce qui fait que tu achètes toujours des lots de 40, et comme tous les magasins sont faits de la même manière, c'est pareil partout.

L'information de charges ne fait pas partie de l'objet mais d'une structure supplémentaire, comme évoqué ci-dessus. Il y a en général une structure par emplacement de l'inventaire utilisé (CRE V1.0 Items Table). Donc deux structures d'emplacement de l'inventaire peuvent se référer au même objet ("Resource name of the ITM file" dans la structure) avec des charges différentes.
Dans le cas d'ANOMEN6, on retrouve deux emplacements, Quiver 1 et 2, qui pointent sur la même structure, à la position 0 dans la table, définie pour 20 charges. Dès qu'Anomen va tirer une bille, le jeu va devoir dupliquer la structure pour que l'une ne contienne plus que 19 billes.

Si tu veux deux charges différentes, il faut créer deux structures faisant référence au "resource name" des billes (BULL01), et leur affecter des charges à 20 et 15. Et ensuite indiquer dans Quiver 1 de pointer sur la première structure et dans Quiver 2 de pointeur sur la seconde.

Quand j'ouvre une sauvegarde avec NI, je constate que le jeu ne cherche pas à faire le même genre d'optimisation qu'avec Anomen : quand j'ai deux lots de billes à 40 charges dans deux emplacements différents, je retrouve bien deux structures à charge 40 dans la tableau d'objets. Bref la factorisation observée dans ANOMEN6 semble être un cas exceptionnel.

[Cocrane]

Evolution réalisée:

Lorsque l'on lit un CRE avec un objet signalé sur deux emplacements, l'objet est dupliqué et chaque objet peut évoluer comme un objet unique. Son unicité est liée à sa position dans l'inventaire.

Conclusion: chaque objet sera géré de manière unique même si il y a plusieurs fois le même objet dans l'inventaire.



Cette évolution m'a pris pas mal de temps compte tenu que j'avais mis en place une mauvaise règle en prenant exemple sur le CRE n'Anomen (on en peut plus faire confiance aux Clercs!). J'ai donc pris un peu de retard pour livrer ma nouvelle version. :-(

Coco

[Cocrane]

Je travaille sur la compatibilité de l'objet avec un kit éventuel.

J'ai un pb avec la valeur du kit que je charge via l'information contenue dans le CRE.

Exemple:
Edwin11.CRE

Conjurateur, la valeur "kit" est 128 en décimale.

Cependant le fichier CRE me donne la valeur '8388608'.

La structure dans le CRE est la suivante:
Offset: 580
4 (dword) Kit information
* NONE 0x00000000
* KIT_BARBARIAN 0x00004000
* KIT_TRUECLASS 0x40000000
* KIT_BERSERKER 0x40010000
*KIT_WIZARDSLAYER 0x40020000
* KIT_KENSAI 0x40030000
* KIT_CAVALIER 0x40040000
* KIT_INQUISITOR 0x40050000
* KIT_UNDEADHUNTER 0x40060000
* KIT_ARCHER 0x40070000
* KIT_STALKER 0x40080000
* KIT_BEASTMASTER 0x40090000
* KIT_ASSASSIN 0x400A0000
* KIT_BOUNTYHUNTER 0x400B0000
* KIT_SWASHBUCKLER 0x400C0000
* KIT_BLADE 0x400D0000
* KIT_JESTER 0x400E0000
* KIT_SKALD 0x400F0000
* KIT_TOTEMIC 0x40100000
* KIT_SHAPESHIFTER 0x40110000
* KIT_AVENGER 0x40120000
* KIT_GODTALOS 0x40130000
* KIT_GODHELM 0x40140000
* KIT_GODLATHANDER 0x40150000
* ABJURER 0x00400000
* CONJURER 0x00800000
* DIVINER 0x01000000
* ENCHANTER 0x02000000
* ILLUSIONIST 0x04000000
* INVOKER 0x08000000
* NECROMANCER 0x10000000


Je n'ai pas de décalage dans la lecture d'après ce que je vois.

Coco

[Cocrane]

La lecture de la valeur du Kit est assez prise de tête car pour obtenir la valeur prévue, la méthode de lecture (nb octects lus) n'est pas la même selon les fichiers:

580 0x0244 4 octets type 'dword' Kit information

EDWIN
Conjurateur, la valeur "kit" attendue est 128 en décimale.

Edwin11.CRE
Lecture
2 puis 2: 0,128
1, 1, 1 et 1: 0,0,128 et 0

> les deux méthodes marchent.

Yoshiro
Traqueur, la valeur "kit" attendue est 11 en décimale.

Yoshi10.CRE
Lecture
2 puis 2: 0,16395
1, 1, 1 et 1: 0,0,11 et 64

> la méthode 1 par 1 marche uniquement

Jansen
Illusioniste, la valeur "kit" attendue est 1024 en décimale.

JAN10.CRE
Lecture
2 puis 2: 0,1024
1, 1, 1 et 1: 0,0,0 et 4

> la méthode 2 par 2 marche uniquement.


YAGASHURA
Berseker, , la valeur "kit" attendue est 1 en décimale.

yaga05.cre
Lecture
2 puis 2: 0,16394
1, 1, 1 et 1: 0,0,10 et 64

> aucune des deux méthodes marchent.

Si quelqu'un a la réponse, je l'invite à me répondre.

Coco

[Isaya]

Tu commences par citer la description de la structure CRE, avec une valeur de 0x00800000 pour un conjurateur, puis tu évoques le fait que tu cherches la valeur 128. Idem pour le cas de Yoshimo, dont le KIT_BOUNTYHUNTER vaut 0x400B0000, puis tu dis chercher 11.
Il y a une grosse contradiction.
Je ne sais pas ce qui t'a donné ces valeurs que tu considères comme des références absolues. La référence absolue, c'est IESDP, point. Si tu as utilisé Near Infinity, quel fichier KIT.IDS as-tu utilisé ? Si c'est le nouveau, as-tu installé une installation avec BG2 Fixpack, qui patche aussi les fichiers CRE pour qu'ils correspondent bien au fichier KIT.IDS corrigé ?

Hors, justement, que vois-on dans les 4 octets que tu lis :

Conjurateur : 0,0,128,0, soit en hexadécimal 0x00 0x00 0x80 0x00
Chasseur de prime : 0,0,11,64, soit en hexadécimal 0x00 0x00 0x0B 0x40
Illusionniste : 0,0,0,4, soit en hexadécimal 0x00 0x00 0x00 0x04
Assassin (Yaga05 a un kit d'assassin, c'est Yaga01 le berserker): 0,0,10,64, soit en hexadécimal 0x00 0x00 0x0A 0x40

La description du champ "Kit information", en 0x244, indique

NB.: The values of this offset are written in big endian style.

Ah, le "big endian", qui, avec son compère "little endian" a fait perdre tant de cheveux aux programmeurs. Pour plus de précisions, consulte l'article de Wikipédia qui donne aussi des exemples.

Concrètement, qu'est-ce que ça signifie ? Sur un PC (voir la partie Dans les ordinateurs / Little Endian de l'article), le premier octet qu'on lit en mémoire est l'octet de poids faible, et ainsi de suite jusqu'à l'octet de poids fort.
Hors, dans la représentation hexadécimale d'un nombre, on place toujours à gauche l'octet de poids fort et à droite l'octet de poids faible.
A noter que la remarque d'IESDP sur le Big Endian est à mon sens complètement erronée, même si elle m'a servi d'introduction. En effet quand on considère le champ Kit information en little endian, comme les autres champs, on arrive bien au résultat qui suit.

Ce qui nous donne :

Conjurateur : 0x00 0x00 0x80 0x00 -> 0x00800000
Chasseur de prime : 0x00 0x00 0x0B 0x40 -> 0x400B0000
Illusionniste : 0x00 0x00 0x00 0x04 -> 0x04000000
Assassin : 0x00 0x00 0x0A 0x40 -> 0x400A0000

Et que constates-tu ? Voilà justement les valeurs qu'indique IESDP.

D'ailleurs, dans ton premier des deux messages, tu disais avoir lu 8388608 pour conjurateur. C'était justement 0x00800000, donc la valeur indiquée par IESDP. On dirait que tu es fâché avec l'hexadécimal.


Concernant les "vrais" kits, le code est toujours en 0x40NN0000. Avec le patch TobEx, une limite a sauté et on peut dépasser 255 kits, donc ce serait plutôt 0x4NNN0000.
Comme je l'ai déjà indiqué dans le long sujet de discussion, on peut apparemment (vérifié avec Chloé et TDD) passer du code du kit au numéro de ligne dans le fichier KITLIST.2DA (pour accéder notamment au "UNUSABLE" pour les objets) en faisant l'opération (code du kit - 0x4000), à condition de ne conserver comme code du kit que la partie 0x4NNN (faire un décalage de 16 bits à droite pour l'obtenir).

Exemple : pour Chasseur de prime, 0x400B - 0x4000 = 0x0B, c'est à dire le fameux 11 en décimal, qui le numéro de ligne du kit dans KITLIST.2DA. Et pour le kit de Chloé, quand j'avais fait le test avec une installation ou c'était le seul kit de mod, j'avais obtenu 0x4020 - 0x4000 = 0x20, soit 32 en décimal. Et cela correspond bien au premier numéro de ligne disponible après celles du jeu de base.

Avant de faire cette opération, il faut t'assurer que tu as bien à faire à un vrai kit. Et pour ça, il faut commencer par vérifier s'il ne s'agit pas d'un mage (donc champ Class = mage) spécialisé (les 8 spécialités listées, plus 0x00008000 pour le mage entropique, qui est bizarrement absent d'IESDP) ou d'un barbare (donc champ Class = guerrier) avec "kit informatiion" égal à 0x00004000, et enfin que ce n'est pas un "true class" (0x40000000) ou "not kit" (0x00000000), donc un guerrier/voleur/etc. sans kit ni un mage sans spécialité.

Bonne continuation.

[Cocrane]

Salut Isaya,

je pense que tu as mis le doigt sur une vérité. "Je suis bel et bien fâché" avec les conversions "dec-hex-bin". Quand je lis ton explication, je me dis que j'aurai pu chercher longtemps sans trouver.

J'arrive enfin à traduire fidèlement les kits. Du coup, l'éditeur va pouvoir gérer ce point.

Une brique de plus sur le "mur", un peu de mortier et on attend la brique suivante!


As tu eu l'occasion de tester l'éditeur? Tu sais bien que ton retour m'intéresse!

Coco