Talk:UNITPOS.DAT - Revision history

Volutar: /* Flag field 10 (0x0a) */

2011-04-10T09:31:36Z

Flag field 10 (0x0a)

← Older revision		Revision as of 09:31, 10 April 2011
Line 94:		Line 94:
	When finding very first "sububit" of any selected part of bigunit: first_subunit = subunit - (subunit.flag >> 3) & 3;		When finding very first "sububit" of any selected part of bigunit: first_subunit = subunit - (subunit.flag >> 3) & 3;

	bit 7 (mask 0x80) used for reaction fire (changed in runtime). Normally reaction fire works only for enemy units within viewsector. But when this flag is set, unit become _revealed_ even for reaction fire of units turned away. This flag is set when unit got hit by someone (even from friendly fire or explosion). Presumably this bit mean reaction bonus ~~caused by~~ "~~damage sound~~".		bit 7 (mask 0x80) used for reaction fire (changed in runtime). Normally reaction fire works only for enemy units within viewsector. But when this flag is set, your unit become _revealed_ even for reaction fire of units turned away (who have this flag). This flag is set when unit got hit by someone (even from friendly fire or explosion). Presumably this bit mean reaction bonus, like "waking up" or extra cautious.
	--[[User:Volutar\|Volutar]] 02:40, 10 April 2011 (EDT)		--[[User:Volutar\|Volutar]] 05:31, 10 April 2011 (EDT)

Volutar at 06:40, 10 April 2011

2011-04-10T06:40:49Z

← Older revision		Revision as of 06:40, 10 April 2011
Line 79:		Line 79:

	:: I'm sure there are a heck of a lot of bad programming practices used back then which are not acceptable with today's standards in programming. However, for something that was basically started by two guys in their garage (that could be an exaggeration, of course!), we still ended up with a fairly decent game. Would be nice if we ever got the opportunity to debug the source code. -[[User:NKF\|NKF]] 03:43, 23 August 2010 (EDT)		:: I'm sure there are a heck of a lot of bad programming practices used back then which are not acceptable with today's standards in programming. However, for something that was basically started by two guys in their garage (that could be an exaggeration, of course!), we still ended up with a fairly decent game. Would be nice if we ever got the opportunity to debug the source code. -[[User:NKF\|NKF]] 03:43, 23 August 2010 (EDT)

			== Flag field 10 (0x0a) ==

			Actually this is 32bit value, but used only first byte.
			And bits 3-4 (mask 0x18) isn't a bitfield, it's rather offset to corresponding part of bigunit.

			So in memory there are 4 small unit for each bigunit:

			0x00 0 top-left subunit
			0x08 1 top-right subunit
			0x10 2 bottom-left subunit
			0x18 3 bottom-right subunit

			When finding very first "sububit" of any selected part of bigunit: first_subunit = subunit - (subunit.flag >> 3) & 3;

			bit 7 (mask 0x80) used for reaction fire (changed in runtime). Normally reaction fire works only for enemy units within viewsector. But when this flag is set, unit become _revealed_ even for reaction fire of units turned away. This flag is set when unit got hit by someone (even from friendly fire or explosion). Presumably this bit mean reaction bonus caused by "damage sound".
			--[[User:Volutar\|Volutar]] 02:40, 10 April 2011 (EDT)

NKF: /* Offsets 4-7 */ some guesswork

2010-08-23T07:54:15Z

Offsets 4-7: some guesswork

← Older revision		Revision as of 07:54, 23 August 2010
Line 76:		Line 76:
	: Yes, it's reasonable to assume large units were added later. The game <b>should</b> be smart enough to always count a large unit as 4 UNITPOS slots, but I'm not sure how much pre-release playtesting XCOM actually received. [The free manufacturing bug would have been pretty easy to spot by a systematic testing regime.] -- [[User:Zaimoni\|Zaimoni]] 23:47, 22 August 2010 (CDT)		: Yes, it's reasonable to assume large units were added later. The game <b>should</b> be smart enough to always count a large unit as 4 UNITPOS slots, but I'm not sure how much pre-release playtesting XCOM actually received. [The free manufacturing bug would have been pretty easy to spot by a systematic testing regime.] -- [[User:Zaimoni\|Zaimoni]] 23:47, 22 August 2010 (CDT)

	:: I think the easier way to look at it is that UNITPOS is what they work off primarily, then offset the index reference to UNITREF as necessary based on what sort of units are in the list. The UNITPOS entries do identify if they are large units or otherwise, and which segment they are. When you issue a move order, the game updates the first segment (the primary quarter, which is also the only one they seem to base almost all of their collision detection on), then just updates the position of the next three segments accordingly.		:: I think the easier way to look at it is that UNITPOS is what they work off primarily, then offset the index reference to UNITREF as necessary based on what sort of units are in the list. The UNITPOS entries do identify if they are large units or otherwise, and which segment they are. When you issue a move order, the game updates the first segment (the primary quarter, which is also the only one they seem to base almost all of their collision detection on), then just updates the position of the next three segments accordingly. Not sure why they ended up using this system as it would have been easier to handle one line of data for all units rather than several for a single unit. This is just conjecture, but one of the possible reasons for this may be to speed up rendering the units on the isometric map. By having the dummy units in UNITPOS, the game just has to check through UNITPOS for each tile it's rendering and simply draws the unit that it comes across that is occupying the tile. If they only had one record per large unit, each tile that is redrawn would have to go through UNITPOS/UNITREF to check if it's a small or large unit and draw it if it's on the same tile. If it's a large unit, check if any of its projecting sides are in the current tile. I imagine all that overhead would've made the rendering a bit slower. Especialyl on the x80286/386 machines that this game was built to run on. Again, that's just guesswork on my part.

	:: I'm sure there are a heck of a lot of bad programming practices used back then which are not acceptable with today's standards in programming. However, for something that was basically started by two guys in their garage (that could be an ~~exaggerating~~, of course!), we still ended up with a fairly decent game. Would be nice if we ever got the opportunity to debug the source code. -[[User:NKF\|NKF]] 03:43, 23 August 2010 (EDT)		:: I'm sure there are a heck of a lot of bad programming practices used back then which are not acceptable with today's standards in programming. However, for something that was basically started by two guys in their garage (that could be an exaggeration, of course!), we still ended up with a fairly decent game. Would be nice if we ever got the opportunity to debug the source code. -[[User:NKF\|NKF]] 03:43, 23 August 2010 (EDT)

NKF: /* Offsets 4-7 */

2010-08-23T07:43:57Z

Offsets 4-7

← Older revision		Revision as of 07:43, 23 August 2010
Line 75:		Line 75:

	: Yes, it's reasonable to assume large units were added later. The game <b>should</b> be smart enough to always count a large unit as 4 UNITPOS slots, but I'm not sure how much pre-release playtesting XCOM actually received. [The free manufacturing bug would have been pretty easy to spot by a systematic testing regime.] -- [[User:Zaimoni\|Zaimoni]] 23:47, 22 August 2010 (CDT)		: Yes, it's reasonable to assume large units were added later. The game <b>should</b> be smart enough to always count a large unit as 4 UNITPOS slots, but I'm not sure how much pre-release playtesting XCOM actually received. [The free manufacturing bug would have been pretty easy to spot by a systematic testing regime.] -- [[User:Zaimoni\|Zaimoni]] 23:47, 22 August 2010 (CDT)

			:: I think the easier way to look at it is that UNITPOS is what they work off primarily, then offset the index reference to UNITREF as necessary based on what sort of units are in the list. The UNITPOS entries do identify if they are large units or otherwise, and which segment they are. When you issue a move order, the game updates the first segment (the primary quarter, which is also the only one they seem to base almost all of their collision detection on), then just updates the position of the next three segments accordingly.

			:: I'm sure there are a heck of a lot of bad programming practices used back then which are not acceptable with today's standards in programming. However, for something that was basically started by two guys in their garage (that could be an exaggerating, of course!), we still ended up with a fairly decent game. Would be nice if we ever got the opportunity to debug the source code. -[[User:NKF\|NKF]] 03:43, 23 August 2010 (EDT)

Zaimoni at 04:48, 23 August 2010

2010-08-23T04:48:08Z

← Older revision		Revision as of 04:48, 23 August 2010
Line 73:		Line 73:

	~ [[User:Renegrade\|Renegrade]] 12:02, 22 August 2010 (EDT)		~ [[User:Renegrade\|Renegrade]] 12:02, 22 August 2010 (EDT)

			: Yes, it's reasonable to assume large units were added later. The game <b>should</b> be smart enough to always count a large unit as 4 UNITPOS slots, but I'm not sure how much pre-release playtesting XCOM actually received. [The free manufacturing bug would have been pretty easy to spot by a systematic testing regime.] -- [[User:Zaimoni\|Zaimoni]] 23:47, 22 August 2010 (CDT)

Renegrade: /* Offsets 4-7 */

2010-08-22T18:42:47Z

Offsets 4-7

← Older revision		Revision as of 18:42, 22 August 2010
Line 69:		Line 69:

	Is this the only reference tying UNITPOS and UNITREF together, aside from the position on disk/in memory? I'm guessing after the file is reloaded, they step through UNITREF, and use something there to determine whether or not there are 1 or 4 UNITPOS records associated and update this pointer correctly. But then how are UNITPOS records updated while the game runs? They must either have some internal memory-only linkage that isn't saved, or are always updating/using UNITREF from the state of UNITPOS? Having to search every UNITPOS's pointer to find the UNITPOS from the UNITREF record's side would be rather expensive if it has to be repeated :S		Is this the only reference tying UNITPOS and UNITREF together, aside from the position on disk/in memory? I'm guessing after the file is reloaded, they step through UNITREF, and use something there to determine whether or not there are 1 or 4 UNITPOS records associated and update this pointer correctly. But then how are UNITPOS records updated while the game runs? They must either have some internal memory-only linkage that isn't saved, or are always updating/using UNITREF from the state of UNITPOS? Having to search every UNITPOS's pointer to find the UNITPOS from the UNITREF record's side would be rather expensive if it has to be repeated :S

			An additional thought occurred to me: there's 80 of these, and 80 of UNITREF, yet there could be as many as 320 UNITPOS records for a set of 80 large units in UNITREF. Could the crashes relating to overstuffed base defense missions have something to do with there being too many UNITPOS entries for the UNITPOS array? Perhaps in XCOM's early stages, UNITPOS and UNITREF were 1:1 and large units were added later?

	~ [[User:Renegrade\|Renegrade]] 12:02, 22 August 2010 (EDT)		~ [[User:Renegrade\|Renegrade]] 12:02, 22 August 2010 (EDT)

Renegrade: /* Offsets 4-7 */

2010-08-22T16:02:16Z

Offsets 4-7

← Older revision		Revision as of 16:02, 22 August 2010
Line 64:		Line 64:

	- [[User:Bomb Bloke\|Bomb Bloke]] 20:01, 9 February 2008 (PST)		- [[User:Bomb Bloke\|Bomb Bloke]] 20:01, 9 February 2008 (PST)


			----

			Is this the only reference tying UNITPOS and UNITREF together, aside from the position on disk/in memory? I'm guessing after the file is reloaded, they step through UNITREF, and use something there to determine whether or not there are 1 or 4 UNITPOS records associated and update this pointer correctly. But then how are UNITPOS records updated while the game runs? They must either have some internal memory-only linkage that isn't saved, or are always updating/using UNITREF from the state of UNITPOS? Having to search every UNITPOS's pointer to find the UNITPOS from the UNITREF record's side would be rather expensive if it has to be repeated :S

			~ [[User:Renegrade\|Renegrade]] 12:02, 22 August 2010 (EDT)

Bomb Bloke: /* Offsets 4-7 */

2008-02-10T04:01:31Z

Offsets 4-7

← Older revision		Revision as of 04:01, 10 February 2008
Line 52:		Line 52:

	Looks like it's a raw memory pointer to unitref data. For big units, the 4 parts seems to points to the same data.		Looks like it's a raw memory pointer to unitref data. For big units, the 4 parts seems to points to the same data.

			- [[User:Seb76\|Seb76]]

			------

			O_O

			You've gotta be right; the values increment by 124 (the UnitRef record size).

			(Could you please sign your Talk comments? Just stick in four consecutive tildes (~), the Wiki'll convert that to the time/date/username info).

			- [[User:Bomb Bloke\|Bomb Bloke]] 20:01, 9 February 2008 (PST)

Seb76: New section: Offsets 4-7

2008-02-09T23:03:29Z

New section: Offsets 4-7

← Older revision		Revision as of 23:03, 9 February 2008
Line 48:		Line 48:

	- [[User:Bomb Bloke\|Bomb Bloke]] 03:15, 25 April 2007 (PDT)		- [[User:Bomb Bloke\|Bomb Bloke]] 03:15, 25 April 2007 (PDT)

			== Offsets 4-7 ==

			Looks like it's a raw memory pointer to unitref data. For big units, the 4 parts seems to points to the same data.

Bomb Bloke: /* Offset 8 */

2007-04-25T10:15:12Z

Offset 8

← Older revision		Revision as of 10:15, 25 April 2007
Line 38:		Line 38:
	I remember reading somewhere about the aliens knowing where you are from the start, but I can't remember the details.		I remember reading somewhere about the aliens knowing where you are from the start, but I can't remember the details.
	[[User:Pi Masta\|Pi Masta]] 20:26, 14 February 2007 (PST)		[[User:Pi Masta\|Pi Masta]] 20:26, 14 February 2007 (PST)

			-----------------------------

			I'm pretty sure you're right; I never tested to see what this value did over time, I just noticed it reset when you spotted something. I never twigged that it'd be to do with the intellegence byte as I only noticed it change when I spotted aliens (as opposed to when they spotted ME!).

			The rumor goes that if the aliens know where one of your units is, they know where ALL of them are until they "forget". This has to be that counter byte. The only question I have is when it increments (when you have your turn, when the aliens have theirs, or both).

			I suspect the byte is somewhat redundant in the case of aliens, as a seperate "visibility" flag (see offset 10) is used so you can keep track of enemies. Still, it might be interesting to boost one of your own units intellegence somewhat and see what happens.

			- [[User:Bomb Bloke\|Bomb Bloke]] 03:15, 25 April 2007 (PDT)