Difference between revisions of "Talk:FA1C39F7"

From SimsWiki
Jump to: navigation, search
(Discussion of my efforts to parse this record format.)
 
(I know more now, so I updated my description and commentary to match.)
Line 1: Line 1:
 
==Say What?==
 
==Say What?==
I`ve been investigating this record format because it is one of the most numerous formats in a lot file that I believe is corrupted. Unfortunately, I have been having some difficulty with the record format as described. Still, I have been able to decode *some* of it. However, as near as I can determine, given that I do not fully understand the format description, the data I am seeing appears to be formatted somewhat differently. In the hope that someone can help me, and that my experience might help others, and not wanting to mess up the existing description, I`m documenting my observations here. Obviously, I am still working on this record at the time of writing.
+
I`ve been investigating this record format because it is one of the most numerous formats in a lot file that I believe is corrupted. Unfortunately, I have been having some difficulty with the record format as described. Still, I have been able to decode *most* of it. However, as my understanding of the record format has improved, I have discovered that the data I am seeing does not quite match the description. In the hope that someone could help me, and that my experience might help others, and not wanting to mess up the existing description with my misunderstandings, I documented my observations here. Even though my understanding of the format has improved considerably since originaly posting this commentary, and I have updated my description to match, I am still working on this record at the time of writing.
  
 
I start with some relatively simple structures that occur a variable number of times in the record, and build my way up towards the full description:
 
I start with some relatively simple structures that occur a variable number of times in the record, and build my way up towards the full description:
Line 18: Line 18:
 
*[[7BITSTR]]: Name
 
*[[7BITSTR]]: Name
 
*CoOrdinates block
 
*CoOrdinates block
 +
 +
I call these blocks "Slot" blocks because some of the "Name" entries actually have the word "slot" as part of their value.
 
==cObjectBlock blocks==
 
==cObjectBlock blocks==
 
*[[7BITSTR]]: Unknown [Name?]
 
*[[7BITSTR]]: Unknown [Name?]
Line 23: Line 25:
 
*DWORD: Count
 
*DWORD: Count
 
*MaterialMesh block: Repeat Count times
 
*MaterialMesh block: Repeat Count times
 +
 +
I had to invent a name for these blocks, but was singularly uninspired at the time. Any suggestions?
 
==cObject blocks==
 
==cObject blocks==
 
*[[7BITSTR]]: Model
 
*[[7BITSTR]]: Model
Line 30: Line 34:
 
*DWORD: Count
 
*DWORD: Count
 
*Slot block: Repeat Count times
 
*Slot block: Repeat Count times
 
Additional data is present, occasionaly including a counted list of Blend blocks, and sometimes as small as one DWORD. I do not yet know how to determine programaticaly which appears when, nor do I know what the remainder of that data represents.
 
 
==cAnimatable blocks==
 
==cAnimatable blocks==
*DWORD: BlockID
+
*DWORD: BlockID; always the BlockID for cObject blocks
*DWORD: Unknown (Version?)
+
*DWORD: Version of embedded cObject block
*[[7BITSTR]]: Name? Unverified, but appears to always match BlockID
+
*[[7BITSTR]]: Name; always "cObject", matching the BlockID
*[[7BITSTR]]: Unknown (Model?)
+
*cObject block
*DWORD: Unknown
+
*[[7BITSTR]]: Unknown (Mesh? Material?)
+
 
+
The remaining data described here is apparently not present when Version=15
+
 
+
*DWORD: Unkown
+
 
*DWORD: Count
 
*DWORD: Count
*MaterialMesh block: Repeat Count times
+
*Blend block: Repeat Count times
 +
*Float: Unknown, always 1.0
 +
*DWORD: Unknown, always 1
 +
*CoOrdinates block: Occurs twice
 +
*Unknown, 24 bytes long for Version<16, 28 bytes for Version>15; apparently cannot be a CoOrdinates block, not only because of the size, but because some values decode into "Not A Number"
 
*CoOrdinates block
 
*CoOrdinates block
*DWORD: Count
 
*Slot block: repeat Count times
 
*DWORD: Count
 
*Blend block: repeat Count times
 
  
Additional data is present, occasionaly containing [[7BITSTR]]s. I do not yet know how to determine programaticaly what appears when, nor do I know what the remainder of that data represents.
+
The Anim block described on the main page has not been seen for Version<17, but no blocks Version>16 have been observed yet either.
 
==Full Record==
 
==Full Record==
 
*64 BYTEs: Unknown, always zeroes
 
*64 BYTEs: Unknown, always zeroes
Line 60: Line 56:
 
*cAnimatable block: Only if Block ID matches cAnimatable BlockID
 
*cAnimatable block: Only if Block ID matches cAnimatable BlockID
 
*cPerson block: Only if BlockID matches cPerson BlockID
 
*cPerson block: Only if BlockID matches cPerson BlockID
 +
*DWORD: Unknown, apparently always 0x00000000 or 0x00FE0000
 
==Notes==
 
==Notes==
The inexplicably-varying portions of the record are suspected to depend on the fields labeled "(Version?)", but this has yet to be investigated. It seems possible that the cPerson blocks may actualy *contain* cAnimatable blocks, and that cAnimatable blocks may actualy *contain* cObject blocks, but I have been unable to verify this yet, due to the presence of still-unknown data in those blocks. At this time, I have not yet attempted to analyse the cPerson blocks. --GeneralOperationsDirector
+
The formerly inexplicably-varying portions of the record suspected to depend on the fields labeled "(Version?)" [as reported in the first version of this page] has been confirmed: the cAnimatable blocks actualy *do* contain cObject blocks, and it seems highly probable that the cPerson blocks also contain cAnimatable blocks. At this time, however, I have not yet attempted to analyse the cPerson blocks. --GeneralOperationsDirector

Revision as of 02:36, 13 October 2010

Contents

Say What?

I`ve been investigating this record format because it is one of the most numerous formats in a lot file that I believe is corrupted. Unfortunately, I have been having some difficulty with the record format as described. Still, I have been able to decode *most* of it. However, as my understanding of the record format has improved, I have discovered that the data I am seeing does not quite match the description. In the hope that someone could help me, and that my experience might help others, and not wanting to mess up the existing description with my misunderstandings, I documented my observations here. Even though my understanding of the format has improved considerably since originaly posting this commentary, and I have updated my description to match, I am still working on this record at the time of writing.

I start with some relatively simple structures that occur a variable number of times in the record, and build my way up towards the full description:

Blend blocks

MaterialMesh blocks

CoOrdinates blocks

  • FLOAT: X
  • FLOAT: Y
  • FLOAT: Height
  • 16 Bytes: Quaternion

Slot blocks

I call these blocks "Slot" blocks because some of the "Name" entries actually have the word "slot" as part of their value.

cObjectBlock blocks

  • 7BITSTR: Unknown [Name?]
  • DWORD: Unknown, only present for Version=17
  • DWORD: Count
  • MaterialMesh block: Repeat Count times

I had to invent a name for these blocks, but was singularly uninspired at the time. Any suggestions?

cObject blocks

  • 7BITSTR: Model
  • DWORD: Count
  • cObjectBlock block: Repeat Count times
  • CoOrdinates block
  • DWORD: Count
  • Slot block: Repeat Count times

cAnimatable blocks

  • DWORD: BlockID; always the BlockID for cObject blocks
  • DWORD: Version of embedded cObject block
  • 7BITSTR: Name; always "cObject", matching the BlockID
  • cObject block
  • DWORD: Count
  • Blend block: Repeat Count times
  • Float: Unknown, always 1.0
  • DWORD: Unknown, always 1
  • CoOrdinates block: Occurs twice
  • Unknown, 24 bytes long for Version<16, 28 bytes for Version>15; apparently cannot be a CoOrdinates block, not only because of the size, but because some values decode into "Not A Number"
  • CoOrdinates block

The Anim block described on the main page has not been seen for Version<17, but no blocks Version>16 have been observed yet either.

Full Record

  • 64 BYTEs: Unknown, always zeroes
  • DWORD: BlockID
  • DWORD: Version
  • 7BITSTR: Name; always matches BlockID
  • cObject block: Only if BlockID matches cObject BlockID
  • cAnimatable block: Only if Block ID matches cAnimatable BlockID
  • cPerson block: Only if BlockID matches cPerson BlockID
  • DWORD: Unknown, apparently always 0x00000000 or 0x00FE0000

Notes

The formerly inexplicably-varying portions of the record suspected to depend on the fields labeled "(Version?)" [as reported in the first version of this page] has been confirmed: the cAnimatable blocks actualy *do* contain cObject blocks, and it seems highly probable that the cPerson blocks also contain cAnimatable blocks. At this time, however, I have not yet attempted to analyse the cPerson blocks. --GeneralOperationsDirector

Personal tools
Namespaces

Variants
Actions
Navigation
game select
Toolbox