PRODUCT.DAT - Revision history

Hobbes at 04:35, 23 July 2013

2013-07-23T04:35:37Z

← Older revision		Revision as of 04:35, 23 July 2013
Line 81:		Line 81:
	* [[Saved Game Files]]		* [[Saved Game Files]]
	[[Category:Game Files]]		[[Category:Game Files]]
			[[Category:Enemy Unknown/UFO Defense]]

Spike: /* Structure */ index into BASE.DAT for item manufactured

2012-09-11T00:17:46Z

Structure: index into BASE.DAT for item manufactured

← Older revision		Revision as of 00:17, 11 September 2012
Line 26:		Line 26:
	:Note that these bytes are also the cause of the [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers\|Fusion Ball Launcher (FBL) manufacturing "bug"]]. The FBL does not require an Alien Alloy for the first FBL made (as shown on the Build screen), but subsequent FBLs made in the same batch run ''do'' require an Alloy. For the FBL (the first Product in this file), bytes 8-13 read: 255, 88, 255, 0, 1, 0. It is the '''only''' PRODUCT.DAT item that does not have all its prerequisites shifted to the left (i.e., byte 8 is never null if there is a prequisite, for everything but the FBL). Apparently the Build screen itself (and the first item made) is coded to stop checking prerequisites as soon as it finds a null prereq - but subsequently the manufacturing code ''does'' check all 3 prerequisite columns. Editing PRODUCT.DAT to shift the Alloy prereq "left" fixes the problem (the first FBL shows, and uses, one Alloy). This fix only affects new production jobs; current jobs are stored in BPROD.DAT. Also note that the source data for PRODUCT.DAT is stored in the .EXE; you'd have to edit the executable to permanently fix the bug. Or just consider it a tiny gift from the programmers - one Alloy saved for each FBL manufacturing job - and get back to work saving the world. ''Courtesy of Zombie:'' The Executable's source bytes for PRODUCT.DAT's FBL are 459821-459838 in [[HackerTools\|MS-Edit]] with 100 columns or 459720-459737 normally. Just look for 255, 88, 255 and that'll be the start of the mess. This is for the CE executable. If you have the DOS version, simply search for the three numbers above and you should find it near the end of Geoscape.exe.		:Note that these bytes are also the cause of the [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers\|Fusion Ball Launcher (FBL) manufacturing "bug"]]. The FBL does not require an Alien Alloy for the first FBL made (as shown on the Build screen), but subsequent FBLs made in the same batch run ''do'' require an Alloy. For the FBL (the first Product in this file), bytes 8-13 read: 255, 88, 255, 0, 1, 0. It is the '''only''' PRODUCT.DAT item that does not have all its prerequisites shifted to the left (i.e., byte 8 is never null if there is a prequisite, for everything but the FBL). Apparently the Build screen itself (and the first item made) is coded to stop checking prerequisites as soon as it finds a null prereq - but subsequently the manufacturing code ''does'' check all 3 prerequisite columns. Editing PRODUCT.DAT to shift the Alloy prereq "left" fixes the problem (the first FBL shows, and uses, one Alloy). This fix only affects new production jobs; current jobs are stored in BPROD.DAT. Also note that the source data for PRODUCT.DAT is stored in the .EXE; you'd have to edit the executable to permanently fix the bug. Or just consider it a tiny gift from the programmers - one Alloy saved for each FBL manufacturing job - and get back to work saving the world. ''Courtesy of Zombie:'' The Executable's source bytes for PRODUCT.DAT's FBL are 459821-459838 in [[HackerTools\|MS-Edit]] with 100 columns or 459720-459737 normally. Just look for 255, 88, 255 and that'll be the start of the mess. This is for the CE executable. If you have the DOS version, simply search for the three numbers above and you should find it near the end of Geoscape.exe.

	'''14 (1 Byte):''' Item type manufactured. ~~Indexes~~ into [[BASE.DAT]].		'''14 (1 Byte):''' Item type manufactured. This is a record index (not byte index) into the Stores section of [[BASE.DAT]]. To convert this value to a byte offset into BASE.DAT, x 2 (Stores section record length = 2 bytes) and add 16 (BASE.DAT header length = 16 bytes).

	'''15 (1 Byte):''' Unknown - always 1? [Not used]		'''15 (1 Byte):''' Unknown - always 1? [Not used]

Volutar: /* Structure */

2011-04-02T12:56:08Z

Structure

← Older revision		Revision as of 12:56, 2 April 2011
Line 28:		Line 28:
	'''14 (1 Byte):''' Item type manufactured. Indexes into [[BASE.DAT]].		'''14 (1 Byte):''' Item type manufactured. Indexes into [[BASE.DAT]].

	'''15 (1 Byte):''' Unknown - always 1?		'''15 (1 Byte):''' Unknown - always 1? [Not used]

	'''16 (1 Byte?):''' Researched / Can Build flag. At the start of game, all values are set to 1.		'''16 (1 Byte?):''' Researched / Can Build flag. At the start of game, all values are set to 1.
Line 34:		Line 34:
	:* 1 - Cannot be built (yet; needs research)		:* 1 - Cannot be built (yet; needs research)

	'''17 (1 Byte):''' Unknown - always 0?		'''17 (1 Byte):''' Unknown - always 0? [Not used]

	==List of Entries==		==List of Entries==

Emphyrio: corrected offset

2009-02-25T20:58:49Z

corrected offset

← Older revision		Revision as of 20:58, 25 February 2009
Line 3:		Line 3:
	Most (if not all) of this info was obtained from [http://www.stonepool.com/xcom/hacking/product.html Hatfarm's] website. There are still values that are unknown in their function.		Most (if not all) of this info was obtained from [http://www.stonepool.com/xcom/hacking/product.html Hatfarm's] website. There are still values that are unknown in their function.

	The PRODUCT.DAT data can also be found at offset ~~355596~~ in the vanilla 1.4 [[GEOSCAPE.EXE]].		The PRODUCT.DAT data can also be found at offset 355600 in the vanilla 1.4 [[GEOSCAPE.EXE]].

	==Structure==		==Structure==

MikeTheRed: Added GEOSCAPE link per Emphyrio

2009-02-25T17:15:34Z

Added GEOSCAPE link per Emphyrio

← Older revision		Revision as of 17:15, 25 February 2009
Line 2:		Line 2:

	Most (if not all) of this info was obtained from [http://www.stonepool.com/xcom/hacking/product.html Hatfarm's] website. There are still values that are unknown in their function.		Most (if not all) of this info was obtained from [http://www.stonepool.com/xcom/hacking/product.html Hatfarm's] website. There are still values that are unknown in their function.

			The PRODUCT.DAT data can also be found at offset 355596 in the vanilla 1.4 [[GEOSCAPE.EXE]].

	==Structure==		==Structure==

MikeTheRed: Added Zombie's hacking info

2008-05-15T22:56:27Z

Added Zombie's hacking info

← Older revision		Revision as of 22:56, 15 May 2008
Line 22:		Line 22:
	:This is an odd packing scheme because they used 6 bytes to show values for only 4 possible prerequisites. They could've just used 4 bytes, with each one specific to the four prereq types. Possibly they were originally thinking of having many more types of prequisites (but any one item could only have a max of 3 prerequisites). Perhaps e.g. TFTD has more prereqs. In any event, it's interesting inasmuch as it's a rare(?) example of X-COM packing data that should have been in an external list (per relational database rules) into its parent flat file. A somewhat similar example can be found with ammo requirements in bytes 25-28 of [[OBDATA.DAT]].		:This is an odd packing scheme because they used 6 bytes to show values for only 4 possible prerequisites. They could've just used 4 bytes, with each one specific to the four prereq types. Possibly they were originally thinking of having many more types of prequisites (but any one item could only have a max of 3 prerequisites). Perhaps e.g. TFTD has more prereqs. In any event, it's interesting inasmuch as it's a rare(?) example of X-COM packing data that should have been in an external list (per relational database rules) into its parent flat file. A somewhat similar example can be found with ammo requirements in bytes 25-28 of [[OBDATA.DAT]].

	:Note that these bytes are also the cause of the [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers\|Fusion Ball Launcher (FBL) manufacturing "bug"]]. The FBL does not require an Alien Alloy for the first FBL made (as shown on the Build screen), but subsequent FBLs made in the same batch run ''do'' require an Alloy. For the FBL (the first Product in this file), bytes 8-13 read: 255, 88, 255, 0, 1, 0. It is the '''only''' PRODUCT.DAT item that does not have all its prerequisites shifted to the left (i.e., byte 8 is never null if there is a prequisite, for everything but the FBL). Apparently the Build screen itself (and the first item made) is coded to stop checking prerequisites as soon as it finds a null prereq - but subsequently the manufacturing code ''does'' check all 3 prerequisite columns. Editing PRODUCT.DAT to shift the Alloy prereq "left" fixes the problem (the first FBL shows, and uses, one Alloy). This fix only affects new production jobs; current jobs are stored in BPROD.DAT. Also note that the source data for PRODUCT.DAT is stored in the .EXE; you'd have to edit the executable to permanently fix the bug. Or just consider it a tiny gift from the programmers - one Alloy saved for each FBL manufacturing job - and get back to work saving the world.		:Note that these bytes are also the cause of the [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers\|Fusion Ball Launcher (FBL) manufacturing "bug"]]. The FBL does not require an Alien Alloy for the first FBL made (as shown on the Build screen), but subsequent FBLs made in the same batch run ''do'' require an Alloy. For the FBL (the first Product in this file), bytes 8-13 read: 255, 88, 255, 0, 1, 0. It is the '''only''' PRODUCT.DAT item that does not have all its prerequisites shifted to the left (i.e., byte 8 is never null if there is a prequisite, for everything but the FBL). Apparently the Build screen itself (and the first item made) is coded to stop checking prerequisites as soon as it finds a null prereq - but subsequently the manufacturing code ''does'' check all 3 prerequisite columns. Editing PRODUCT.DAT to shift the Alloy prereq "left" fixes the problem (the first FBL shows, and uses, one Alloy). This fix only affects new production jobs; current jobs are stored in BPROD.DAT. Also note that the source data for PRODUCT.DAT is stored in the .EXE; you'd have to edit the executable to permanently fix the bug. Or just consider it a tiny gift from the programmers - one Alloy saved for each FBL manufacturing job - and get back to work saving the world. ''Courtesy of Zombie:'' The Executable's source bytes for PRODUCT.DAT's FBL are 459821-459838 in [[HackerTools\|MS-Edit]] with 100 columns or 459720-459737 normally. Just look for 255, 88, 255 and that'll be the start of the mess. This is for the CE executable. If you have the DOS version, simply search for the three numbers above and you should find it near the end of Geoscape.exe.

	'''14 (1 Byte):''' Item type manufactured. Indexes into [[BASE.DAT]].		'''14 (1 Byte):''' Item type manufactured. Indexes into [[BASE.DAT]].

MikeTheRed: /* Structure */ Added Zombie's testing

2008-05-15T03:48:21Z

Structure: Added Zombie's testing

← Older revision		Revision as of 03:48, 15 May 2008
Line 22:		Line 22:
	:This is an odd packing scheme because they used 6 bytes to show values for only 4 possible prerequisites. They could've just used 4 bytes, with each one specific to the four prereq types. Possibly they were originally thinking of having many more types of prequisites (but any one item could only have a max of 3 prerequisites). Perhaps e.g. TFTD has more prereqs. In any event, it's interesting inasmuch as it's a rare(?) example of X-COM packing data that should have been in an external list (per relational database rules) into its parent flat file. A somewhat similar example can be found with ammo requirements in bytes 25-28 of [[OBDATA.DAT]].		:This is an odd packing scheme because they used 6 bytes to show values for only 4 possible prerequisites. They could've just used 4 bytes, with each one specific to the four prereq types. Possibly they were originally thinking of having many more types of prequisites (but any one item could only have a max of 3 prerequisites). Perhaps e.g. TFTD has more prereqs. In any event, it's interesting inasmuch as it's a rare(?) example of X-COM packing data that should have been in an external list (per relational database rules) into its parent flat file. A somewhat similar example can be found with ammo requirements in bytes 25-28 of [[OBDATA.DAT]].

	:~~Here we~~ also ~~see~~ the ~~possible~~ cause of the [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers\|Fusion Ball Launcher]] (FBL) manufacturing "bug". The FBL does not require an Alien Alloy for the first FBL made (as shown on the Build screen), but subsequent FBLs made in the same batch run ''do'' require an Alloy. For the FBL (the first Product in ~~the~~ file), bytes 8-13 read: 255, 88, 255, 0, 1, 0. It is the '''only''' ~~product~~ that does not have all its prerequisites shifted to the left (i.e., byte 8 is never null if there is a prequisite, for everything but the FBL). Apparently the Build screen itself (and the first item made) is coded to stop ~~looking for~~ prerequisites as soon as it ~~encounters~~ a null ~~one~~ - but subsequently the manufacturing code ''does'' check all 3 prerequisite columns.		:Note that these bytes are also the cause of the [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers\|Fusion Ball Launcher (FBL) manufacturing "bug"]]. The FBL does not require an Alien Alloy for the first FBL made (as shown on the Build screen), but subsequent FBLs made in the same batch run ''do'' require an Alloy. For the FBL (the first Product in this file), bytes 8-13 read: 255, 88, 255, 0, 1, 0. It is the '''only''' PRODUCT.DAT item that does not have all its prerequisites shifted to the left (i.e., byte 8 is never null if there is a prequisite, for everything but the FBL). Apparently the Build screen itself (and the first item made) is coded to stop checking prerequisites as soon as it finds a null prereq - but subsequently the manufacturing code ''does'' check all 3 prerequisite columns. Editing PRODUCT.DAT to shift the Alloy prereq "left" fixes the problem (the first FBL shows, and uses, one Alloy). This fix only affects new production jobs; current jobs are stored in BPROD.DAT. Also note that the source data for PRODUCT.DAT is stored in the .EXE; you'd have to edit the executable to permanently fix the bug. Or just consider it a tiny gift from the programmers - one Alloy saved for each FBL manufacturing job - and get back to work saving the world.

	'''14 (1 Byte):''' Item type manufactured. Indexes into BASE.DAT.		'''14 (1 Byte):''' Item type manufactured. Indexes into [[BASE.DAT]].

	'''15 (1 Byte):''' Unknown - always 1?		'''15 (1 Byte):''' Unknown - always 1?

	'''16 (1 Byte?):''' Build flag		'''16 (1 Byte?):''' Researched / Can Build flag. At the start of game, all values are set to 1.
	:* 0 - Can be built		:* 0 - Can be built
	:* 1 - Cannot be built (needs research)		:* 1 - Cannot be built (yet; needs research)

	'''17 (1 Byte):''' Unknown - always 0?		'''17 (1 Byte):''' Unknown - always 0?

Zombie: Again, added index of file item type draws from.

2008-05-15T01:16:41Z

Again, added index of file item type draws from.

← Older revision		Revision as of 01:16, 15 May 2008
Line 24:		Line 24:
	:Here we also see the possible cause of the [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers\|Fusion Ball Launcher]] (FBL) manufacturing "bug". The FBL does not require an Alien Alloy for the first FBL made (as shown on the Build screen), but subsequent FBLs made in the same batch run ''do'' require an Alloy. For the FBL (the first Product in the file), bytes 8-13 read: 255, 88, 255, 0, 1, 0. It is the '''only''' product that does not have all its prerequisites shifted to the left (i.e., byte 8 is never null if there is a prequisite, for everything but the FBL). Apparently the Build screen itself (and the first item made) is coded to stop looking for prerequisites as soon as it encounters a null one - but subsequently the manufacturing code ''does'' check all 3 prerequisite columns.		:Here we also see the possible cause of the [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers\|Fusion Ball Launcher]] (FBL) manufacturing "bug". The FBL does not require an Alien Alloy for the first FBL made (as shown on the Build screen), but subsequent FBLs made in the same batch run ''do'' require an Alloy. For the FBL (the first Product in the file), bytes 8-13 read: 255, 88, 255, 0, 1, 0. It is the '''only''' product that does not have all its prerequisites shifted to the left (i.e., byte 8 is never null if there is a prequisite, for everything but the FBL). Apparently the Build screen itself (and the first item made) is coded to stop looking for prerequisites as soon as it encounters a null one - but subsequently the manufacturing code ''does'' check all 3 prerequisite columns.

	'''14 (1 Byte):''' Item type manufactured. ~~''What set of numbers is this pointing to? Please insert if you know~~. ~~-RK''~~		'''14 (1 Byte):''' Item type manufactured. Indexes into BASE.DAT.

	'''15 (1 Byte):''' Unknown - always 1?		'''15 (1 Byte):''' Unknown - always 1?

Zombie: Added mention of file where prereqs index into.

2008-05-15T01:01:00Z

Added mention of file where prereqs index into.

← Older revision		Revision as of 01:01, 15 May 2008
Line 12:		Line 12:
	'''6-7 (2 Bytes):''' Work space needed (low byte, high byte). It's conjecture that Byte 7 is the high byte for Byte 6; it's always 0. No item comes close to needing 256 work spaces (36 is the max).		'''6-7 (2 Bytes):''' Work space needed (low byte, high byte). It's conjecture that Byte 7 is the high byte for Byte 6; it's always 0. No item comes close to needing 256 work spaces (36 is the max).

	'''8-13 (6 Bytes):''' An odd data-packing scheme to show manufacturing prerequisites. Bytes 8-10 show the prequisite; the matching Bytes 11-13 show how many are needed. Here, "matching" means whether it's the 1st, 2nd, or 3rd byte. Possible values for prerequisites (Bytes 8-10):		'''8-13 (6 Bytes):''' An odd data-packing scheme to show manufacturing prerequisites. Bytes 8-10 show the prequisite; the matching Bytes 11-13 show how many are needed. Here, "matching" means whether it's the 1st, 2nd, or 3rd byte. Possible values for prerequisites (Bytes 8-10) - indexes into [[BASE.DAT]]:
	:*60 = E115		:*60 = E115
	:*88 = Alloys		:*88 = Alloys

MikeTheRed: Thanks for the pointer on the Talk page, Tifi - I dug a little deeper, take a look

2008-05-14T22:10:28Z

Thanks for the pointer on the Talk page, Tifi - I dug a little deeper, take a look

← Older revision		Revision as of 22:10, 14 May 2008
Line 6:		Line 6:
	Each entry is 18 bytes long with 35 entries totaling 630 bytes. Values are presented according to byte offset (0 to 17).		Each entry is 18 bytes long with 35 entries totaling 630 bytes. Values are presented according to byte offset (0 to 17).

	'''0-3 (4 Bytes):''' ~~Unit price for~~ the item		'''0-3 (4 Bytes):''' Cost to manufacture item, in low-to-high byte format ([0] x 1, [1] x 256, [2] x 256<sup>2</sup>, [3] x 256<sup>3</sup>). This is the cost shown on the Build screen. Byte 3 is always 0; the most costly item requires 900k (256<sup>3</sup> = 16.8 million).

	'''4-5 (2 Bytes):''' Engineering Hours needed to complete 1 item		'''4-5 (2 Bytes):''' Engineering Hours needed to complete one item (low byte, high byte)

	'''6-7 (2 Bytes):''' Work space needed		'''6-7 (2 Bytes):''' Work space needed (low byte, high byte). It's conjecture that Byte 7 is the high byte for Byte 6; it's always 0. No item comes close to needing 256 work spaces (36 is the max).

	'''8-10 (~~1 Byte each~~):''' ~~Prerequisite item~~(s~~) needed~~. ~~Up to 3 types possible~~.		'''8-13 (6 Bytes):''' An odd data-packing scheme to show manufacturing prerequisites. Bytes 8-10 show the prequisite; the matching Bytes 11-13 show how many are needed. Here, "matching" means whether it's the 1st, 2nd, or 3rd byte. Possible values for prerequisites (Bytes 8-10):
			:*60 = E115
			:*88 = Alloys
			:*80 = Power Source
			:*81 = Navigation
			:*255 = null (no prereq)
			:For example, the Avenger's bytes 8-13 read: 88, 80, 81, 120, 2, 1. It needs 120 Alloys, 2 PSs, and 1 Nav.

	'''11-13 (~~1 Byte each~~)~~:''' Quantity~~ of ~~prerequisites needed~~. ~~Up to 3 types possible~~.		:This is an odd packing scheme because they used 6 bytes to show values for only 4 possible prerequisites. They could've just used 4 bytes, with each one specific to the four prereq types. Possibly they were originally thinking of having many more types of prequisites (but any one item could only have a max of 3 prerequisites). Perhaps e.g. TFTD has more prereqs. In any event, it's interesting inasmuch as it's a rare(?) example of X-COM packing data that should have been in an external list (per relational database rules) into its parent flat file. A somewhat similar example can be found with ammo requirements in bytes 25-28 of [[OBDATA.DAT]].

	'''14 (1 Byte):''' Item type manufactured.		:Here we also see the possible cause of the [[Manufacturing_Profitability#Laser_Cannons_vs._Fusion_Ball_Launchers\|Fusion Ball Launcher]] (FBL) manufacturing "bug". The FBL does not require an Alien Alloy for the first FBL made (as shown on the Build screen), but subsequent FBLs made in the same batch run ''do'' require an Alloy. For the FBL (the first Product in the file), bytes 8-13 read: 255, 88, 255, 0, 1, 0. It is the '''only''' product that does not have all its prerequisites shifted to the left (i.e., byte 8 is never null if there is a prequisite, for everything but the FBL). Apparently the Build screen itself (and the first item made) is coded to stop looking for prerequisites as soon as it encounters a null one - but subsequently the manufacturing code ''does'' check all 3 prerequisite columns.

			'''14 (1 Byte):''' Item type manufactured. ''What set of numbers is this pointing to? Please insert if you know. -RK''

			'''15 (1 Byte):''' Unknown - always 1?

	'''16 (1 Byte?):''' Build flag		'''16 (1 Byte?):''' Build flag
	** 0 - Can be built		:* 0 - Can be built
	** 1 - Cannot be built (needs research)		:* 1 - Cannot be built (needs research)

			'''17 (1 Byte):''' Unknown - always 0?

	==List of Entries==		==List of Entries==