OniGalore

OBD:Instance file format: Difference between revisions

OBD Discussion

OBD:Instance file format (view source)

Revision as of 23:31, 29 June 2025

161 bytes added ,  29 June
corrected type of ints in header; it's really v1.0 and v1.1 of the engine, not "PC" and "Mac"
(oops, "gaps" was not referring to the items in the previous sentence)
(corrected type of ints in header; it's really v1.0 and v1.1 of the engine, not "PC" and "Mac")
 
(One intermediate revision by the same user not shown)
Line 27: Line 27:
{{Table}}
{{Table}}
{{OBD_Table_Header}}
{{OBD_Table_Header}}
{{OBDtr| 0x00 | int64   | | 1F 27 DC 33 DF BC 03 00 | 0x0003BCDF33DC271F | Total template checksum (main indicator of engine compatibility):
{{OBDtr| 0x00 | uint64   | | 1F 27 DC 33 DF BC 03 00 | 0x0003BCDF33DC271F | Total template checksum (main indicator of engine compatibility):
*0x0003BCDF33DC271F ("PC") - templates compatible with Windows retail engine(s)
*0x0003BCDF33DC271F (v1.0) - templates compatible with Windows retail engine(s)
*0x0003BCDF23C13061 ("Mac") - templates compatible with Windows demo and Mac engines
*0x0003BCDF23C13061 (v1.1) - templates compatible with Windows demo and Mac engines
*0x0003BA70A8D8AE11 ("PS2") - templates compatible with PlayStation 2 engine(s)
*0x0003BA70A8D8AE11 (PS2) - templates compatible with PlayStation 2 engine(s)
*0x0000000000000000 (blank) - for use with [[OniX]] engine(s) (VR33), which handle data versioning using the 0x3C field below
*0x0000000000000000 (blank) - for use with [[OniX]] engine(s) (VR33), which handle data versioning using the 0x3C field below
OniSplit's .oni files (VR32) use PC checksum by default and Mac/PS2 checksums where required (SNDD, TXMP, AGQG, M3GM, IGSt, TSFT/TSGA, TRAM/TREX) }}
OniSplit's .oni files (VR32) use PC checksum by default and Mac/PS2 checksums where required (SNDD, TXMP, AGQG, M3GM, IGSt, TSFT/TSGA, TRAM/TREX) }}
{{OBDtr| 0x08 | int32   | | 31 33 52 56             | '13RV'             | .dat version (meant to be read as "VR31")<br>OniSplit's .oni files use '23RV' ("VR32") instead<br>OniX's [[Oni (folder)|GDFX]] uses '33RV' ("VR33") to signify that the new data versioning system is in use }}
{{OBDtr| 0x08 | uint32   | | 31 33 52 56 | '13RV'   | .dat version (meant to be read as "VR31")<br>OniSplit's .oni files use '23RV' ("VR32") instead<br>OniX's [[Oni (folder)|GDFX]] uses '33RV' ("VR33") to signify that the new data versioning system is in use }}
{{OBDtr| 0x0C | int16   | | 40 00 | 64 | size of this header }}
{{OBDtr| 0x0C | uint16   | | 40 00       | 64       | size of this header }}
{{OBDtr| 0x0E | int16   | | 14 00 | 20 | size of instance descriptor }}
{{OBDtr| 0x0E | uint16   | | 14 00       | 20       | size of instance descriptor }}
{{OBDtr| 0x10 | int16   | | 10 00 | 16 | size of template descriptor }}
{{OBDtr| 0x10 | uint16   | | 10 00       | 16       | size of template descriptor }}
{{OBDtr| 0x12 | int16   | | 08 00 | 8 | size of name descriptor }}
{{OBDtr| 0x12 | uint16   | | 08 00       | 8         | size of name descriptor }}
{{OBDtr| 0x14 | int32   | | 83 24 00 00 | 9347      | instance descriptor count  }}
{{OBDtr| 0x14 | uint32   | | 83 24 00 00 | 9347      | instance descriptor count  }}
{{OBDtr| 0x18 | int32   | | D4 1B 00 00 | 7124      | name descriptor count }}
{{OBDtr| 0x18 | uint32   | | D4 1B 00 00 | 7124      | name descriptor count }}
{{OBDtr| 0x1C | int32   | | 38 00 00 00 | 56        | template descriptor count }}
{{OBDtr| 0x1C | uint32   | | 38 00 00 00 | 56        | template descriptor count }}
{{OBDtr| 0x20 | int32   | | A0 BC 03 00 | 0x03BCA0  | data table offset }}
{{OBDtr| 0x20 | uint32   | | A0 BC 03 00 | 0x03BCA0  | data table offset }}
{{OBDtr| 0x24 | int32   | | A0 35 25 00 | 2438560  | data table size }}
{{OBDtr| 0x24 | uint32   | | A0 35 25 00 | 2438560  | data table size }}
{{OBDtr| 0x28 | int32   | | 40 F2 28 00 | 0x28F240  | name table offset }}
{{OBDtr| 0x28 | uint32   | | 40 F2 28 00 | 0x28F240  | name table offset }}
{{OBDtr| 0x2C | int32   | | 04 4F 02 00 | 151300    | name table size }}
{{OBDtr| 0x2C | uint32   | | 04 4F 02 00 | 151300    | name table size }}
{{OBDtr| 0x30 | int32   | | 99 CF 40 00 | (garbage) | used by OniSplit for raw table offset }}
{{OBDtr| 0x30 | uint32   | | 99 CF 40 00 | (garbage) | used by OniSplit for raw table offset }}
{{OBDtr| 0x34 | int32   | | 90 4F 63 00 | (garbage) | used by OniSplit for raw table size }}
{{OBDtr| 0x34 | uint32   | | 90 4F 63 00 | (garbage) | used by OniSplit for raw table size }}
{{OBDtr| 0x38 | int32   | | F4 55 5F 00 | (garbage) | unused }}
{{OBDtr| 0x38 | uint32   | | F4 55 5F 00 | (garbage) | unused }}
{{OBDtr| 0x3C | int32   | | 90 4F 63 00 | (garbage) | used by OniX (three high bytes) for data versioning; contains the highest data version (timestamp) found in any instance in this .dat; see instance descriptor table's 0x10 for format }}
{{OBDtr| 0x3C | uint32   | | 90 4F 63 00 | (garbage) | used by OniX (three high bytes) for data versioning; contains the highest data version (timestamp) found in any instance in this .dat; see instance descriptor table's 0x10 for format }}
|}
|}


Line 169: Line 169:
Likewise, the template descriptor array starts directly after the name descriptors. Since name descriptors are 8 bytes, 8 * 7124 (taken from the header) = 56992, or 0xDEA0, and adding that to the name descriptor array's start address (0x02DA7C) gives us 0x03B91C as the start of the template descriptors.
Likewise, the template descriptor array starts directly after the name descriptors. Since name descriptors are 8 bytes, 8 * 7124 (taken from the header) = 56992, or 0xDEA0, and adding that to the name descriptor array's start address (0x02DA7C) gives us 0x03B91C as the start of the template descriptors.


The template descriptor array contains information about all templates (that is, resource types, AKA tags), used in the file (56 in this case, as we learned from the file header). Any resource occurring in this instance file has to have its type listed here. Here is the template descriptor at 0x3B9FC:
The template descriptor array contains information about all templates (that is, resource types, aka tags), used in the file (56 in this case, as we learned from the file header). Any resource occurring in this instance file has to have its type listed here. Here is the template descriptor at 0x3B9FC:


{{Table}}
{{Table}}
Line 175: Line 175:
{{OBDtr| 0x00 | int64  | | 3C B9 A6 71 08 00 00 00 | 0x871A6B93C | template checksum }}
{{OBDtr| 0x00 | int64  | | 3C B9 A6 71 08 00 00 00 | 0x871A6B93C | template checksum }}
{{OBDtr| 0x08 | tag    | | 45 47 52 54            | 'EGRT'      | template tag }}
{{OBDtr| 0x08 | tag    | | 45 47 52 54            | 'EGRT'      | template tag }}
{{OBDtr| 0x0C | int32  | | 01 00 00 00            | 1          | number of resources in file that use this template }}
{{OBDtr| 0x0C | int32  | | 01 00 00 00            | 1          | unused: number of resources in file that use this template }}
|}
|}


The '''template checksum''' is used to prevent loading of instance files that are not compatible with the current engine version. The '''tag''' is the same kind of number-written-as-backwards-ASCII that we discussed in the "Backwards and garbage data" section; in this case, 'EGRT' means [[TRGE]]. The '''number of resources''' is self-explanatory.
The '''template checksum''' is used to prevent loading of instance files that are not compatible with the current engine version. The '''tag''' is the same kind of number-written-as-backwards-ASCII that we discussed in the "Backwards and garbage data" section; in this case, 'EGRT' means [[TRGE]]. The field for the '''number of resources''' using this template is unused. The number should be correct for each template, but Oni never uses it for anything.


You might wonder how Oni knows how to read each type of data, such as a SUBT or an ABNA. The simple answer is that this information is hard-coded into Oni. In fact, the information on each instance type, as stored in Oni's code, is actually the real "template". The file data only gives the tag and checksum that refer to a certain template. Which types of data fields are encountered in which order is already known by Oni. These hardcoded templates also tell Oni which parts of the file data are reserved for pointers.
You might wonder how Oni knows how to read each type of data, such as a SUBT or an ABNA. The simple answer is that this information is hard-coded into Oni. In fact, the information on each instance type, as stored in Oni's code, is actually the real "template". The file data only gives the tag and checksum that refer to a certain template. Which types of data fields are encountered in which order is already known by Oni. These hardcoded templates also tell Oni which parts of the file data are reserved for pointers.
Retrieved from "https://wiki.oni2.net/Special:MobileDiff/45256...45398"