KEY file format

[Guest Baum]

IESDP says, the 32bit value is divided into three parts:

 

# bits 31-20: source index (on disk, this is 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)

 

I believe the last part is really 12 bits long, these are bits 11 - 0. Probably the tileset index is then 19 - 12.

[Avenger]

DLTCEP uses 0x3fff (14 bits) for file index

and 0xfc000 (6 bits) for tiles.

 

It works correctly.

 

So, i think IESDP is good as it is.

[Guest Guest]

I'm using 12 bits for file index now. Also works.

I don't work with tilesets, though.

[Avenger]

I'm using 12 bits for file index now. Also works.

I don't work with tilesets, though.

<{POST_SNAPBACK}>

Do try them

[Guest Baum]

I won't need tilesets for this program, and I don't have the time to work on things I don't need. Still I find this IESDP entry quite confusing, as it seems to contradict itself.

 

What do you do with the 14 bits for the files index?

[Avenger]

I use it to count resources

I don't see how 12 bits are less confusing than 14 bits.

[Guest Guest]

Hm, I use the index to go directly to the file entry inside the BIFF.

 

The confusing thing is, that it states the index is both 14 and 12 bits.

[Avenger]

Your method will not work always (though dltcep does the same).

Older versions of weidu mixed the bif entries, so you had to match the resource indicators (reading through all the bif and compare the fields one by one).

 

If the field in the bif is 12 bits length, then you are right, but still the tileset field is 14 bits off inside the dword.

 

It is quite easy to check, but i let you to do it:

change the first resource ID in the bif and chitin.key to 0x3ffff.

Check if the game can still find it.

 

I think dltcep can find it only if you enable the weidu compatibility option

The game will find it, and your tool won't...

 

If you want to be sure if it is 12 or 14 bits, modify one of the 3ffff to ffff.

[Guest Baum]

Your method will not work always (though dltcep does the same).

Older versions of weidu mixed the bif entries, so you had to match the resource indicators (reading through all the bif and compare the fields one by one).

 

I did the same originally, but it was so slow...

If both the 14bit and the 12bit index lead to the same entry, this means, that bits 14 and 13 are always zero.

I will check the WeiDu issue, if I get the time.

 

It is quite easy to check, but i let you to do it:

change the first resource ID in the bif and chitin.key to 0x3ffff.

Check if the game can still find it.

I think dltcep can find it only if you enable the weidu compatibility option

The game will find it, and your tool won't...

 

My code is for reading only, not for writing. So the question for me is not, if the game can use 14 bit entries, but if it does use them anywhere. I haven't found any, though.

[Avenger]

I doubt it uses more than 8 bits if that's your question.

But why are you writing on iesdp then

 

The original bifs and those created by dltcep, ni (and those created by the new weidu), are compatible with the faster method.

[Guest Baum]

I doubt it uses more than 8 bits if that's your question.

But why are you writing on iesdp then

 

The original bifs and those created by dltcep, ni (and those created by the new weidu), are compatible with the faster method.

<{POST_SNAPBACK}>

 

IESDP has been very helpful in many cases. But the description of the KEY file was quite confusing for me.

 

I think, I'll keep the faster method and hope I won't get a mixed up BIFF file.

Thanks for your help!