Talk:GFF - Revision history

Mephales: /* GFF V4.1 */ new section

2011-02-28T04:20:10Z

‎GFF V4.1: new section

Eshme: /* Field information incorrect */

2010-03-15T22:51:28Z

‎Field information incorrect

Eshme: /* Field information incorrect */

2010-03-15T07:25:55Z

‎Field information incorrect

Eshme: /* Field information incorrect */

2010-03-15T07:25:47Z

‎Field information incorrect

FollowTheGourd at 06:56, 26 January 2010

2010-01-26T06:56:57Z

Overture1943: wrt Field info

2009-11-06T19:22:46Z

wrt Field info

Overture1943: Created page with 'Can anyone confirm whether the Field's type flags are as stated or if perhaps the bits are swapped? Based on my tests with the GFF used for save game files (.das), bit 3 is set ...'

2009-11-06T15:50:23Z

Created page with 'Can anyone confirm whether the Field's type flags are as stated or if perhaps the bits are swapped? Based on my tests with the GFF used for save game files (.das), bit 3 is set ...'

New page

Can anyone confirm whether the Field's type flags are as stated or if perhaps the bits are swapped? Based on my tests with the GFF used for save game files (.das), bit 3 is set for a number of things that are sensibly structs and bit 2 was set for things that supposedly *must* be references (eg have type 65535) -- overture1943

← Older revision		Revision as of 04:20, 28 February 2011
Line 27:		Line 27:
	:With which if only Bit3 is set, then the Data isnt referenced, but a struct is referenced ,and it is not a list or so it seems to me. [[User:Eshme\|Eshme]] 07:25, 15 March 2010 (UTC)		:With which if only Bit3 is set, then the Data isnt referenced, but a struct is referenced ,and it is not a list or so it seems to me. [[User:Eshme\|Eshme]] 07:25, 15 March 2010 (UTC)
	::This appears true in GAD files as well, solely Bit1 is set for a Float32 list. [[User:Eshme\|Eshme]] 22:51, 15 March 2010 (UTC)		::This appears true in GAD files as well, solely Bit1 is set for a Float32 list. [[User:Eshme\|Eshme]] 22:51, 15 March 2010 (UTC)
		+
		+	== GFF V4.1 ==
		+
		+	Due to the new ERF V3.0 format, we don't have a lot to go on for the new GFF V4.1 format. The only example I know of is profile.dap. However, here are my thoughts. The header has two additional uint32 fields, giving us:
		+	<pre>struct header {
		+	char[8] magic = "GFF V4.1";
		+	char[4] platform;
		+	char[4] file_type;
		+	char[4] file_version;
		+	uint32 struct_count;
		+	uint32 unknown_1;
		+	uint32 string_offset;
		+	uint32 data_offset;
		+	}</pre>
		+	I haven't figured out what the first new field is, but the field I call string_offset appears to be an offset from the beginning of the file to a new list of zero-terminated strings, just like the ERF V3.0 format has for filenames. And as a result of this, it appears that ECStrings are now represented as offsets into this string section. They also do not start with the length of the string, and it appears the strings are most probably encoded in utf-8, but definitely not in utf-16 anymore.
		+
		+	I had an alternate theory that involved the the strings still being part of the data section and the root structure being able to start later in the data section, but the offsets for lists are still relative to the root structure's start, so they appear to be different sections.
		+
		+	I imagine there will be a few more surprises in store for us beyond these, like what the purpose of the first new field is, but it looks like we need to puzzle out the ERF V3.0 format or wait for a toolset so we can get more GFF V4.1 samples. [[User:Mephales\|Mephales]] 04:20, 28 February 2011 (UTC)

← Older revision		Revision as of 22:51, 15 March 2010
Line 26:		Line 26:
	:I say this is not easy, however i think the original was correct. I dont have big explanation at hand, the Bonesused List in MMH for example has Bit 1 set. The "Generic List" has Bit 1 and 3 set (Where with Bit3 Data contains a Struct reference). And lastly "Struct List" has Bit 1 and 2 set. (Where with bit2 the Data contains the Struct itself) All of them data are referenced in itself, however i think that is a given for Lists.		:I say this is not easy, however i think the original was correct. I dont have big explanation at hand, the Bonesused List in MMH for example has Bit 1 set. The "Generic List" has Bit 1 and 3 set (Where with Bit3 Data contains a Struct reference). And lastly "Struct List" has Bit 1 and 2 set. (Where with bit2 the Data contains the Struct itself) All of them data are referenced in itself, however i think that is a given for Lists.
	:With which if only Bit3 is set, then the Data isnt referenced, but a struct is referenced ,and it is not a list or so it seems to me. [[User:Eshme\|Eshme]] 07:25, 15 March 2010 (UTC)		:With which if only Bit3 is set, then the Data isnt referenced, but a struct is referenced ,and it is not a list or so it seems to me. [[User:Eshme\|Eshme]] 07:25, 15 March 2010 (UTC)
		+	::This appears true in GAD files as well, solely Bit1 is set for a Float32 list. [[User:Eshme\|Eshme]] 22:51, 15 March 2010 (UTC)

← Older revision		Revision as of 07:25, 15 March 2010
Line 25:		Line 25:

	:I say this is not easy, however i think the original was correct. I dont have big explanation at hand, the Bonesused List in MMH for example has Bit 1 set. The "Generic List" has Bit 1 and 3 set (Where with Bit3 Data contains a Struct reference). And lastly "Struct List" has Bit 1 and 2 set. (Where with bit2 the Data contains the Struct itself) All of them data are referenced in itself, however i think that is a given for Lists.		:I say this is not easy, however i think the original was correct. I dont have big explanation at hand, the Bonesused List in MMH for example has Bit 1 set. The "Generic List" has Bit 1 and 3 set (Where with Bit3 Data contains a Struct reference). And lastly "Struct List" has Bit 1 and 2 set. (Where with bit2 the Data contains the Struct itself) All of them data are referenced in itself, however i think that is a given for Lists.
−	With which if only Bit3 is set, then the Data isnt referenced, but a struct is referenced ,and it is not a list or so it seems to me. [[User:Eshme\|Eshme]] 07:25, 15 March 2010 (UTC)	+	:With which if only Bit3 is set, then the Data isnt referenced, but a struct is referenced ,and it is not a list or so it seems to me. [[User:Eshme\|Eshme]] 07:25, 15 March 2010 (UTC)

← Older revision		Revision as of 07:25, 15 March 2010
Line 23:		Line 23:

	--[[User:Overture1943\|Overture1943]] 19:22, 6 November 2009 (UTC)		--[[User:Overture1943\|Overture1943]] 19:22, 6 November 2009 (UTC)
		+
		+	:I say this is not easy, however i think the original was correct. I dont have big explanation at hand, the Bonesused List in MMH for example has Bit 1 set. The "Generic List" has Bit 1 and 3 set (Where with Bit3 Data contains a Struct reference). And lastly "Struct List" has Bit 1 and 2 set. (Where with bit2 the Data contains the Struct itself) All of them data are referenced in itself, however i think that is a given for Lists.
		+	With which if only Bit3 is set, then the Data isnt referenced, but a struct is referenced ,and it is not a list or so it seems to me. [[User:Eshme\|Eshme]] 07:25, 15 March 2010 (UTC)

← Older revision		Revision as of 06:56, 26 January 2010
Line 1:		Line 1:
		+	Here's some more info on it for consideration. As is, the wiki article leaves you to guess at a lot of what's going on. Listing it here for now so I don't lose track of it.
		+	* http://social.bioware.com/forum/1/topic/8/index/464166
		+	* http://social.bioware.com/forum/1/topic/72/index/508109
		+	--[[User:FollowTheGourd\|FollowTheGourd]] 06:56, 26 January 2010 (UTC)
		+
		+	----
	== Field information incorrect ==		== Field information incorrect ==
	After checking a .das file with the GFF editor that comes with the toolset, it would appear that FieldType is TypeID then flags. Also the flags are Reference (MSB, bit 16), List (bit 15), and Struct (bit 14).		After checking a .das file with the GFF editor that comes with the toolset, it would appear that FieldType is TypeID then flags. Also the flags are Reference (MSB, bit 16), List (bit 15), and Struct (bit 14).

← Older revision		Revision as of 19:22, 6 November 2009
Line 1:		Line 1:
−	~~Can anyone confirm whether the~~ Field~~'s type flags are as stated or if perhaps the bits are swapped? Based on my tests~~ with the GFF ~~used for save game files (~~.~~das~~), bit ~~3 is set for a number of things that are sensibly structs~~ and bit 2 was set for things that supposedly must be ~~references~~ (~~eg have~~ type ~~65535~~) -- ~~overture1943~~	+	== Field information incorrect ==
		+	After checking a .das file with the GFF editor that comes with the toolset, it would appear that FieldType is TypeID then flags. Also the flags are Reference (MSB, bit 16), List (bit 15), and Struct (bit 14).
		+
		+	This can be verified with:
		+
		+	<pre>
		+	# let data be an array of the gff file
		+	# let offset be the start of a field in the field array
		+	(id, type, flags, index) = unpack("I H H I),data[offset:offset+12])
		+
		+	isList = (flags & (1 << 15) >0)
		+	isStruct = (flags & (1 << 14) >0)
		+	isRef = (flags & (1 << 16) >0)
		+	</pre>
		+
		+	Given this, I'm going to change the page. If I'm incorrect, feel free to revert and explain why here.
		+
		+	--[[User:Overture1943\|Overture1943]] 19:22, 6 November 2009 (UTC)