ITM File Format

[drake127]

In IESDP is offset of ITM (v1) file defined as "Offset to Equipping Feature Blocks" but in BG2 it is always 0. It can be but how did you test it?

 

Next I wonder why you call it offset when it is index (1st effect, 2nd effect, ... in effect block).

[igi]

Purely from memory:

 

That fact that it's always 0 in BG2 .itm files doesn't mean it *has* to be 0. There is a standard layout of the structures in the .itm files (as there is a standard layout of the structures in the other file types, e.g. are), but it is not necessary to stick to this layout, you can have feature blocks before extended headers if you want.

 

 

Offset and index are almost interchangable in this context, although it should probably be specified what it's an offset from...

[drake127]

That fact that it's always 0 in BG2 .itm files doesn't mean it *has* to be 0. There is a standard layout of the structures in the .itm files (as there is a standard layout of the structures in the other file types, e.g. are), but it is not necessary to stick to this layout, you can have feature blocks before extended headers if you want.

I only asked if somebody had tested it with other value than zero. It is logical because EffectIndex and EffectCount make couple and there is no nedd to expect here it is different but since in BG2 it is always zero (and global effects starts always at begin of effects) I had asked if it is really confirmed.

[drake127]

0x0010 | 8 (dword) | Replacement Item (resref)

It is array of chars - it cannot be dword. It only can be qword but it is array of chars (resref)

 

Ext. Header: Size= 40 Bytes

(...)

Extended Header

0x0000 | 1 (char) | Attack Type

(...)

0x0036 | 2 (word) | Misc. Projectile Qualifier (0=No, 1=Yes)

It can't be truth - 0x36 + word = 0x38 = 56

 

Pictrure of item structure is broken.

[devSin]

That was just lazy copying from spells. The spell header is 40 (0x28) bytes. The item header is 56 (0x38) bytes.

[drake127]

That was just lazy copying from spells. The spell header is 40 (0x28) bytes. The item header is 56 (0x38) bytes.

It had caused me little trouble in code so I had to mention it. I know it is not much important.

(READ_SHORT (%ExtHeaderOffset% + %i% * 0x38 + 0x1e) %LocalEffectCount%)

[Avenger]

IMO, if it is an index IESDP should say so.

And in this case it is

Offset and index are not interchangeable and most of the times used correctly.

 

Usually: an offset (whether relative or absolute) does not need any multiplication to get an absolute address.

An index needs a multiplication of the record size and adding an OFFSET.

This flaw in the IESDP caused me some problem when i wrote my first item checker