Sims 3:0x046A7235
From SimsWiki
The data in this resource seems to be used for route planning, as there is a heavy emphasis on portals and footprints.
Contents |
Header
DWORD version 5 DWORD 2 DWORD 7 DWORD section 1 size -- Section 1 data -- Section 2 data DWORD section 3 size DWORD section 4 size -- Section 3 data -- Section 4 data -- Section 5 data
Section 1
DWORD section 2 size
QWORD lot ID
WORD
WORD
DWORD total subcount2b entries
DWORD id18 count (Number of type 18 special IDs)
4 DWORDs
3 BYTEs
MATRIX4x4 lot to world transformation
MATRIX4x4 world to lot transformation
DWORD 3
QWORD lot ID (Again)
QWORD lot ID (Again)
FLOAT (Usually -0.5 or 1.0)
FLOAT 0.0
FLOAT 0.123
DWORD (Typically 0x4000000 or 0x84000000)
4 FLOATS lot coordinate bounds (-0.5 to lot size + 0.5)
DWORD count1
REP count1
DWORD incrementing values from 1 to count1
DWORD count2
REP count2
DWORD subcount2a
REP subcount2a
DWORD value from count1 entries
DWORD subcount2b
REP subcount2b
DWORD value from count1 entries not included in subcount2a
DWORD subcount2c
REP subcount2c
WORD first value 0, rest value from subcount2a
DWORD subcount2d
REP subcount2d
DWORD subcount2d1
REP subcount2d1
WORD index into subcount2a entries
SINGLE (1.0)
BYTE 1
DWORD count3
REP count3
WORD
BYTE
BYTE
BYTE
DWORD count4
REP count4
WORD
WORD
WORD
WORD
Section 2
DWORD
DWORD s2entries
REP s3entries
DWORD
QWORD id (Object ID or special id)
DWORD
2 FLOATS
DWORD
2 FLOATS
DWORD
2 FLOATS
DWORD portal type (47144 = route through, 45250 = animate through)
DWORD
DWORD
DWORD portal type (47144 = route through, 45250 = animate through)
DWORD
WORD
WORD
DWORD
WORD
DWORD
FLOAT
FLOAT
Section 3
Speculation: Table of some sort used by route planning. Doing anything on a lot (Even changing the level of the terrain) causes this data to grow drastically.
DWORD s3entries
REP s3entries
4 DWORDS
DWORD s3subentry1
REP s3subentry1
DWORD
2 BYTES
WORD
DWORD s3subentry2
REP s3subentry2
BYTE unk1
BYTE unk2
BYTE unk3
BYTE unk4
IF unk1 = 0 OR unk2 != 0 OR unk3 != 0 (There has to be a simpler test than this)
REP unk4
DWORD
8 BYTES
DWORD 3
Section 4
DWORD s4entries
DWORD (Some value less than s4entries)
REP s4entries
DWORD datatype
-- type dependent data
DWORD
Type 1
DWORD
Type 2
QWORD lot id
QWORD special id
FLOAT
DWORD
FLOAT 0.123
BYTE
BYTE ID type
BYTE
BYTE
DWORD count
REP count
DWORD subcount
REP subcount
DWORD pointcount
REP pointcount
FLOAT x coordinate
FLOAT y coordinate
BYTE 1
Type 3
(Same as type 2 format)
Type 4
Object footprint?
QWORD lot id
QWORD object id
FLOAT
DWORD
FLOAT 0.123
BYTE
BYTE ID type
BYTE
BYTE
DWORD count
REP count
DWORD subcount
REP subcount
DWORD pointcount
REP pointcount
FLOAT x coordinate
FLOAT y coordinate
BYTE 1
Type 6
(Same as type 2 format)
Type 7
Lot footprint?
QWORD lot id QWORD lot id (Again) FLOAT DWORD FLOAT 0.123 BYTE BYTE ID type BYTE BYTE
Type 8
(Same as type 2 data)
Section 5
DWORD s5entries
REP s5entries
WORD
BYTE
BYTE
DWORD
Special IDs
In some cases rather than a LOT ID (Which always ends with the last 4 bits 0) the data contains what I've termed a special ID. This appears to use the 8 bytes slightly differently.
BYTE 5 BYTE ID type WORD WORD BYTE level (-1 = pool) BYTE (Always 0)
However this could all be coincidental, as the typical lot or object ID looks, to the casual observer, like a DWORD followed by two WORDs.
The following ID types have been observed...
| ID type | Context | Identifies |
|---|---|---|
| 0 | Lot ID (Not a special ID) | Lot |
| 1 | Object ID (Not a special ID) | Object |
| 3 | Section 4 type 6 data | Floor |
| 9 | Door object ID (Not a special ID) | Door |
| 12 | Section 4 type 2 data | Wall? |
| 13 | Section 4 type 8 data | Wall? |
| 15 | Section 4 type 6 data | |
| 16 | Section 4 type 6 data | |
| 18 | Section 4 type 2 data
Section 2 data |
Lot portal |
| 19 | Section 4 type 3 data | |
| 20 | Sim object ID (Not a special ID) | Sim |
| 21 | Section 4 type 6 data | Foundation |