This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
documentation:file_formats:games:deathkeep [2024/04/14 09:30] – vas.1987 | documentation:file_formats:games:deathkeep [2024/04/15 13:56] (current) – vas.1987 | ||
---|---|---|---|
Line 7: | Line 7: | ||
Directions for stairs and ramps means that named direction must have considered from lower to upper part of the structure. i.e. North direction for the ramp means that I’m sliding from the top towards South.\\ | Directions for stairs and ramps means that named direction must have considered from lower to upper part of the structure. i.e. North direction for the ramp means that I’m sliding from the top towards South.\\ | ||
Directions for the monsters means that monster is faced towards the named direction. | Directions for the monsters means that monster is faced towards the named direction. | ||
+ | |||
+ | I made an app, which reads all game data needed for 3D model export and for some level edit. You can edit every cube, but you can’t extend or shrink the palette. You can extract level to wavefront *.obj format. You can edit a gap between cubes before exporting (for some 3rd app needs). You can also test your suggestions by editing cube’s properties and test it later in the game. First select the target cube, edit its value and click this button “edit”. Then just save a new file or overwrite the an existing one. | ||
+ | |||
+ | ---- | ||
+ | < | ||
__**Contents**__ | __**Contents**__ | ||
Line 22: | Line 27: | ||
**Savefile structure** | **Savefile structure** | ||
- | \\ | ||
**OVERVIEW**. This description covers almost all game data files, which contains level geometry, level textures, inventory items and monsters. Movies, sounds, music and separate cel files are excluded from documenting. I also tried to investigate savefile data structure. | **OVERVIEW**. This description covers almost all game data files, which contains level geometry, level textures, inventory items and monsters. Movies, sounds, music and separate cel files are excluded from documenting. I also tried to investigate savefile data structure. | ||
Line 648: | Line 652: | ||
|FE | | | |FE | | | ||
|FF |Blank (N/A) | | |FF |Blank (N/A) | | ||
- | |||
- | I made an app, which reads all game data needed for 3D model export and for some level edit. You can edit every cube, but you can’t extend or shrink the palette. You can extract level to wavefront *.obj format. You can edit a gap between cubes before exporting (for some 3rd app needs). You can also test your suggestions by editing cube’s properties and test it later in the game. First select the target cube, edit its value and click this button “edit”. Then just save a new file or overwrite the an existing one. ( | ||
- | < | ||
**B) LEVEL DATA FILES** (\data2\levels\*data) | **B) LEVEL DATA FILES** (\data2\levels\*data) | ||
- | Data file structure | + | Data file structure: |
^Offset (HEX) ^Length (HEX) ^Description | ^Offset (HEX) ^Length (HEX) ^Description | ||
Line 930: | Line 931: | ||
^Offset (HEX)^Byte #7 (Chapter A)^Byte #0 (Chapter A)^Description| | ^Offset (HEX)^Byte #7 (Chapter A)^Byte #0 (Chapter A)^Description| | ||
- | | | | |Standart Teleport. Works with zero byte set to 0x80 and blocks 4, 5| | + | |0|0xE4|0x80|Standart Teleport. Works with zero byte set to 0x80 and blocks 4, 5| |
- | | | | | | | + | |0x4|0xE5|0x81| | |
- | | | | |Elevator down. Works with zero byte set to 0x82, blocks 4, 5 and 0xE7(0x83).| | + | |0x8|0xE6|0x82|Elevator down. Works with zero byte set to 0x82, blocks 4, 5 and 0xE7(0x83).| |
- | | | | |This cube points on cubes around elevators. Use blocks 4, 5. Works with zero byte set to 0x83. May be one cube per level, may be some of them.| | + | |0xC|0xE7|0x83|This cube points on cubes around elevators. Use blocks 4, 5. Works with zero byte set to 0x83. May be one cube per level, may be some of them.| |
- | | | | |Wall fireball trigger. Works with zero byte set to 0x84.| | + | |0x10|0xE8|0x84|Wall fireball trigger. Works with zero byte set to 0x84.| |
- | | | | |Floor flame trigger. Works with zero byte set to 0x85.| | + | |0x14|0xE9|0x85|Floor flame trigger. Works with zero byte set to 0x85.| |
- | | | | |Ceiling fireball trigger. Wait an attack from above. Works with zero byte set to 0x86.| | + | |0x18|0xEA|0x86|Ceiling fireball trigger. Wait an attack from above. Works with zero byte set to 0x86.| |
- | | | | |Wall fireball trigger (blue). Works with zero byte set to 0x87.| | + | |0x1C|0xEB|0x87|Wall fireball trigger (blue). Works with zero byte set to 0x87.| |
- | | | | |Switch off the light (reduces brightness). Works with zero byte set to 0x88.| | + | |0x20|0xEC|0x88|Switch off the light (reduces brightness). Works with zero byte set to 0x88.| |
- | | | | |This cube points on some Monsters to set to active mode. Works with zero byte set to 0x8B and blocks 4, 5| | + | |0x24|0xED|0x89| | |
- | | | | | | | + | |0x28|0xEE|0x8A| | |
- | | | | | | | + | |0x2C|0xEF|0x8B|This cube points on some Monsters to set to active mode. Works with zero byte set to 0x8B and blocks 4, 5| |
- | | | | | | | + | |0x30|0xF0|0x8C| | |
- | | | | | | | + | |0x34|0xF1|0x8D| | |
- | | | | | | | + | |0x38|0xF2|0x8E| | |
- | | | | | | | + | |0x3C|0xF3|0x8F| | |
- | | | | | | | + | |0x40|0xF4|0x90| | |
- | | | | | | | + | |0x44|0xF5|0x91| | |
- | | | | | | | + | |0x48|0xF6|0x92| | |
- | | | | |Elevator related DOWN. Works with zero byte set to 0x95, blocks 4, 5 and 0xE7 (0x83). Byte #0 (see chapter A) in all cubes along the elevator’s way must be set to 0x10. Platform returns up?| | + | |0x4C|0xF7|0x93| | |
- | | | | | | | + | |0x50|0xF8|0x94| | |
- | | | | | | | + | |0x54|0xF9|0x95|Elevator related DOWN. Works with zero byte set to 0x95, blocks 4, 5 and 0xE7 (0x83). Byte #0 (see chapter A) in all cubes along the elevator’s way must be set to 0x10. Platform returns up?| |
- | | | | | | | + | |0x58|0xFA|0x96|Elevator UP. Works with zero byte set to 0x96, blocks 4, 5 and 0xE7(0x83). Поднимается снизу наверх. Byte #0 (see chapter A) in all cubes along the elevator’s way must be set to 0x10. Platform returns down.| |
- | | | | | | | + | |0x5C|0xFB|0x97|Elevator DOWN. Works with zero byte set to 0x97, blocks 4, 5 and 0xE7(0x83). Byte #0 (see chapter A) in all cubes along the elevator’s way must be set to 0x10.| |
- | | | | | | | + | |0x60|0xFC|0x98| | |
- | | | | | | | + | |0x64|0xFD|0x99| | |
- | | | | | | | + | |0x68|0xFE|0x9A| | |
+ | |||
+ | **B.7) Block 5** \\ | ||
+ | Block 5 contains all special events logic (teleports, elevators, wall and ceiling triggers, etc.). All data in this block is linked with Block 4 offsets (see chapter B.6). If there are no data for block 5 (block is missing), Block 5 is 4 bytes length and = 4. In order to be working, Byte #0 and Byte #7 must be set (see chapter A). | ||
+ | |||
+ | ^Offset (HEX)^Length, | ||
+ | |-|4|Block 5 size (without these bytes)| | ||
+ | |0|1|Teleports or elevators quantity (or other types quantity)| | ||
+ | |1|3|Teleport or elevator or other entrance (trigger) (X, Y, Z)| | ||
+ | |4|1|Delimiter (always = 1 for teleports type). In other cases = number of dependent cubes.| | ||
+ | |5|3 x n|Teleport exit (X, Y, Z) or dependent cubes (3xn) for other types. n = number of dependent cubes. n=1 for teleports, because teleport has only one dependent cube (exit).| | ||
+ | |5+ 3 x n|3|Next teleport or elevator or other entrance (trigger) (X, Y, Z)| | ||
+ | | |1|Next delimiter (always = 1 for teleports type). In other cases = number of dependent cubes.| | ||
+ | | | |…| | ||
+ | |||
+ | If dependent cube is an another trigger, this new trigger will be activated instead of the first triggering cube (non-teleport related). | ||
+ | |||
+ | **C) ANIMBACK** \\ | ||
+ | These objects appear in the cube then value on corresponding offsets in Block 1 (see chapter B.2) is not zero. ANIMBACK are usually animated objects which have no collision and may resides always near walls (torches, flames, huge challises etc…) and in the cube’s center (sparkles, hanging objects, candelabras, | ||
+ | I didn’t dive deeply into the investigation for this type of objects, because it wasn’t necessary for building a 3D model, which was my primary objective. Object’s structure is fairly investigated, | ||
+ | |||
+ | ^Offset (HEX)^Length, | ||
+ | |0|4|1| | ||
+ | |4|4|Header size in bytes| | ||
+ | |8|1|Bytes left before “ANIM” header?| | ||
+ | |9|1|Frames quantity| | ||
+ | |0xA|1|?| | ||
+ | |0xB|1|?| | ||
+ | |0xC|1|Animation speed? Frames selection? | ||
+ | |…|…|…| | ||
+ | | |4|“ANIM” section size in bytes| | ||
+ | | |4|‘ANIM’ identifier string| | ||
+ | | |various|“ANIM” data| | ||
+ | |||
+ | **D) ANIMENEMIES** \\ | ||
+ | This objects placed in level are monsters. Enemy placement encoded in Byte #7 (see chapter A.8). May be three of monster types per level maximum. I also didn’t investigate this objects deeply. Object’s structure is shown below. | ||
+ | |||
+ | ^Offset (HEX)^Length (HEX)^Description| | ||
+ | |0|4|Monster types quantity| | ||
+ | |4|4|Header size in bytes| | ||
+ | |8|1|Offset to monster’s name| | ||
+ | |9|1|0?| | ||
+ | |0xA|1|?| | ||
+ | |0xB|1|?| | ||
+ | |0xC|1|Animation speed| | ||
+ | |0xD|1|Z coordinate. Loading at this altitude in the level cube| | ||
+ | |0xE| |Transparency or translucency| | ||
+ | |0xF| |Z coordinate. While walking| | ||
+ | |0x10| |?| | ||
+ | |0x11| |?| | ||
+ | |0x12| |?| | ||
+ | |0x13| |Z coordinate. Walking coordinate? Attacking coordinate? | ||
+ | |0x14| |?| | ||
+ | |0x15| |?| | ||
+ | |0x16| |?| | ||
+ | |0x17| |?| | ||
+ | |0x18| |?| | ||
+ | |0x19| |?| | ||
+ | |0x1A| |?| | ||
+ | |0x1B| |?| | ||
+ | |0x1C| |?| | ||
+ | |0x1D| |Health? Armor?| | ||
+ | |0x1E| |?| | ||
+ | |0x1F| |?| | ||
+ | |0x20| |?| | ||
+ | |0x21| |?| | ||
+ | |0x22| |?| | ||
+ | |0x23| |Health| | ||
+ | |0x24| |Speed| | ||
+ | |0x25| |?| | ||
+ | |0x26| |First frame ID?| | ||
+ | |0x27| |?| | ||
+ | |0x28| |First attacking frame ID?| | ||
+ | |0x29| |Frame ID?| | ||
+ | |0x2A| |Frame ID?| | ||
+ | |0x2B| |Frame ID?| | ||
+ | |0x2C| |Frame ID?| | ||
+ | |0x2D| |Frame ID?| | ||
+ | |0x2E| |Frame ID?| | ||
+ | |…| |….| | ||
+ | | |4|“ANIM” section size in bytes| | ||
+ | | |4|‘ANIM’ identifier string| | ||
+ | | |various|“ANIM” data| | ||
+ | |||
+ | **E) ANIMOBJ** \\ | ||
+ | This objects are for level decoration (stalactites, | ||
+ | |||
+ | ^Offset (HEX)^Length (HEX)^Description| | ||
+ | |0| |Object types quantity available| | ||
+ | |4| |Header size in bytes| | ||
+ | |8| |?| | ||
+ | |9| |Frames quantity| | ||
+ | |0xA| |?| | ||
+ | |0xB| |?| | ||
+ | |0xC| |Animation speed| | ||
+ | |0xD| |Z coordinate| | ||
+ | |0xE| |Transparency. 0-No transparency, | ||
+ | |0xF| |0?| | ||
+ | |0x10| |0| | ||
+ | |0x11| |Collision (=4 only?)| | ||
+ | |…| |…| | ||
+ | | |4|“ANIM” section size in bytes| | ||
+ | | |4|‘ANIM’ identifier string| | ||
+ | | |various|“ANIM” data| | ||
+ | |||
+ | **F) OBJECTS** \\ | ||
+ | These objects are unique items which could be found on a level (Keys, Ancestral Artefacts, Feast, etc…). Object placement encoded in Byte #7 (see chapter A.8). May be three or four of these object types per level maximum. In some levels 4th object exist in level file, but kind of ‘blank’. Object may be observed as plain texture in the game. No deep investigation also, sorry. | ||
+ | |||
+ | ^Offset (HEX)^Length (HEX)^Descripton| | ||
+ | |0|4|Object types quantity available| | ||
+ | |4|1|Item ID (see Byte #7 in chapter A.8)| | ||
+ | |5|1|0| | ||
+ | |6|1|0| | ||
+ | |7|1|Header size in bytes| | ||
+ | |8|1|Offset to object’s name| | ||
+ | |9|1|Frames quantity| | ||
+ | |0xA|1|?| | ||
+ | |0xB|1|?| | ||
+ | |0xC|1|Animation speed| | ||
+ | |0xD|1|Z coordinate| | ||
+ | |0xE|1|Transparency. 0-No transparency, | ||
+ | |0xF|1|0? | ||
+ | |0x10|1|0| | ||
+ | |0x11|1|0? | ||
+ | |0x12|1|? | ||
+ | |0x13|1|? | ||
+ | |0x14|1|? | ||
+ | |0x15|1|? | ||
+ | |0x16|1|? | ||
+ | |0x17|1|? | ||
+ | |0x18|1|? | ||
+ | |0x19|1|? | ||
+ | |0x1A|1|? | ||
+ | |0x1B|1|Item ID again (see Byte #7 in chapter A.8)| | ||
+ | |0x1C|1|? | ||
+ | |0x1D|1|? | ||
+ | |0x1E|1|? | ||
+ | |0x1F|1|? | ||
+ | |0x20|1|? | ||
+ | |0x21|various|Object’s name| | ||
+ | | |4|“ANIM” section size in bytes| | ||
+ | | |4|‘ANIM’ identifier string| | ||
+ | | |various|“ANIM” data| | ||
+ | |||
+ | **G) END OF FILE** \\ | ||
+ | End of the file mark (-1) is located after objects block (see chapter F). After this mark level name follows. | ||
+ | |||
+ | ^Offset (HEX)^Length^Description| | ||
+ | |0|4|0xFFFFFF| | ||
+ | |4|various|Level name| | ||
+ | | |1|0x20 (dot)| | ||
+ | |||
+ | **H) GLOBAL DATA FILES** (\data2\DK Data*)\\ | ||
+ | This three files contains all item textures (also small item textures in inventory), explosions animations, weapons animations, inventory backgrounds and huge amount of unknown data.\\ | ||
+ | File structure is the follows. | ||
+ | |||
+ | ^Offset (HEX)^Length, | ||
+ | |0|0xD0|Character name and default skills| | ||
+ | |0xD0|4|Block 1 size in bytes including this 4 bytes| | ||
+ | | |various|Block 1| | ||
+ | | |4|‘APPL’ identifier string| | ||
+ | | |4|Block 2 size in bytes including this 4 bytes| | ||
+ | | |various|Block 2| | ||
+ | | |4|‘APPL’ identifier string| | ||
+ | | |4|Block 3 size in bytes including this 4 bytes| | ||
+ | | |various|Block 3| | ||
+ | | |4|‘APPL’ identifier string| | ||
+ | | |4|Block 4 size in bytes including this 4 bytes| | ||
+ | | |various|Block 4| | ||
+ | | |4|‘APPL’ identifier string| | ||
+ | | |4|Block 5 size in bytes including this 4 bytes| | ||
+ | | |various|Block 5| | ||
+ | | |4|‘APPL’ identifier string| | ||
+ | | |4|Block 6 size in bytes including this 4 bytes| | ||
+ | | |various|Block 6| | ||
+ | | |4|‘APPL’ identifier string| | ||
+ | | |4|Block 7 size in bytes including this 4 bytes| | ||
+ | | |various|Block 7| | ||
+ | | |4|‘APPL’ identifier string| | ||
+ | | |4|0x63 for DK Data 1 file, 0x64 for DK Data 2 file, 0x69 for DK Data 3 file| | ||
+ | | |4|Item ID or index # (zero-length header)| | ||
+ | | |4|“ANIM” size in bytes| | ||
+ | | |4|‘ANIM’ identifier string| | ||
+ | | |various|“ANIM” data| | ||
+ | | | |…| | ||
+ | | |1|Item ID or index # (zero-length header)| | ||
+ | | |4|“ANIM” size in bytes| | ||
+ | | |4|‘ANIM’ identifier string| | ||
+ | | |various|“ANIM” data| | ||
+ | | |4|“ANIM” or “CCB” header size in bytes| | ||
+ | | |1|If equal to zero, item’s texture is below. If not, take texture from this item’s ID| | ||
+ | | |1|0| | ||
+ | | |1|Item ID| | ||
+ | | |4|“ANIM” or “CCB” size in bytes| | ||
+ | | |4|‘ANIM’ or ‘CCB’ identifier string| | ||
+ | | |various|“ANIM” or ‘CCB’ data| | ||
+ | |||
+ | **I) SAVEFILE STRUCTURE** \\ | ||
+ | Savefile size is 356 bytes. I tried a lot of tests and now I know some bytes are used for. Some bytes have secondary meaning, may be character dependent. I made a table with all investigated data. Each cell is a byte. Number of columns and rows are equal to HEX-editor in GameGuru. | ||
+ | |||
+ | |— |— |— |— |— | <font inherit/ | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | |— |— | <font inherit/ | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | |— |— |— |Health Max |Fighter at level #. Text description on the loading screen | ||
+ | |— |Character level |— |— | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | |— |— |— |— |— |— |— |Level completition (time). 0 = infinite. Max - 0xFF (10 seconds) | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | |— |— |— |— | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | |— | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | |— |— |— |— |— |— |— |— | | ||
+ | |— |— |— | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | |Ring #2 |Boots | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | | <font inherit/ | ||
+ | |||
+ | Bytes for pells for Fighter/ | ||
+ | Cone of cold, Feeblemind, Hold monster Death fog, Disintegrate, | ||
+ | |||
+ | Artefacts byte and its possible values with marked artefacts colors avalable in inventory: | ||
+ | |||
+ | ^Artefacts colors^^^Value (HEX)| | ||
+ | |Red available|Green available|Blue available|0xF, | ||
+ | | |Green available|Blue available|0xD, | ||
+ | |Red available| |Blue available|0xB, | ||
+ | | | |Blue available|0x9, | ||
+ | |Red available|Green available| |0x7, 0x6| | ||
+ | | |Green available| |0x5, 0x4| | ||
+ | |Red available| | |0x3, 0x2| | ||