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 [Please?], 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 CoOrdinates block data patterns
|
| 7BITSTR |
Unknown |
if not empty, always ends in "_anim"
|
| DWORD |
Unknown |
always 0 or 1
|
| CoOrdinates blocks
|
| FLOAT |
X |
|
| FLOAT |
Y |
|
| FLOAT |
Height |
|
| 16 Bytes |
Quaternion |
Does anyone know how to "read" one of these?
|
| 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"
|
| cLocomotable block |
|
|
| 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
|
| Additional data |
Unknown |
See Notes
|
Notes
After the main block, additional data occurs that varies with the type and version of the outermost block, but which does NOT appear after a block of the same type and version within another block.
- When the main block is a cObject block of version 16, it is sometimes followed by a single additional DWORD.
- When the main block is a cObject block of version 17, it is followed by one of the following:
- A single DWORD, always 0x00FE0000.
- A DWORD Count with Count additional DWORDs.
- If either is present, it marks the END of the record; any other data present will be in place of, rather than in addition to, this data.
-
- Other versions of cObject blocks have not been seen.
- When the main block is a cAnimatable block of version 16, it is always followed by one of the following, all of which mark the end of the record:
- Nothing at all.
- A single DWORD, always either 0x00FE0000 or 0xFD000000.
- A DWORD Count with Count additional DWORDs.
- A DWORD Count with Count Anim blocks.
- When the main block is a cAnimatable block of version 17, it is always followed by one additional DWORD, always 0x00000000.
- When the main block is a cAnimatable block of version 14, the format is unknown.
-
- Other versions of cAnimatable blocks have not been seen. At this time, it appears that version 14 blocks never occur as the main block, as this should cause my tool to raise an exception that has not occured. As well, the existance of version 17 blocks needs to be verified.
- cPerson and cLocomotable blocks.
- Because of the way that cPerson and cLocomotable blocks always occur only with a single instance of the other, it is impossible to determine if any data present belongs to the cPerson block or the cLocomotable block. At any rate, the cLocomotable block`s embedded cAnimatable block has been observed to be followed by any of the following:
- A single DWORD, always 0x00FE0000. Always marks the end of the record.
- Two DWORDs, both always 0x00000000. Always marks the end of the record.
- A DWORD Count with Count additional DWORDs. Always marks the end of the record.
- A DWORD Count with Count Anim blocks, optionally followed by:
- Two DWORDs, both always 0x00000000. Always marks the end of the record.
- A DWORD Count with Count additional DWORDs. Always marks the end of the record.
-
- Other data may follow the Anim blocks, or appear in place of them, but this data has proven very resistant to analysis.
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, N002, and N003, and still have some troubles with the data following the cLocomotable`s embedded cAnimatable block. 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. The record in question is Neighborhoods\G001\Lots\G001_Lot23.package, TypeID=0xFA1C39F7, GroupID=4294967295, InstanceID=218. Several other files have what appears to be 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, and has proven reilable for all other records observed to date. --GeneralOperationsDirector
