Talk:OBPOS.DAT - Revision history

Morgan525: /* Aliens Storage */

2013-03-18T14:22:41Z

Aliens Storage

← Older revision		Revision as of 14:22, 18 March 2013
Line 16:		Line 16:
	: 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. -[[User:NKF\|NKF]] 08:28, 16 August 2010 (EDT)		: 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. -[[User:NKF\|NKF]] 08:28, 16 August 2010 (EDT)

	== ~~Aliens~~ Storage ==		== 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. [[User:Morgan525\|Tycho]] 10:01, 18 March 2013 (EDT)		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. [[User:Morgan525\|Tycho]] 10:01, 18 March 2013 (EDT)

Morgan525: /* Aliens Storage */

2013-03-18T14:11:44Z

Aliens Storage

← Older revision		Revision as of 14:11, 18 March 2013
Line 17:		Line 17:

	== Aliens Storage ==		== Aliens Storage ==
	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 ~~would cost~~ an alien 6 TU to pickup and place an object from the ground into this zone. It ~~cost~~ them 3 TU to move an object from the zone to their hand. [[User:Morgan525\|Tycho]] 10:01, 18 March 2013 (EDT)		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. [[User:Morgan525\|Tycho]] 10:01, 18 March 2013 (EDT)

Morgan525: /* Aliens Storage */

2013-03-18T14:01:55Z

Aliens Storage

← Older revision		Revision as of 14:01, 18 March 2013
Line 17:		Line 17:

	== Aliens Storage ==		== Aliens Storage ==
	Aliens don't have a layout matrix as XCOM ~~unit~~ 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 would cost an alien 6 TU to pickup and place an object from the ground into this zone. It cost them 3 TU to move an object from the zone to their hand. [[User:Morgan525\|Tycho]] 10:01, 18 March 2013 (EDT)		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 would cost an alien 6 TU to pickup and place an object from the ground into this zone. It cost them 3 TU to move an object from the zone to their hand. [[User:Morgan525\|Tycho]] 10:01, 18 March 2013 (EDT)

Morgan525: /* Record offsets 6 and 7 */ finding on alien storage and time used

2013-03-18T14:01:38Z

Record offsets 6 and 7: finding on alien storage and time used

← Older revision		Revision as of 14:01, 18 March 2013
Line 15:		Line 15:

	: 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. -[[User:NKF\|NKF]] 08:28, 16 August 2010 (EDT)		: 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. -[[User:NKF\|NKF]] 08:28, 16 August 2010 (EDT)

			== Aliens Storage ==
			Aliens don't have a layout matrix as XCOM unit 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 would cost an alien 6 TU to pickup and place an object from the ground into this zone. It cost them 3 TU to move an object from the zone to their hand. [[User:Morgan525\|Tycho]] 10:01, 18 March 2013 (EDT)

NKF: /* Record offsets 6 and 7 */

2010-08-16T12:28:24Z

Record offsets 6 and 7

← Older revision		Revision as of 12:28, 16 August 2010
Line 13:		Line 13:

	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) ~ [[User:Renegrade\|Renegrade]]		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) ~ [[User:Renegrade\|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. -[[User:NKF\|NKF]] 08:28, 16 August 2010 (EDT)

Renegrade: /* Record offsets 6 and 7 */

2010-08-16T11:46:17Z

Record offsets 6 and 7

← Older revision		Revision as of 11:46, 16 August 2010
Line 12:		Line 12:
	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.		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)		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) ~ [[User:Renegrade\|Renegrade]]

Renegrade: New section: Record offsets 6 and 7

2010-08-08T02:15:10Z

New section: Record offsets 6 and 7

← Older revision		Revision as of 02:15, 8 August 2010
Line 1:		Line 1:
	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. --[[User:Zombie\|Zombie]] 22:39, 30 December 2009 (EST)		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. --[[User:Zombie\|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. [[User:Spike\|Spike]]		:Worrying! Is it possible to check if the extra entries are used or not? It's possible they are just padding. [[User:Spike\|Spike]]

			== Record offsets 6 and 7 ==

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

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

			<b>7/07</b>: -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)

Spike: reply

2009-12-31T14:33:16Z

← Older revision		Revision as of 14:33, 31 December 2009
Line 1:		Line 1:
	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. --[[User:Zombie\|Zombie]] 22:39, 30 December 2009 (EST)		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. --[[User:Zombie\|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. [[User:Spike\|Spike]]

Zombie: CE has more records than DOS!

2009-12-31T03:39:13Z

CE has more records than DOS!

New page

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. --[[User:Zombie|Zombie]] 22:39, 30 December 2009 (EST)