Bone TTARCH: Difference between revisions
Jump to navigation
Jump to search
imported>WATTO No edit summary |
imported>WATTO |
||
| Line 6: | Line 6: | ||
=== Format Specifications === | === Format Specifications === | ||
<tt><b> | <tt><b> | ||
uint32 {4} - Number | uint32 {4} - Number Of Directories <font color="purple">(These seem to be redundant)</font> <br> | ||
<font color="blue"> ''' // | <br> | ||
: uint32 {4} - Length | <font color="blue"> ''' // for each directory ''' </font> <br> | ||
: char {X} - | : uint32 {4} - Directory Name Length <br> | ||
: char {X} - Directory Name <br> | |||
uint32 {4} - Number | <br> | ||
<font color="blue"> ''' // | uint32 {4} - Number Of Files <br> | ||
: uint32 {4} - Length | <br> | ||
: char {X} - | <font color="blue"> ''' // for each file ''' </font> <br> | ||
: uint32 {4} - | : uint32 {4} - Filename Length <br> | ||
: uint32 {4} - File | : char {X} - Filename <br> | ||
: uint32 {4} - File | : uint32 {4} - null <br> | ||
: uint32 {4} - File Offset <font color="purple">(relative to the start of the file data)</font> <br> | |||
uint32 {4} - | : uint32 {4} - File Length <br> | ||
uint32 {4} - | <br> | ||
uint32 {4} - Data Offset <br> | |||
uint32 {4} - Data Length <br> | |||
<br> | |||
byte {X} - File Data <br> | |||
</b></tt> | </b></tt> | ||
=== MultiEx BMS === | === MultiEx BMS === | ||
Revision as of 08:10, 20 December 2005
TTARCH
- Format Type : Archive
- Endian Order : Little Endian
Format Specifications
uint32 {4} - Number Of Directories (These seem to be redundant)
// for each directory
- uint32 {4} - Directory Name Length
- char {X} - Directory Name
uint32 {4} - Number Of Files
// for each file
- uint32 {4} - Filename Length
- char {X} - Filename
- uint32 {4} - null
- uint32 {4} - File Offset (relative to the start of the file data)
- uint32 {4} - File Length
uint32 {4} - Data Offset
uint32 {4} - Data Length
byte {X} - File Data
MultiEx BMS
Not written yet
Notes and Comments
Original file format analysis by Counting Pine.
The files inside this archive are xor'ed with 0xFF, however it appears that parts of the files may be xor'ed with a different value. This is most visable with the .dds images where areas of the image appear corrupted. For more information see this thread.