Difference between revisions of "Talk:FA1C39F7"

From SimsWiki
Jump to: navigation, search
(→‎Notes: More notes.)
(Updated with the results of my latest research, plus I learned how to format tables.)
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 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`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 [[FA1C39F7|here]]. 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==
+
{| class="wikitable"
−
*16 Bytes: Unknown
+
! Anim blocks
−
*[[7BITSTR]]: Unknown
+
|-
−
*[[7BITSTR]]: Unknown; apparently always "obj" or "int"
+
| 16 Bytes || Unknown ||
−
*377 Bytes: Unknown, but some of the data patterns resemble CoOrdinate block data patterns.
+
|-
−
*[[7BITSTR]]: Unknown, but appears to always end in "_anim"
+
| [[7BITSTR]] || Unknown ||
−
*4 Bytes: Unknown, possibly DWORD?
+
|-
−
==Blend blocks==
+
| [[7BITSTR]] || Unknown || apparently always "", "int", "lat", "sim", "obj", "osl", "ovh", "ovl", or "ovm"
−
*[[7BITSTR]]: Name
+
|-
−
*[[7BITSTR]]: Partner
+
| 377 Bytes || Unknown || some of the data patterns resemble CoOrdinate block data patterns.
−
*DWORD: Unknown; apparently always 0x00000000 or 0x3F7FFFB2
+
|-
−
==CoOrdinates blocks==
+
| [[7BITSTR]] || Unknown || appears to always end in "_anim"
−
*FLOAT: X
+
|-
−
*FLOAT: Y
+
| DWORD || Unknown || always 0 or 1
−
*FLOAT: Height
+
|}
−
*16 Bytes: Quaternion [Does anyone know how to "read" one of these?]
+
{| class="wikitable"
−
==MaterialMesh blocks==
+
! Blend blocks
−
*[[7BITSTR]]: Material
+
|-
−
*[[7BITSTR]]: Mesh
+
| [[7BITSTR]] || Name
−
==Slot blocks==
+
|-
−
*[[7BITSTR]]: Name
+
| [[7BITSTR]] || Partner
−
*CoOrdinates block
+
|-
−
 
+
| DWORD || Unknown
 +
|}
 +
{| class="wikitable"
 +
! CoOrdinates blocks
 +
|-
 +
| FLOAT || X ||
 +
|-
 +
| FLOAT || Y ||
 +
|-
 +
| FLOAT || Height ||
 +
|-
 +
| 16 Bytes || Quaternion ||Does anyone know how to "read" one of these?
 +
|}
 +
{| class="wikitable"
 +
! MaterialMesh blocks
 +
|-
 +
| [[7BITSTR]] || Material
 +
|-
 +
| [[7BITSTR]] || Mesh
 +
|}
 +
{| class="wikitable"
 +
! 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.
 
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==
+
{| class="wikitable"
−
*[[7BITSTR]]: Unknown [Name?]
+
! cObjectBlock blocks
−
*DWORD: Unknown, only present for Version=17
+
|-
−
*DWORD: Count
+
| [[7BITSTR]] || Unknown || Name?
−
*MaterialMesh block: Repeat Count times
+
|-
−
 
+
| DWORD || Unknown ||
 +
* only present for cObject Version=17
 +
* always 3, 7, 8, 9, 10, or 12
 +
|-
 +
| 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?
 
I had to invent a name for these blocks, but was singularly uninspired at the time. Any suggestions?
−
==cObject blocks==
+
{| class="wikitable"
−
*[[7BITSTR]]: Model
+
! cObject blocks
−
*DWORD: Count
+
|-
−
*cObjectBlock block: Repeat Count times
+
| [[7BITSTR]] || Model ||
−
*CoOrdinates block
+
|-
−
*DWORD: Count
+
| DWORD || Count ||
−
*Slot block: Repeat Count times
+
|-
−
==cAnimatable blocks==
+
| cObjectBlock block || || Repeat Count times
−
*DWORD: BlockID; always the BlockID for cObject blocks
+
|-
−
*DWORD: Version of embedded cObject block
+
| CoOrdinates block || ||
−
*[[7BITSTR]]: Name; always "cObject", matching the BlockID
+
|-
−
*cObject block
+
| DWORD || Count ||
−
*DWORD: Count
+
|-
−
*Blend block: Repeat Count times
+
| Slot block || || Repeat Count times
−
*Float: Unknown; always 1.0
+
|}
−
*DWORD: Unknown; always 1
+
{| class="wikitable"
−
*CoOrdinates block: Occurs twice
+
! cAnimatable blocks
−
*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
+
| DWORD || BlockID || always the BlockID for cObject blocks
−
==cLocomotable blocks==
+
|-
−
*DWORD: BlockID; always the BlockID for cAnimatable blocks
+
| DWORD || Version || of embedded cObject block
−
*DWORD: Version of embedded cAnimatable block
+
|-
−
*cAnimatable block
+
| [[7BITSTR]] || Name || always "cObject", matching the BlockID
−
==cPerson blocks==
+
|-
−
*DWORD: BlockID; always the BlockID for cLocomotable blocks
+
| cObject block || ||
−
*DWORD: Version of embedded cLocomotable block
+
|-
−
[[7BITSTR]]: Name; always "cLocomotable"
+
| DWORD || Count ||
−
==Full Record==
+
|-
−
*64 BYTEs: Unknown, always zeroes
+
| Blend block || || Repeat Count times
−
*DWORD: BlockID
+
|-
−
*DWORD: Version
+
| Float || Unknown || nearly always 1.0, but values as low as 0.939999997616 have been seen
−
*[[7BITSTR]]: Name; always matches BlockID
+
|-
−
*cObject block: Only if BlockID matches cObject BlockID
+
| DWORD || Unknown || always 1
−
*cAnimatable block: Only if Block ID matches cAnimatable BlockID
+
|-
−
*cPerson block: Only if BlockID matches cPerson BlockID
+
| CoOrdinates block || || Occurs twice
−
*DWORD: Unknown, apparently always 0x00000000 or 0x00FE0000
+
|-
 +
| || Unknown ||
 +
* 24 bytes long for Version<16
 +
* 28 bytes long 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 || ||
 +
|}
 +
{| class="wikitable"
 +
! cLocomotable blocks
 +
|-
 +
| DWORD || BlockID || always the BlockID for cAnimatable blocks
 +
|-
 +
| DWORD || Version || of embedded cAnimatable block
 +
|-
 +
| cAnimatable block || ||
 +
|}
 +
{| class="wikitable"
 +
! cPerson blocks
 +
|-
 +
| DWORD || BlockID || always the BlockID for cLocomotable blocks
 +
|-
 +
| DWORD || Version || of embedded cLocomotable block
 +
|-
 +
| [[7BITSTR]] || Name || always "cLocomotable"
 +
|-
 +
| DWORD? || Unknown || always 0, 1, or 2?
 +
|-
 +
| DWORD? || Unknown || always 0 or 1?
 +
|}
 +
{| class="wikitable"
 +
! Full Record
 +
|-
 +
| 64 Bytes || Unknown || always zeroes
 +
|-
 +
| DWORD || BlockID ||
 +
|-
 +
| DWORD || Version || of outermost block
 +
|-
 +
| [[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
 +
|-
 +
|  || || See Notes
 +
|-
 +
| 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 cPerson blocks also contain [or are always followed by] cLocomotable blocks, which contain [or are always followed by] cAnimatable blocks.
 
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 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.
+
When the main block is a cAnmatable block, and the next DWORD is neither 0x00000000 nor 0x00FE0000, and the remaining data is more than a few DWORDS long, a counted group of Anim blocks appears; its presence bears no relation to the version number of any known part of the record. I am still engaged in verifying that this "rule" holds true for all lots in all EAxis neighborhoods in my game, none of which has ever been played.
  
−
As part of that further investigation, I have used my tool to test-read EVERY lot in neighborhoods E001 and F001, neither of which has EVER been played, and begun scanning the lots in neighborhoods G001, N001, and N002, none of which has ever been played, and still have troubles with the data where the Anim block resides. At least one cPerson record has a Anim-block count of 3, followed by TWO Anim blocks and something that clearly is NOT an Anim block. Several other files have one or more of these non-Anim blocks at the end of one or more cPerson records, but so far I have only found the one record with such within the *counted* Anim blocks.
+
As part of my ongoing investigation, I have used my tool to test-read every lot in neighborhoods E001 and F001 and begun scanning the lots in neighborhoods G001, N001, and N002, and still have some troubles with the data where the Anim block resides. As of the last scan of the file it resides in, at least one cPerson record had a Anim-block count of 3, followed by TWO Anim blocks and something that clearly is NOT an Anim block. Several other files have one or more of these non-Anim blocks at the end of one or more cPerson records, but so far I have only found the one record with such within the *counted* Anim blocks.
  
 
I still don`t know how to identify the presence of the Anim blocks by any way other than checking for the length of the unused data at the end of the record, but that method had proven absolutely reliable until that one abberant record was found. Incidentally, the record in question is Neighborhoods\G001\Lots\G001_Lot23.package, TypeID=0xFA1C39F7, GroupID=4294967295, InstanceID=218. --GeneralOperationsDirector
 
I still don`t know how to identify the presence of the Anim blocks by any way other than checking for the length of the unused data at the end of the record, but that method had proven absolutely reliable until that one abberant record was found. Incidentally, the record in question is Neighborhoods\G001\Lots\G001_Lot23.package, TypeID=0xFA1C39F7, GroupID=4294967295, InstanceID=218. --GeneralOperationsDirector

Revision as of 05:56, 15 October 2010

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 here. 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 "", "int", "lat", "sim", "obj", "osl", "ovh", "ovl", or "ovm"
377 Bytes Unknown some of the data patterns resemble CoOrdinate block data patterns.
7BITSTR Unknown appears to always end in "_anim"
DWORD Unknown always 0 or 1
Blend blocks
7BITSTR Name
7BITSTR Partner
DWORD Unknown
CoOrdinates blocks
FLOAT X
FLOAT Y
FLOAT Height
16 Bytes Quaternion Does anyone know how to "read" one of these?
MaterialMesh blocks
7BITSTR Material
7BITSTR Mesh
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 cObject Version=17
  • always 3, 7, 8, 9, 10, or 12
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 nearly always 1.0, but values as low as 0.939999997616 have been seen
DWORD Unknown always 1
CoOrdinates block Occurs twice
Unknown
  • 24 bytes long for Version<16
  • 28 bytes long 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"
DWORD? Unknown always 0, 1, or 2?
DWORD? Unknown always 0 or 1?
Full Record
64 Bytes Unknown always zeroes
DWORD BlockID
DWORD Version of outermost block
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
See Notes
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 cLocomotable blocks seem to be singularly useless, apparently adding no significant information to the record.

When the main block is a cAnmatable block, and the next DWORD is neither 0x00000000 nor 0x00FE0000, and the remaining data is more than a few DWORDS long, a counted group of Anim blocks appears; its presence bears no relation to the version number of any known part of the record. I am still engaged in verifying that this "rule" holds true for all lots in all EAxis neighborhoods in my game, none of which has ever been played.

As part of my ongoing investigation, I have used my tool to test-read every lot in neighborhoods E001 and F001 and begun scanning the lots in neighborhoods G001, N001, and N002, and still have some troubles with the data where the Anim block resides. As of the last scan of the file it resides in, at least one cPerson record had a Anim-block count of 3, followed by TWO Anim blocks and something that clearly is NOT an Anim block. Several other files have one or more of these non-Anim blocks at the end of one or more cPerson records, but so far I have only found the one record with such within the *counted* Anim blocks.

I still don`t know how to identify the presence of the Anim blocks by any way other than checking for the length of the unused data at the end of the record, but that method had proven absolutely reliable until that one abberant record was found. Incidentally, the record in question is Neighborhoods\G001\Lots\G001_Lot23.package, TypeID=0xFA1C39F7, GroupID=4294967295, InstanceID=218. --GeneralOperationsDirector

Retrieved from "http://simswiki.info/index.php?title=Talk:FA1C39F7&oldid=47682"
Personal tools
Namespaces

Variants
Actions
Navigation
game select
Toolbox