Talk:OBPOS.DAT

From UFOpaedia
Revision as of 14:22, 18 March 2013 by Morgan525 (talk | contribs) (→‎Aliens Storage)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

I think it's not so much a problem with updating the position in real-time as the owner moves about as such, but is the position of the equipment being properly updated when it should be in relation to the owner for some of the effects mentioned in the article. Like where to drop a body when it's created (perhaps after being moved and either killed by grenade/wounds), or where to center an explosion. Though I've seen it happen when I was experimenting with the weapon flags to see what did what, I can't off the top of my head recall how you'd cause an explosion to be set off in a different location in the course of a normal game. -NKF 08:28, 16 August 2010 (EDT)

Alien's Storage Zone

Aliens don't have a layout matrix as XCOM units do, although if one were to look at their inventory the default man image and layout is used. Anything not held in hand is stored in a nimblous area of 23 spaces (25 including both hands) with space 2 on the layout being the representation of this phantom zone. For every object they have, the space of the object (WxH) is deducted from this amount. It costs an alien 6 TU to pickup and place an object from the ground into this zone. It costs them 3 TU to move an object from the zone to their hand. Tycho 10:01, 18 March 2013 (EDT)