Page 1 of 4 123 ... LastLast
Results 1 to 10 of 35

Thread: Reversal of DKII Binary File Formats

  
  1. #1

    Default Reversal of DKII Binary File Formats

    This thread is devoted to the reversal of the DKII level and data binary file formats, for modding. Feel free to contribute.




    Binary Data - Level Map File Terrain Slabs (Work in Progress)



    The first byte I GUESS is the slab type.

    The second byte seems to be the owner of the slab type.

    The third and fourth bytes are unknown to me, but I guess they
    are always 01 and 00 (maybe junk data or seperators/spacers)?


    Code:
    Hex Code = Slab Type
    
    
    01 02 01 00 = Impenetrable Rock Slab owned by Neutral Player
    
    02 02 01 00 = Rock Slab owned by Neutral Player
    
    03 02 01 00 = Dirt Path Slab owned by Neutral Player
    
    04 02 01 00 = Water Slab owned by Neutral Player
    
    05 02 01 00 = Lava Slab owned by Neutral Player
    
    06 02 01 00 = Gold Slab owned by Neutral Player
    
    07 02 01 00 = Gems Slab owned by Neutral Player
    
    08 00 01 00 = Claimed Path Slab owned by Unknown
    
    08 01 01 00 = Claimed Path Slab owned by Good Player
    
    08 02 01 00 = Claimed Path Slab owned by Neutral Player
    
    08 03 01 00 = Claimed Path Slab owned by Keeper 1
    
    08 04 01 00 = Claimed Path Slab owned by Keeper 2
    
    08 05 01 00 = Claimed Path Slab owned by Keeper 3
    
    08 06 01 00 = Claimed Path Slab owned by Keeper 4
    
    08 07 01 00 = Claimed Path Slab owned by Keeper 5
    
    08 08 01 00 = Claimed Path Slab owned by Unknown
    
    09 03 01 00 = Reinforced Wall Slab owned by Keeper 1
    
    0A 02 01 00 = Treasury owned by Neutral Player
    
    0B 02 01 00 = Lair owned by Neutral Player
    
    0C 02 01 00 = Portal Slab owned by Neutral Player
    
    0D 02 01 00 = Hatchery owned by Neutral Player
    
    0E 01 01 00 = Dungeon Heart Slab owned by Good Player
    
    0E 02 01 00 = Dungeon Heart Slab owned by Neutral Player
    
    0E 03 01 00 = Dungeon Heart Slab owned by Keeper 1
    
    0F 02 01 00 = Library owned by Neutral Player
    
    10 02 01 00 = Training Room owned by Neutral Player
    
    11 02 01 00 = Wooden Bridge owned by Neutral Player
    
    12 02 01 00 = Guard Room owned by Neutral Player
    
    13 02 01 00 = Workshop owned by Neutral Player
    
    14 02 01 00 = Prison owned by Neutral Player
    
    15 02 01 00 = Torture Chamber owned by Neutral Player
    
    16 02 01 00 = Temple owned by Neutral Player
    
    17 02 01 00 = Graveyard owned by Neutral Player
    
    18 02 01 00 = Casino owned by Neutral Player
    
    19 02 01 00 = Combat Pit owned by Neutral Player
    
    1A 02 01 00 = Stone Bridge owned by Neutral Player
    
    1C 01 01 00 = Hero Gate (Final) owned by Good Player
    
    1E 02 01 00 = Edge of Map Slab owned by Neutral Player
    
    1F 02 01 00 = Unclaimed Mana Vault Slab owned by Neutral Player
    
    20 03 01 00 = Claimed Mana Vault Slab owned by Keeper 1
    
    21 01 01 00 = Hero Gate (2x2) owned by Good Player
    
    22 01 01 00 = Hero Gate (Front End 3D Level) owned by Good Player
    
    23 01 01 00 = Hero Lair Slab owned by Good Player
    
    24 01 01 00 = Hero Stone Bridge owned by Good Player
    
    25 01 01 00 = Hero Gate (3x1) owned by Good Player
    
    28 02 01 00 = Mercenary Hero Portal Slab owned by Neutral Player
    Last edited by Metal Gear Rex; August 16th, 2017 at 22:15. Reason: undeleted

  2. #2

    Default Re: Reversal of DKII Binary File Formats

    The map element block on disk looks as follows:

    struct Element {
    BYTE idTerrain; /* lookup into Terrain kwd with id (BYTE at Terrain Block 0x1d6) */
    BYTE idPlayer; /* lookup into Players kld with id (BYTE at Player Block 0xa8) */
    BYTE flags; /* only a '2' bit here is interpreted to do anything special at load, 1 may indicate 'valid', but it is not interpreted as such */
    BYTE unused; /* as you suspected */
    };

    The flags 2 bit being set assigns an as yet unknown flag in the runtime map element (0x1000 in WORD at 8, the lower 24 of which correspond to the Tag Id of the player owner).

    I've been upside down inside of this executable for the past year and a half. What else do you want to know?

  3. #3

    Default Re: Reversal of DKII Binary File Formats

    I have most of the code execution for level/resource loading mapped out. I will be posting a kwd/kld loading framework to github after some cleanup, with all that I know about the on disk game structures.

    If you happen to know of any particular crash locations (any trace information would be invaluable), assuming we're talking about 1.7 (I don't exactly know all the conventions used for executable versioning by the community), let me know. If I can reproduce a crash, I can probably tell you why it's happening.

    And I'm just doing a manual decompile into C++, not any sort of binary reuse. 52k lines and counting, I'm pretty sure I can see the matrix at this point.
    Last edited by werkt; March 19th, 2014 at 21:35. Reason: Actually answering the technique question

  4. #4

    Default Re: Reversal of DKII Binary File Formats

    https://github.com/werkt/kwd - Enjoy. Consider the unannotated structures an exercise left for the reader.

  5. #5

    Default Re: Reversal of DKII Binary File Formats

    I've already kind of done all this, all you had to do was ask.

  6. #6

    Default Re: Reversal of DKII Binary File Formats

    Dark Light, where is your code?

  7. #7

    Default Re: Reversal of DKII Binary File Formats

    I'll post my editor and outline the format when I get a chance.

  8. #8

    Default Re: Reversal of DKII Binary File Formats

    Here is the format that I found when I created my editor.

    Map ->
    (0,1) - (n,1)
    (0,n) - (n,n)

    8 - 11: Size of file w*h*4+36
    20 : height
    24 : width
    32 - 33: Size of map w*h*4
    Little-endian

    Things to note is that there is a 36 byte header. The map itself uses 32 bit values, the first byte (or last depending which way you want to look at it) is the block type, the second byte is the owner of the block, 1 good, 2 hero (I think, it's the same order as in the official editor), then 3, 4, 5 and 6 are players (again same order as the editor). The third and forth are unused as a result of 32 bit. Also note, there are two mana vaults.

  9. #9

    Default Re: Reversal of DKII Binary File Formats

    Quote Originally Posted by Dark Light View Post
    Things to note is that there is a 36 byte header.
    This is what my code deals with, in addition to providing the rest of the asset structures.

    The keeper world/level data format is organized as follows:

    field:
    uint32_t code; /* table below */
    uint32_t size; /* size in bytes of content */
    uint8_t content[size]; /* content */

    code above is n * 10 for the following values:

    10 = Map
    11 = Terrain
    12 = Rooms
    13 = Traps
    14 = Doors
    15 = KeeperSpells
    16 = CreatureSpells
    17 = Creatures
    18 = Players
    19 = Things
    20 = (also Things, but no 200 code)
    21 = Triggers
    22 = Level
    23 = Variables
    24 = Objects
    25 = EffectElements
    26 = Shots
    27 = Effects

    Each block is followed by either another block, or the end of file.

    For m in n * 10 + m, the content is usually as follows:

    0 = total size of the field content (e.g. 250, 4, 2048 would appear in a 2048 byte file with EffectElements)
    1 = a header with a count of the related items, along with some other version or timestamp related fields (e.g. 251, 28, 67 would appear in a file with 67 defined EffectElements). kudos to anyone who discovers what the rest of the fields are, they're definitely meaningless (uninterpreted) at asset load time by game executable.
    2 = the content of items, concatenated. The size of individual items here is (usually) the content size / item count from m = 1

    Notable exceptions are Things (with a variety of field codes, see kwdThings in my code) and Triggers, with separate codes for actions and whens.
    These codes usually follow one another in sequence, making up the "36 byte header" present in the map and many other files. n * 100 + 0, 4, <size>; n * 100 + 1, 28, <count>, <24 more bytes>; n * 100 + 2, <size - 36>, <content>; EOF, describes most of the asset files completely.
    Last edited by werkt; March 26th, 2014 at 05:32. Reason: fixed math, * 10, not * 100

  10. #10

    Default Re: Reversal of DKII Binary File Formats

    Pulled GIM and patched for this.

    Have not had any luck reproducing, tried a myriad of options and settings. I drop there, he drops, I drop more, he drops more, I drop it all, battle ensues, win, never a crash.

    Incidentally, I did find a crash in 1.7 that does not appear in GIM related to combat pit building.
    The same problem does not appear to happen with 1.51, however the "stamp room" effect I noticed does not play in GIM as the room progresses through the tiles.
    I've mapped out the path to that crash, and was able to recognize a path along a player update routine, so I bet I can pick out a crash if you can get me an address (running DK2 in any debugger should be able to at least get you that much for your crash).

Similar Threads

  1. Questions about the reversal of stuff
    By DragonsLover in forum KeeperFX
    Replies: 61
    Last Post: April 16th, 2014, 21:32
  2. LOG file improvement
    By jomalin in forum KeeperFX
    Replies: 10
    Last Post: June 15th, 2011, 21:54
  3. Help me by uploading a file
    By f0wh in forum DK2 Troubleshooting
    Replies: 0
    Last Post: January 26th, 2011, 02:10

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •