Structure and Class Documentation

[em_eight]

Take this struct for example:

Code:

typedef struct {
  uint8_t unknkown_0x0;
  uint8_t unknkown_0x1;
  uint8_t padding[2]; // Ignored when copying to array
  uint32_t objectId; // see http://wiki.tockdom.com/wiki/List_of_Identifiers#Items
  uint32_t numberOfItems;
  uint32_t unknown_0xc;
  uint8_t unknown_0x10;
  uint8_t padding2[3]; // Ignored when copying to array
  ItemUseType useType;
  void * useFunction; // Item is draggable if this is null
} ItemBehaviour; // Total size 0x1c

In katai, it becomes:

Code:

meta:
  id: itembehaviour
  endian: be
seq:
  - id: body
    type: body
types:
  body:
    seq:
    - id: unknown_0x0
      type: u1
    - id: unknown_0x1
      type: u1
    - id: padding_0x2
      size: 2
    - id: objectid
      type: u4
    - id: numberofitems
      type: u4
    - id: unknown_0xc
      type: u4
    - id: unknown_0x10
      type: u1
    - id: padding_0x11
      size: 3
    - id: usetype
      type: u4
    - id: usefunction
      type: u4

The useless steps being:

Code:

meta:
  id: itembehaviour
  endian: be
seq:
  - id: body
    type: body
types:

vs the lines

Code:

typedef struct {
} ItemBehaviour; // Total size 0x1c

and each field's declaration is less concise

As for the overhead, it generates a 80 line header and a c++ file that needs to be compiled (as well as depending on the katai library to build) for a struct that could've been read in one pointer dereference with the definition above just put in a header

Katai could be useful for other languages, but considering most coding done for the game above asm is in C++ (or even pure C, which katai doesn't support), it's not ideal here imo

I can get the less concise part, but that's what happens when you require precision. You would have to write additional code to enforce strict alignment for structs in C too.

Trust me there is practically no computational overhead in compiling the C files generated. You would need to compile a custom parser anyway, how is that different? If you are talking about human overhead, all of this is easily automated in Makefile/CMake/shell script or w/e.

I am not suggesting this as a stylistic preference, it is absolutely harder to read and write. I am suggesting it for additional functionality. As mkw-structures grows, no progress will be made in creating an actual memory parser. And such parser is way more complicated than wimm's tools, as those work in non-dynamic memory and do not need to do pointer-chasing. WIll there be interest for anyone to develop+debug it from scratch?
I just think that work(documentation in pseudoC+custom parser)>>work(documentation in kaitai)

Anyway, I know your effort is still very helpful and as you do it for fun I am in no position to force you do anything, so I just wanted to drop a suggestion. I am interested in the automation of extraction of large amount of data from the game, so I might join your efforts at some point