Talk:OBPOS.DAT

My version of TFTD (Collector's Edition) has a file size of 3360 bytes. At 16 bytes per record, that comes to 210 records. I guess the programmers increased the size of this file a bit from the DOS version which only has 200 records of 16 bytes for a total file size of 3200 bytes. --Zombie 22:39, 30 December 2009 (EST)

Worrying! Is it possible to check if the extra entries are used or not? It's possible they are just padding. Spike

Record offsets 6 and 7

The record offsets at 6/7 are showing as this:

6/06: Object the current item is loaded into. -1/255 by default for no item. (Uses obpos item index - first object in obpos is 0).

7/07: -1/255 by default, otherwise 0 if the item is loaded into something.

It would seem likely to me, based on that, and examining the file myself, that 6 and 7 form a 16-bit value (uint16_t or int16_t), with 0xFFFF being 'not loaded' and the full 16-bit value being what it's loaded into. It's possible at the time that field was defined that they expected more than 255 items in the file. Note that 170/200 is getting close to the limit, and no other field here appears to be related to offsets in this file. I'm surprised even that they skimped on these filesizes -- putting 400 records in here would only add 3200 bytes to the memory/disk load. Note too that address 6 is word-aligned.

Also, I don't find it that odd that they don't update the physical position of an item that's being carried. Updating a carried item's position would increase the overhead significantly for little gain, as the position can be easily calculated when needed from the location of the unit carrying it. (ex, if the unit drops it in any way, simply update the field there and then. The border between carried and dropped should be fairly well defined) ~ Renegrade