Accès rapide aux fichiers de BG

[Cocrane]

Le but est de ne pas demander à Weidu l'extraction des fichiers et de le réaliser par l'éditeur lui même afin d'être plus rapide au global.

1- Identification du fichier BIf contenant le fichier ciblé à extraire
Le fichier CHITIN.KEY contient la liste des fichiers .BIF du jeu et la liste des fichiers qu'ils contiennent. Il faut mémoriser:
- le nom du fichier Bif.
- sa localisation
- la liste des fichiers qu'il contient.

2- Extraction du fichier ciblé du fichier Bif identifié
A détailler

[Cocrane]

Informations signalées par Isaya:



Envoyé par Cocrane Voir le message
2-à un 'Resource name' correspond un 'Resource locator ' qui me donne la position à lire dans Bif entries.

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

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

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

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

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



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

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

[Cocrane]

J'ai commencé à décortiquer le contenu du fichier. Voici les données lues associées à la structure du fichier CHITIN.KEY pour une install BG2

//Header
-Count of BIF entries_____________182
-Count of resource entries_______41794
-Offset to BIF entries______________24
-Offset to resource entries________5449

Interprétation des données lues:
__182 fichiers Bif répertoriées dans le fichier key
41794 noms de fichiers sont contenus dans les 182 fichiers bifs
___24 position de la section entrée dans le fichier (info sur les fichiers bifs)
_5449 position de la section ressource dans le fichier
(info sur les fichiers contenus dans le fichier bif)


//Bif Entries
-Length of BIF file_____________5847739
-Offset from start of file___________2208
to ASCIIZ BIF filename
-Length, including terminating NUL,____17
of ASCIIZ BIF filename
-The 16 bits of this field are used______1
individually to mark the location
of the relevant file.
*(MSB) xxxx xxxx ABCD EFGH (LSB)
* Bits marked A to F determine on which CD the file is stored (A = CD6, F = CD1)
* Bit G determines if the file is in the \cache directory
* Bit H determines if the file is in the \data directory

Interprétation des données lues:
5847739 taille du fichier BIF
___2208 position dans le fichier KEY du nom du fichier BIF. J'obtiens pour une longueur de 17 caractères "data\Default.bif".

//Resource_Entries
Cas entrée 1
Resource name______________ABCLASRQ
Resource type___________________1012
Resource locator____________________0
(à chaque nouvelle entrée compteur+1 jusqu'à 443 et passage à 1048576)
Cas entrée 444
Resource name________________AROW01
Resource type___________________1005
Resource locator______________1048576
* The IE resource manager uses 32-bit values as a 'resource index',
* which codifies the source of the resource as well as which source it refers to. The layout of this value is below.
* bits 31-20: source index (the ordinal value giving the index of the corresponding BIF entry)
* bits 19-14: tileset index
* bits 13- 0: non-tileset file index (any 12 bit value, so long as it matches the value used in the BIF file)

ABCLASRQ Nom du fichier contenu dans le fichier Bif
_____1012 correspond à une extention de fichier? (CRE etc?)
________0 index qui sert à?

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

Ok, c'est un "non-tileset file index". Lorsque je suis dans cette zone du fichier Bif, je cherche le nom de mon ficher "ABCLASRQ"?


Si on part dans l'idée d'une liste des fichiers et du fichier Bif associé, je suppose que j'ai besoin de mémoriser les informations suivantes:
- nom du fichier Bif
- chemin du fichier Bif
- nom du fichier présent dans le fichie bif
- index du fichier dans le fichier bif

[Isaya]

La correspondance entre la valeur "resource type" et l'extension du fichier se trouve sur cette page d'IESDP.

L'index "non-tileset file index" permet de retrouver l'élément dans le fichier BIF. Le fichier BIF possède au début une table de correspondance qui permet de passer de l'index à la position dans le fichier et à la taille de l'élément dans le fichier BIF.

Le "resource locator" du fichier KEY est composé de deux parties : les bits de poids forts (source index) désigne par l'index un des fichiers BIF listés dans la table des noms et emplacements des fichiers BIF. Les autres bits désignent soient un index de fichier TIS (bits 19-14), soit un index de fichier autre (13-0).
Donc, quand tu obtiens quelque chose d'inférieur à 16384 (valeur du bit 14), cela veut dire que c'est dans le fichier BIF (source index = 0), que ce n'est pas un TIS et la valeur désigne bien alors un index de fichier d'un autre type de TIS.
Quand tu as la valeur 1048576, en hexadécimal 0x100000, le 1 correspond au bit 20, donc il s'agit du fichier BIF qui est à l'index 1, et la ressource indiquée est à l'index 0.
Il faut impérativement utiliser des masques binaires pour extraire les différents éléments du "resource locator".

Seul le fichier KEY a la connaissance des noms de fichier. La table au début du fichier BIF n'indique que le type, la position et la taille. Pour trouver la ressource, il faut parcourir la table qui va bien au début du fichier BIF : soit celle des tilesets, si tu cherches un fichier TIS désigné par les bits 19-14 du "resource locator", soit l'autre table pour tous les autres types de données. En principe, l'index obtenu du "resource locator" a de bonnes chances d'être directement l'index dans la table. Mais il faudra toujours vérifier que la valeur des bits 13-0 du "resource locator" dans le fichier BIF correspond bien à celle du fichier KEY.

Un fichier BIF est comme une archive dans laquelle la table des matières ne contiendrait pas le noms des fichiers. C'est le fichier KEY qui la contient. Et le fichier KEY est une table des matières multi-archives, puisqu'il référence pleins de fichiers BIF.

Dernier point que tu n'as pas évoqué mais qui a son importance : la partie "location of the file" de la table BIF Entries est très importante. C'est elle qui permet de trouver le fichier BIF. En effet, dans BG II, la quasi-totalité des fichiers contenant les graphismes des zones (donc des fichiers TIS, mais pas seulement) sont placés dans les répertoires "CDn\data" alors que le fichier KEY ne va jamais indiquer la partie "CDn\" du chemin. La raison est simple : certains fichiers particuliers sont présents sur plusieurs CD, pour réduire les demandes de changement de CD à ceux qui ne font pas d'installation complète. Le fichier KEY indique alors que le fichier se trouve sur plusieurs CD, donc il ne donne pas la partie "CDn\" du chemin puisque plusieurs peuvent convenir.
Pour trouver les fichiers à partir de l'indication des bits "location of the file", il faut lire le fichier Baldur.ini, partie Alias, qui indique où se trouve le "CDn". Pour les gens qui font des installations multiples, très utiles aux moddeurs, ces répertoires CDn ne sont jamais copiés dans les répertoires de copie et le fichier Baldur.ini pointe alors sur l'installation de base. Il n'est donc pas correct de supposer que ce qui est indiqué par le fichier KEY comme étant sur le CD 2 se trouve forcément dans le sous-répertoire CD2 de l'installation du jeu désigné lors de la configuration de l'éditeur.
Tous les outils (WeiDU, Near Infinity, ...) gèrent très bien cette situation en exploitant le fichier Baldur.ini.

[Cocrane]

Tu as l'air de maitriser le sujet mais il n'est pas encore clair pour moi.

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

Tu dis '1048576' = '100000000000000000000' en binaire
=> Ok

Le 1 est en 20ième position donc on est dans le cas 'bits 31-20: source index (the ordinal value giving the index of the corresponding BIF entry)'.
=> Ok, on a un index pour un fichier Biff. La valeur correspond à l'un des index de la section 'Bif Entries'. C'est donc le 1ier fichier Biff.

"

//1ier index de biff entries
"
-Length of BIF file_____________5847739
-Offset from start of file___________2208
to ASCIIZ BIF filename
-Length, including terminating NUL,____17
of ASCIIZ BIF filename
-The 16 bits of this field are used______1
individually to mark the location
of the relevant file.
*(MSB) xxxx xxxx ABCD EFGH (LSB)
* Bits marked A to F determine on which CD the file is stored (A = CD6, F = CD1)
* Bit G determines if the file is in the \cache directory
* Bit H determines if the file is in the \data directory
"
"
="data\Default.bif"

Le fichier "AROW01" d'extension type '1005' est donc contenu sous "data\Default.bif".

Je prends un autre cas pr bien comprendre:
Section Resource entries / Resource locator = 1048949
nom du fichier "MISC1H" d'extension type '1005'

En décimal on a donc: "1048949"
En binaire ca correspond a: "100000000000101110101" soit 21 bits => c'est un index pour identifier le fichier bif.

En hexa ca correspond a: "0x100175". Le fichier bif est donc le 175ième de la liste.

//Bif Entries
-Length of BIF file_____________20509572
-Offset from start of file____________5306
to ASCIIZ BIF filename
-Length, including terminating NUL,____18
of ASCIIZ BIF filename
-The 16 bits of this field are used______64 soit en binaire '1000000'
individually to mark the location
of the relevant file.
*(MSB) xxxx xxxx ABCD EFGH (LSB)
* Bits marked A to F determine on which CD the file is stored (A = CD6, F = CD1)
* Bit G determines if the file is in the \cache directory
* Bit H determines if the file is in the \data directory

= "data\AREA610A.bif".

Le fichier n'est pas dans le répertoire data du jeu. Je suppose qu'il est donc sur un cd?
Je passe pour le moment, la partie sur les Cd etc... J'ai pas compris comment le .ini va me sauver.

Pour le cas ci dessus, j'ai le nom du fichier Bif et le nom du fichier qu'il contient. Maintenant il faut pouvoir aller chercher ce fameux fichier dans le contenu du fichier bif.

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

L'indice est de 175 et désigne un fichier Bif.

Structure de la section File Entries d'un fichier Bif
"
//File Entries
0x0000 4 (dword) Resource locator
* NB: On disk, only bits 0-13 are matched. They are matched against the file index in the "resource locator" field from
* the KEY file resource entries which claim to exist in this BIFF.
0x0004 4 (dword) Offset (from start of file) to resource data
0x0008 4 (dword) Size of this resource
0x000c 2 (word) Type of this resource
0x000e 2 (word) Unknown
"

dc là mon resource locator doit être égal à '1048949'. Je me positionne sur cet index et j'obtiens les infos pour extraire le fichier (localisation, taille, type).

Isaya peux tu corriger les conneries que j'ai pu dire? .

27/03
la création de la liste dure environ 10-15 secondes. Le tableau constitué en base de données contient:
- Nom du fichier du jeu Ex: SPIN756
- l'extension Ex: SPL
- resource locator Ex: 18875209
- index dans le fichier Bif si resource locator en Binaire est sur plus de 20 bits.
- le chemin du fichiet bif
Ex: data\AREA0600.bif

J'ai essayé d'appliquer le raisonnement que tu as expliqué et que j'ai interprété:
"
Quand tu as la valeur 1048576, en hexadécimal 0x100000, le 1 correspond au bit 20, donc il s'agit du fichier BIF qui est à l'index 1, et la ressource indiquée est à l'index 0.
"

Ressource locator
en valeur décimale: 1048576
en binaire:10000000000000000000 (20 bits => on a index Bif)
en héxa:0x100000

Ressource locator
en valeur décimale: 18875209
en binaire:1001000000000001101001001 (25 bits => on a index Bif)
en héxa:0x1200349

bit de 25 à 20 100100
bit de 0 à 13 0001101001001
100100 (binaire) = 36 (decimal). 18ieme index bif entries du fichier Key?
soit data\AREA0400.bif (pour moi ce n'est pas le bon Bif pour un fichier SPL)

1101001001= 841. 841ieme index dans le fichier bif cible


Pour les fichiers de type IDS ou 2DA doit on trouver un fichier bif?

Coco



Coco

[Isaya]

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

Tu dis '1048576' = '100000000000000000000' en binaire
=> Ok

Le 1 est en 20ième position donc on est dans le cas 'bits 31-20: source index (the ordinal value giving the index of the corresponding BIF entry)'.
=> Ok, on a un index pour un fichier Biff. La valeur correspond à l'un des index de la section 'Bif Entries'. C'est donc le 1ier fichier Biff.

Non !

Un resource locator donne à la fois un pointage vers un fichier BIF (source index) et un pointage de resource à l'intérieur du fichier (tileset index ou non tileset file index).

Il y a toujours un index de fichier BIF. Il vaut 0, 1, 2, ... Sa valeur étant codée sur 12 bits (31-20), cela fait 2^12 valeurs possibles, de 0 à 4095. C'est pour ça que j'avais dit que le système limitait à 4096 fichiers BIF.

Ici l'index vaut 1, donc il s'agit du deuxième fichier BIF de la liste. Comme dans la plupart des cas en informatique, la valeur 0 d'un index est la première.

"-The 16 bits of this field are used______1
individually to mark the location
of the relevant file.
*(MSB) xxxx xxxx ABCD EFGH (LSB)
* Bits marked A to F determine on which CD the file is stored (A = CD6, F = CD1)
* Bit G determines if the file is in the \cache directory
* Bit H determines if the file is in the \data directory
"
="data\Default.bif"

Le fichier "AROW01" d'extension type '1005' est donc contenu sous "data\Default.bif".

Précision importante : la valeur 1 du champ 16 bits correspond en binaire au bit H. Cela signifie qu'il est indiqué que le fichier se trouve dans le sous-répertoire Data du jeu, c'est à dire que le ce fichier BIF y est placé même dans le cas d'une installation minimale.
Comme le répertoire "data/" est déjà précisé dans le nom du fichier, il faut comprendre que cette information signifie simplement qu'il suffit de chercher dans le répertoire du jeu et non sur un des CD (ou la recopie d'un CD sur disque dur).

Je prends un autre cas pr bien comprendre:
Section Resource entries / Resource locator = 1048949
nom du fichier "MISC1H" d'extension type '1005'

En décimal on a donc: "1048949"
En binaire ca correspond a: "100000000000101110101" soit 21 bits => c'est un index pour identifier le fichier bif.

En hexa ca correspond a: "0x100175". Le fichier bif est donc le 175ième de la liste.

Ce n'est pas une bonne interprétation. Il y a toujours une valeur de "source index", même quand elle vaut 0. Quelle que soit la valeur de "source index", même 0, elle désigne un fichier de la table des fichiers BIF. Ici "source index" vaut 1, donc cela désigne le deuxième fichier BIF.
Les bits 13-0 (non tileset file index) valent 0x175, soit 373, le fichier concerné est donc probablement le 374ème à l'intérieur du fichier BIF. Mais il faudra le vérifier en parcourant la table de resource au début du fichier BIF et vérifier que les bits 13-0 du "resource locator" ont bien la même valeur 0x175.

-The 16 bits of this field are used______64 soit en binaire '1000000'
individually to mark the location
of the relevant file.
*(MSB) xxxx xxxx ABCD EFGH (LSB)
* Bits marked A to F determine on which CD the file is stored (A = CD6, F = CD1)
* Bit G determines if the file is in the \cache directory
* Bit H determines if the file is in the \data directory

= "data\AREA610A.bif".

Le fichier n'est pas dans le répertoire data du jeu. Je suppose qu'il est donc sur un cd?
Je passe pour le moment, la partie sur les Cd etc... J'ai pas compris comment le .ini va me sauver.

La valeur du champ 16 bits, 1000000, permet de voir que c'est le bit B qui vaut 1. Cela désigne donc le CD 5, celui de ToB, que tu retrouves généralement dans le sous-répertoire CD5 du jeu sur disque dur si tu fais une installation complète. L'installation crée aussi un sous-répertoire data dans CD5 pour y placer les fichiers, ce qui fait que le chemin d'accès au fichier BIF est bien "data\AREA610A.BIF" à partir du répertoire CD5, que ce soit sur le disque dur (installation complète) ou sur le CD.

Pour savoir où se trouve le point de départ pour trouver les fichiers qui sont désignés comme étant sur CD, il faut utiliser les définitions de la partie [Alias] du fichier Baldur.ini.

Pourquoi ne pas simplifier et supposer que le contenu du CD 5 est forcément dans C:\Rep du jeu\CD5 ? Trois raisons :

• le moddeur n'a pas fait une installation complète, donc le fichier n'est pas présent sur le disque dur : peu probable (pas pratique pour lui), mais pas à exclure
• le moddeur a fait une installation multiple et a suivi la méthode pour ne pas dupliquer les répertoires CDn dans son répertoire de travail : du coup le sous-répertoire CDn se trouve dans le répertoire de l'installation de base, donc tu ne connais pas le chemin, sauf à lire la ligne CDn du fichier Baldur.ini
• le moddeur a un jeu basé sur un DVD multilangues : du coup certains fichiers ne se trouvent pas dans le sous-répertoire CDn, mais dans le sous-répertoire French (cf le guide d'installation de Baldur's Gate II)

Pour le cas ci dessus, j'ai le nom du fichier Bif et le nom du fichier qu'il contient. Maintenant il faut pouvoir aller chercher ce fameux fichier dans le contenu du fichier bif.

L'indice est de 175 et désigne un fichier Bif.

Non. Le "non tileset file index" vaut 0x175 ou encore 373.

Structure de la section File Entries d'un fichier Bif
"
//File Entries
0x0000 4 (dword) Resource locator
* NB: On disk, only bits 0-13 are matched. They are matched against the file index in the "resource locator" field from
* the KEY file resource entries which claim to exist in this BIFF.
0x0004 4 (dword) Offset (from start of file) to resource data
0x0008 4 (dword) Size of this resource
0x000c 2 (word) Type of this resource
0x000e 2 (word) Unknown
"

dc là mon resource locator doit être égal à '1048949'. Je me positionne sur cet index et j'obtiens les infos pour extraire le fichier (localisation, taille, type).

J'ai surligné en rouge un élément très important.
Le "resource locator" du fichier KEY sert à préciser aussi l'index du fichier BIF dans sa table (bits 31-20). Une fois qu'on est dans le fichier BIF en question, cette indication n'est pas applicable et n'a aucun intérêt puisqu'on est déjà dans le bon fichier. On n'y trouve donc que les seuls bits utiles, ceux du "non tileset file index" (bits 13-0). La comparaison du "resource locator" du fichier KEY avec le "resouce locator" doit donc se limiter à ces bits utiles, ce qu'indique la remarque surlignée.
Pour cela il faut recourir à un masque binaire, pour les deux "resource locator" à comparer. Ce qui fera donc la valeur recherchée sera 0x175.

Il y a de bonnes chances que la structure soit à l'index 373 de la table, donc la 374ème. Mais ce n'est pas certain. C'est la raison pour laquelle la documentation du format BIF (reprise dans mon explication) indique qu'il faut parcourir la table et comparer la valeur du "non tileset file index" jusqu'à trouver la structure qui correspond.

[Cocrane]

Merci pr tes précisions.

J'ai un autre problème.

J'ai 182 fichiers bifs annoncés (Count_of_BIF_entries=182).
Je parcours la section Resources entries et j'obtiens des sources_index supérieurs à 182.

Exemple:
resource locator: 189793525 soit '1011010100000000010011110101' (28 bits)
0-13: '0010011110101' soit l'index dans le fichier Bif ciblé.
20-31: '101101010' soit 363ième index bif pr la section bif entries. Mais j'ai 182 fichiers Bif annoncés.

Je ne penses pas avoir un décalage de lecture du champs resource locator.

Coco

[Isaya]

resource locator: 189793525 soit '1011010100000000010011110101' (28 bits)
0-13: '0010011110101' soit l'index dans le fichier Bif ciblé.

Tu t'es trompé : les bits 13-0, ça veut dire 14 bits, du 0 au 13 inclus, donc '00010011110101'.

20-31: '101101010' soit 363ième index bif pr la section bif entries. Mais j'ai 182 fichiers Bif annoncés.

Comme tu as 28 bits significatifs dans ta valeur converti en binaire, et qu'on compte à partir de 0, les 12 bits de poids fort (31-20) correspondent aux 8 bits de gauche de ta valeur. Ce qui donne '10110101', soit 0xB5 en hexadecimal et 171 en decimal. Donc c'est bien inférieur à 182.

De façon générale, comme je te l'ai déjà dit, la source IESDP présente très peu d'erreurs. Le plus probable en cas de problème, ce que ce soit nous qui nous trompions et pas IESDP.

[Cocrane]

Arf l'erreur qui tue.

C'est écrit noir sur blanc mais j'ai manqué de rigueur à la lecture encore une fois. Je me doutais que je ne me trompais pas sur la lecture du contenu du resource_locator mais j'ai lu 13 bits au lieu de 14. Saleté de 0. Normalement quand tu es un "zéro" tu comptes pas!
C'est toute ma base sociale qui est remise en cause là!

Je n'insinuais pas cette fois que l'erreur était chez les autres (je me suis déjà pris une baffe pas deux! ) mais je ne la voyais pas. Et parfois, ce genre d'étourderie peut prendre des heures a être trouvé.

Avec cette correction, ma liste est cohérente. Je vais attaquer l'extraction d'un fichier ciblé. Si j'ai bien compris, on lit la zone du fichier biff et on la 'colle telle que' dans un fichier de sortie qui a le nom du fichier à extraire.
> je pourrais comparer mon fichier extrait au fichier Weidu pour voir si je n'ai pas d'erreur.

Coco

[Cocrane]

Extraction réalisée dans le cas d'un Bif non compressé.

5 secondes pour extraire tous les fichiers .spl (1300)
1 secondes pour extraire tous les fichiers SPPR* dans le cas des sorts de clerc.

Je vais rajouter un étape dans l'extraction pour avoir des infos sur les sorts extraits
( level, nom fichier Bam, index tlk pr la description etc...)

Coco