AttribSys Vault: Difference between revisions
m (Burninrubber0 moved page AttribSysVault (Burnout Paradise) to AttribSys Vault: Removed unnecessary qualifier.) |
(dumping random scribblings from very outdated notes - not sure where the "start node" name referenced here comes from so might have missed some info here.) |
||
Line 76: | Line 76: | ||
== Start node == |
== Start node == |
||
There is no data after the ChunkBlock. |
|||
{| class="wikitable" |
{| class="wikitable" |
||
|- |
|- |
||
Line 83: | Line 81: | ||
|- |
|- |
||
| 0x0 || 0x8 || [[#Attrib::Vault::ChunkBlock | ChunkBlock]] || super_ChunkBlock || || |
| 0x0 || 0x8 || [[#Attrib::Vault::ChunkBlock | ChunkBlock]] || super_ChunkBlock || || |
||
|- |
|||
| ??? || || || || || |
|||
|} |
|} |
||
Size is 16 bytes, but the final 8 bytes is always null. This node appears to not be read by the game. |
|||
== Data node == |
== Data node == |
||
Line 94: | Line 96: | ||
This is followed by several [[#Attrib::CollectionLoadData | collections]]. |
This is followed by several [[#Attrib::CollectionLoadData | collections]]. |
||
This node is not read directly. Pointers in other nodes read the data that lies in this node. |
|||
=== Attrib::CollectionLoadData === |
=== Attrib::CollectionLoadData === |
||
Line 177: | Line 181: | ||
| 0x10 || 0x4 || uint32_t || mDataBytes || || |
| 0x10 || 0x4 || uint32_t || mDataBytes || || |
||
|- |
|- |
||
| 0x14 || 0x4 || uint32_t || mDataOffset || || |
| 0x14 || 0x4 || uint32_t || mDataOffset || Points to data in DatN (data node) || |
||
|} |
|} |
||
Line 204: | Line 208: | ||
| 0x8 || 0x8 || [[#Attrib::PtrRef::anon_union_0 | anon_union_0]] || field_3 || || |
| 0x8 || 0x8 || [[#Attrib::PtrRef::anon_union_0 | anon_union_0]] || field_3 || || |
||
|} |
|} |
||
Pointers with type 2 with an index of 1 point to the bin. <!-- TODO: this is perhaps not the only scenario, but is the only one seen in Burnout - perhaps will be clearer if we figure out what "type" and "index" means. --> |
|||
=== Attrib::PtrRef::anon_union_0 === |
=== Attrib::PtrRef::anon_union_0 === |
||
Line 218: | Line 224: | ||
The bin is primarily data but has one ChunkBlock in Burnout Paradise: |
The bin is primarily data but has one ChunkBlock in Burnout Paradise: |
||
* '''StrE''': The string exports |
* '''StrE''': The string exports |
||
The rest of the data in the bin is not associated to a chunk and is instead pointed to by the vault. |
|||
=== String exports === |
=== String exports === |
Revision as of 06:48, 17 January 2023
AttribSys vault resources act as a database which holds attributes for vehicles, engines, surfaces and more. They are split into the vault, which holds information needed to access the data, and the bin, which holds the actual attribute data. Vaults work with the AttribSys schema found in the executable.
Structures
CgsResource::AttribSysVaultResource
32-bit
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x4 | uint8_t* | mpau8VltData | ||
0x4 | 0x4 | uint32_t | muVltSizeInBytes | ||
0x8 | 0x4 | uint8_t* | mpau8BinData | ||
0xC | 0x4 | uint32_t | muBinSizeInBytes |
64-bit
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | uint8_t* | mpau8VltData | ||
0x8 | 0x4 | uint32_t | muVltSizeInBytes | ||
0xC | 0x4 | padding | |||
0x10 | 0x8 | uint8_t* | mpau8BinData | ||
0x18 | 0x4 | uint32_t | muBinSizeInBytes |
Vault
The vault is a set of structures with ChunkBlocks which are read sequentially. In Burnout Paradise, these are:
- Vers: The version
- DepN: The dependency node
- StrN: The start node
- DatN: The data node
- ExpN: The export node
- PtrN: The pointer node
Attrib::Vault::ChunkBlock
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x4 | uint32_t | mType | A type ID similar in form to a magic number | |
0x4 | 0x4 | uint32_t | mSize | The total size of the chunk |
Version
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | ChunkBlock | super_ChunkBlock | ||
0x8 | 0x8 | uint64_t | mVersion | Version hash |
Dependency node
Attrib::Vault::DependencyNode
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | ChunkBlock | super_ChunkBlock | ||
0x8 | 0x8 | HashInt | mCount | Number of dependencies |
This structure is immediately followed by the hashes of the dependency strings, then the offsets of the strings relative to the start of the first string, then the strings themselves.
Start node
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | ChunkBlock | super_ChunkBlock | ||
??? |
Size is 16 bytes, but the final 8 bytes is always null. This node appears to not be read by the game.
Data node
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | ChunkBlock | super_ChunkBlock |
This is followed by several collections.
This node is not read directly. Pointers in other nodes read the data that lies in this node.
Attrib::CollectionLoadData
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | Key | mKey | ||
0x8 | 0x8 | Key | mClass | ||
0x10 | 0x8 | Key | mParent | ||
0x18 | 0x4 | uint32_t | mTableReserve | Amount allocated for entries | |
0x1C | 0x4 | uint32_t | mTableKeyShift | ||
0x20 | 0x4 | uint32_t | mNumEntries | Number of entries | |
0x24 | 0x2 | uint16_t | mNumTypes | Number of types | |
0x26 | 0x2 | uint16_t | mTypesLen | Amount allocated for types | |
0x28 | 0x4 | void* | mLayout | padding | |
0x28 | 0x4 | padding |
This is always followed by the types, then the entries (which are the key followed by several unknown bytes - might be a node).
Attrib::Node
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | Key | mKey | ||
0x8 | 0x4 | anon_union_0 | field_1 | Just a pointer | |
0xC | 0x2 | uint16_t | mTypeIndex | ||
0xE | 0x1 | uint8_t | mMax | Assuming collections use this, it's the only part of the entry used | |
0xF | 0x1 | uint8_t | mFlags |
Attrib::Node::anon_union_0
Length | Type | Name | Description | Comments |
---|---|---|---|---|
0x4 | void* | mPtr | ||
0x4 | Array* | mArray | ||
0x4 | uintptr_t | mValue | ||
0x4 | uintptr_t | mOffset |
Export node
Attrib::Vault::ExportNode
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | ChunkBlock | super_ChunkBlock | ||
0x8 | 0x8 | HashInt | mCount | Number of dependencies |
Followed by export entries of an amount defined by mCount.
Attrib::Vault::ExportEntry
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | ExportID | mID | ||
0x8 | 0x8 | TypeID | mType | ||
0x10 | 0x4 | uint32_t | mDataBytes | ||
0x14 | 0x4 | uint32_t | mDataOffset | Points to data in DatN (data node) |
Pointer node
Attrib::Vault::PointerNode
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | ChunkBlock | super_ChunkBlock |
Followed by several PtrRefs.
Attrib::PtrRef
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x4 | uint32_t | mFixupOffset | ||
0x4 | 0x2 | uint16_t | mPtrType | ||
0x6 | 0x2 | uint16_t | mIndex | ||
0x8 | 0x8 | anon_union_0 | field_3 |
Pointers with type 2 with an index of 1 point to the bin.
Attrib::PtrRef::anon_union_0
Length | Type | Name | Description | Comments |
---|---|---|---|---|
0x8 | ExportID | mExportID | ||
0x8 | HashInt | mOffset |
Bin
The bin is primarily data but has one ChunkBlock in Burnout Paradise:
- StrE: The string exports
The rest of the data in the bin is not associated to a chunk and is instead pointed to by the vault.
String exports
Offset | Length | Type | Name | Description | Comments |
---|---|---|---|---|---|
0x0 | 0x8 | ChunkBlock | super_ChunkBlock |
This is followed by null-terminated strings.
Attributes
The fields and order are defined by the AttribSys schema.