DO/BTB
From Dark Omen Wiki
(Unknown Chunk is Objectives) |
(→Objectives Chunk) |
||
| Line 76: | Line 76: | ||
3-TUPLE RECORD n (unknown) type=3, size=20 | 3-TUPLE RECORD n (unknown) type=3, size=20 | ||
| + | Each tuple appears to look a little like this: | ||
| + | |||
| + | (Objective Code, data1, data2) | ||
| + | |||
| + | In SotHR, the objective code is a letter from A-Z, I haven't seen an Objective Code that is greater than 26, so this seems like this may carry over. | ||
:{|class="wikitable" | :{|class="wikitable" | ||
| - | |+ | + | |+Description of Objectives |
| - | ! | + | ! Objective Code !! Description !! Subvalue 1 !! Subvalue 2 !! Effect |
| - | + | ||
| - | + | ||
|- | |- | ||
| - | | || | + | | C || Defines Critical Unit Lose Condition || [[ARM|Unique unit ID]] of critical unit || ''Unknown'' || ex (3, 1, 0) states that Morgan Bernhardt (unit id 1) must not die. |
|} | |} | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
---- | ---- | ||
Revision as of 13:47, 1 January 2009
Contents |
Building Blocks
The BTB file consists of chunks of the form:
struct CHUNK_HEADER
{
unsigned int chunkType;
unsigned int chunkSize; // excluding header
};
Each chunk consists of 'records' which are similar to chunks, but the record size is inclusive of the header.
struct RECORD_HEADER
{
unsigned int recordType;
unsigned int recordSize; // including header
};
When coordinates are referenced in the BTB file, divide them by eight to get into the same coordinates as the terrain mesh.
Overall File Structure
The observed format of the BTB files in Dark Omen follows in order:
START/END CHUNK, type=0xBEAFEED0, size=0 HEADER CHUNK, type=1, size=240 UNKNOWN CHUNK, type=2, size=<varies> OBSTACLES CHUNK, type=3, size=<varies> REGION CHUNK 0, type=4, size=<varies> REGION CHUNK 1, type=4, size=<varies> . . . REGION CHUNK n, type=4, size=<varies> GAME OBJECT CHUNK, type=5, size=<varies> START/END CHUNK, type=0xBEAFEED0, size=0
Chunk Descriptions
Start/End Chunk
This chunk is just a marker of the start/end of the file; it contains no data
Header Chunk
HEADER CHUNK, type=1, size=240
INTEGER RECORD (Map width) type=1, size=12
INTEGER RECORD (Map height) type=2, size=12
STRING RECORD (Mercenary Army file name without extension) type=1001, size=40
STRING RECORD (Enemy Army file name without extension) type=1002, size=40
STRING RECORD (CTL filename without extension) type=1003, size=40
STRING RECORD ("/0") type=1004, size=40
STRING RECORD ("/0") type=1005, size=40
2-TUPLE RECORD ( [Number of Regions in file, Number of line segments in all regions] ) type=9, size=16
Objectives Chunk
This chunk is made up of several 3-tuples, which contain information about the objectives for this scenario.
OBJECTIVES CHUNK, type=2, size=<varies> 3-TUPLE RECORD 0 (unknown) type=3, size=20 3-TUPLE RECORD 1 (unknown) type=3, size=20 . . . 3-TUPLE RECORD n (unknown) type=3, size=20
Each tuple appears to look a little like this:
(Objective Code, data1, data2)
In SotHR, the objective code is a letter from A-Z, I haven't seen an Objective Code that is greater than 26, so this seems like this may carry over.
Description of Objectives Objective Code Description Subvalue 1 Subvalue 2 Effect C Defines Critical Unit Lose Condition Unique unit ID of critical unit Unknown ex (3, 1, 0) states that Morgan Bernhardt (unit id 1) must not die.
Obstacles Chunk
This chunk seems to contain information about obstacles on the map (e.g. trees). Increase the Integer Record by a higher value (e.g. +10) to avoid crashes in non-official Multiplayer maps. This might imply that the number (type=8) corresponds to an amount of memory to allocate for something.
OBSTACLES CHUNK, type=3, size=<varies>
INTEGER RECORD (unknown) type=8, size=12
COMPOUND RECORD 0 (contains sub-records) type=501, size=80
INTEGER RECORD (type of obstacle - might be bit flags - see table below) type=5, size=12
INTEGER RECORD (x position) type=1, size=12
INTEGER RECORD (y position) type=2, size=12
INTEGER RECORD (z position) type=4, size=12
INTEGER RECORD (radius of bounding sphere) type=6, size=12
INTEGER RECORD (direction - normally 0) type=7, size=12
COMPOUND RECORD 1 (contains sub-records) type=501, size=80
.
.
.
COMPOUND RECORD n (contains sub-records) type=501, size=80
Type Description 1 This obstacle is active 2 This obstacle blocks movement into its area 4 This obstacle blocks movement and projectiles into its area
n.b. some of the above information is guessed by analogy to the text script files found in SotHR
Region Chunk
This chunk contains information which delimits an area or path. It primarily consists of a list of line segments which define the path or polygon. These areas and paths seem to be used for a variety of reasons, some of which are listed below.
REGION CHUNK, type=4, size=<varies> STRING RECORD (the human-readable name of the region) type=1006, size=40 INTEGER RECORD (type code - might be bit flags - see table below) type=5, size=12 2-TUPLE RECORD ([starting X position, starting Y position]) type=10, size=16 4-TUPLE RECORD 0 ([ line start X, line start Y, line end X, line end Y]) type=502, size=24 4-TUPLE RECORD 1 ([ line start X, line start Y, line end X, line end Y]) type=502, size=24 . . . 4-TUPLE RECORD n ([ line start X, line start Y, line end X, line end Y]) type=502, size=24
Bit Value Description 0 1 Always seems to be set 1 2 Closed areas have this bit set 2 4 Paths have this bit set 3 8 Unknown at this time 4 16 About half of the movement boundaries have this bit set 5 32 The Battle Region has this bit set 6 64 Unknown at this time 7 128 The other half of the movement boundaries have this bit set 8 256 Player 1 deployment area has this bit set 9 512 Player 2 deployment area has this bit set 10 1024 The Visible Region has this bit set
Game Objects Chunk
This chunk seems to hold a lot of the game-related info, for example initial enemy deployment, triggers for mission events, movement targets for the enemy AI.
GAME OBJECTS CHUNK, type=5, size=<varies>
INTEGER RECORD (the number of game object compound records in this chunk) type=8, size=12
COMPOUND RECORD 0 (contains sub-records and represents a game object) type=503, size=104
INTEGER RECORD (type of game object - might be bit flags - see table below) type=5, size=12
INTEGER RECORD (x position) type=1, size=12
INTEGER RECORD (y position) type=2, size=12
INTEGER RECORD (radius of area) type=6, size=12
INTEGER RECORD (direction) type=7, size=12
INTEGER RECORD (Script ID?) type=11, size=12
INTEGER RECORD (Unit ID) type=12, size=12
INTEGER RECORD (Node ID?) type=13, size=12
COMPOUND RECORD 1 (contains sub-records and represents a game object) type=503, size=104
.
.
.
COMPOUND RECORD n (contains sub-records and represents a game object) type=503, size=104
Questions
- What does the "direction" value say? There is a orientation value in PRJ->TERR for each graphical instance, but what extra information does BTB->ITEM->direction bring?
- Is the Z position also multiplied by 8 by default?
