STO format error

[Guest Guest_Lord_Jeremy_*]

There appears to be an error in versions 1, 1.1 and 9 of the STO file format in the IESDP. At offset 0x0022 of the header the size (data type) is specified as 2 (dword). I'm not sure if this is supposed to be 2 (word) or 4 (dword).

 

I also have a question regarding the definition of word and dword. I'm wondering if values of these types are unsigned or signed by default.

[jon-eli]

I believe the values are all unsigned unless otherwise specified.

[devSin]

Actually, they should mostly be signed (unsigned is the exception), but you'll never approach values where it would matter 99% of the time.

 

The capacity field could be a DWORD, but then it'd just be followed by 6 bytes of reserved space instead of the 8 it's currently listed at (the next used field is at 0x2C).

[jon-eli]

@devSin

 

I'll admit it was just a guess, based on the IESDP following the basic trend of:

 

0x0024 	2 (word)
0x0026 	2 (word)
0x0028 	2 (word)
0x002a 	2 (word)
[...]
0x0046 	2 (signed word)
0x0048 	2 (signed word)
0x004a 	2 (signed word)
0x004c 	2 (signed word)

 

I would have expected the exceptions to be pointed out, rather than, uhm... whatever it is that's going on here.

[devSin]

The CRE format is tricky since a lot of the byte values (the stats) need to be unsigned to work (can go up to 255 in Find Traps, for instance). But for 2- and 4-byte values (that aren't offsets or counts), whether they're signed or unsigned usually has no consequence (you'd never have occasion to use a value "large" enough to tell).

 

I would guess this is just pointed out explicitly here because negative armor class and AC modifiers (although those four CRE fields are never written to) are very common. The HP fields are also signed, for instance, but it doesn't matter, since you'd never have cause to pre-assign negative hit points in a CRE. Animation is a limited value, so signedness doesn't matter (I believe it's actually a DWORD where only the lower word is read, so it's not even a WORD, signed or unsigned).

[igi]

Ignoring whether values are signed; this topic basically says "0x22 may be a word and two unused bytes, or a dword (with the second two bytes unused)". I'm unsure of the worth of noting this in the IESDP.