Difference between revisions of "Talk:FA1C39F7"
(I know more now, so I updated my description and commentary to match.) |
(Updated with the results of additional research.) |
||
| 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 | + | 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 nearly all 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: | ||
| + | ==Anim blocks== | ||
| + | *16 Bytes: Unknown | ||
| + | *[[7BITSTR]]: Unknown | ||
| + | *[[7BITSTR]]: Unknown; apparently always "obj" or "int" | ||
| + | *377 Bytes: Unknown, but some of the data patterns resemble CoOrdinate block data patterns. | ||
| + | *[[7BITSTR]]: Unknown, but appears to always end in "_anim" | ||
| + | *4 Bytes: Unknown, possibly DWORD? | ||
==Blend blocks== | ==Blend blocks== | ||
*[[7BITSTR]]: Name | *[[7BITSTR]]: Name | ||
*[[7BITSTR]]: Partner | *[[7BITSTR]]: Partner | ||
| − | *DWORD: Unknown | + | *DWORD: Unknown; apparently always 0x00000000 or 0x3F7FFFB2 |
| − | + | ||
| − | + | ||
| − | + | ||
==CoOrdinates blocks== | ==CoOrdinates blocks== | ||
*FLOAT: X | *FLOAT: X | ||
*FLOAT: Y | *FLOAT: Y | ||
*FLOAT: Height | *FLOAT: Height | ||
| − | *16 Bytes: Quaternion | + | *16 Bytes: Quaternion [Does anyone know how to "read" one of these?] |
| + | ==MaterialMesh blocks== | ||
| + | *[[7BITSTR]]: Material | ||
| + | *[[7BITSTR]]: Mesh | ||
==Slot blocks== | ==Slot blocks== | ||
*[[7BITSTR]]: Name | *[[7BITSTR]]: Name | ||
*CoOrdinates block | *CoOrdinates block | ||
| − | I call these blocks "Slot" blocks because some of the "Name" | + | I call these blocks "Slot" blocks because some of the "Name" fields actually have the word "slot" as part of their value, and because the co-ordinates they contain often [if not always] make perfect sense as the object-relative locations of the object features mentioned in the correspoding "Name" field. |
==cObjectBlock blocks== | ==cObjectBlock blocks== | ||
*[[7BITSTR]]: Unknown [Name?] | *[[7BITSTR]]: Unknown [Name?] | ||
| Line 41: | Line 48: | ||
*DWORD: Count | *DWORD: Count | ||
*Blend block: Repeat Count times | *Blend block: Repeat Count times | ||
| − | *Float: Unknown | + | *Float: Unknown; always 1.0 |
| − | *DWORD: Unknown | + | *DWORD: Unknown; always 1 |
*CoOrdinates block: Occurs twice | *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" | *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 | ||
| − | + | ==cLocomotable blocks== | |
| − | + | *DWORD: BlockID; always the BlockID for cAnimatable blocks | |
| + | *DWORD: Version of embedded cAnimatable block | ||
| + | *cAnimatable block | ||
| + | ==cPerson blocks== | ||
| + | *DWORD: BlockID; always the BlockID for cLocomotable blocks | ||
| + | *DWORD: Version of embedded cLocomotable block | ||
| + | [[7BITSTR]]: Name; always "cLocomotable" | ||
==Full Record== | ==Full Record== | ||
*64 BYTEs: Unknown, always zeroes | *64 BYTEs: Unknown, always zeroes | ||
| Line 58: | Line 71: | ||
*DWORD: Unknown, apparently always 0x00000000 or 0x00FE0000 | *DWORD: Unknown, apparently always 0x00000000 or 0x00FE0000 | ||
==Notes== | ==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 | + | 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 the cPerson blocks also contain [or are always followed by] cLocomotable blocks, which contain [or are always followed by] cAnimatable blocks. |
| + | |||
| + | The cPerson and cLocomotable blocks seem to be singularly useless, apparently adding no significant information to the record. | ||
| + | |||
| + | The Anim block described on the main page has been observed sporadicaly, with no reliable means of programaticaly identifying their presence observed. In particular, its presence seems to bear no relation to the version number of any known part of the record. Further investigation is underway. --GeneralOperationsDirector | ||
Revision as of 03:29, 14 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 nearly all 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:
Anim blocks
- 16 Bytes: Unknown
- 7BITSTR: Unknown
- 7BITSTR: Unknown; apparently always "obj" or "int"
- 377 Bytes: Unknown, but some of the data patterns resemble CoOrdinate block data patterns.
- 7BITSTR: Unknown, but appears to always end in "_anim"
- 4 Bytes: Unknown, possibly DWORD?
Blend blocks
CoOrdinates blocks
- FLOAT: X
- FLOAT: Y
- FLOAT: Height
- 16 Bytes: Quaternion [Does anyone know how to "read" one of these?]
MaterialMesh blocks
Slot blocks
- 7BITSTR: Name
- CoOrdinates block
I call these blocks "Slot" blocks because some of the "Name" fields actually have the word "slot" as part of their value, and because the co-ordinates they contain often [if not always] make perfect sense as the object-relative locations of the object features mentioned in the correspoding "Name" field.
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
cLocomotable blocks
- DWORD: BlockID; always the BlockID for cAnimatable blocks
- DWORD: Version of embedded cAnimatable block
- cAnimatable block
cPerson blocks
- DWORD: BlockID; always the BlockID for cLocomotable blocks
- DWORD: Version of embedded cLocomotable block
7BITSTR: Name; always "cLocomotable"
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 the cPerson blocks also contain [or are always followed by] cLocomotable blocks, which contain [or are always followed by] cAnimatable blocks.
The cPerson and cLocomotable blocks seem to be singularly useless, apparently adding no significant information to the record.
The Anim block described on the main page has been observed sporadicaly, with no reliable means of programaticaly identifying their presence observed. In particular, its presence seems to bear no relation to the version number of any known part of the record. Further investigation is underway. --GeneralOperationsDirector
