M2/.skel: Difference between revisions

From wowdev
Jump to navigation Jump to search
mNo edit summary
Line 42: Line 42:


=AFID=
=AFID=
Same structure and semantics as in [[M2#AFID_.28Legion.2B.29|M2.AFID]].
Same structure and semantics as in [[M2#AFID|M2.AFID]].


=BFID=
=BFID=
Same structure and semantics as in [[M2#BFID_.28Legion.2B.29|M2.BFID]].
Same structure and semantics as in [[M2#BFID|M2.BFID]].

Revision as of 17:29, 3 June 2019

These files replace some blocks from the M2 MD20 data. The chunks doing that have a fixed header followed by raw data, as with MD20. The headers have offsets into the respective chunk. This means that there are no fixed sizes for most chunks, and not all bytes of the chunk are actually used but include alignment and padding as well.

SKL1

struct {
  uint32_t _0x00;                       // Version? Flags? Always 0x100 as of Legion (7.3.2.25079).
  M2Array<char> name;
  uint8_t _0x0c[4];                     // Is this already part of the data? Always 0 as of Legion (7.3.2.25079).
} skeleton_l_header;
uint8_t skeleton_l_raw_data[];

SKA1

struct {
  M2Array<M2Attachment> attachments;
  M2Array<uint16_t> attachment_lookup_table;
} skeleton_attachment_header;
uint8_t skeleton_attachment_raw_data[];

SKB1

struct {
  M2Array<M2CompBone> bones;
  M2Array<uint16_t> key_bone_lookup;
} skeleton_bone_header;
uint8_t skeleton_bone_raw_data[];

SKS1

struct {
  M2Array<M2Loop> global_loops;
  M2Array<M2Sequence> sequences;
  M2Array<uint16_t> sequence_lookups;
  uint8_t _0x18[8];                     // Is this already part of the data? Always 0 as of Legion (7.3.2.25079).
} skeleton_sequence_header;
uint8_t skeleton_sequence_raw_data[];

SKPD

struct {
  uint8_t _0x00[8];                     // Always 0 as of Legion (7.3.2.25079).
  uint32_t parent_skel_file_id;
  uint8_t _0x0c[4];                     // Always 0 as of Legion (7.3.2.25079).
} skeleton_parent_data;

The parent skeleton file data id is used for de-duplication. E.g. lightforgeddraeneimale references draeneimale_hd. lightforgeddraeneimale does not have any M2/.anim files, but uses those of draeneimale_hd via parent-link (does not even have an AFID chunk). Note that it appears that the child M2/.skels still have SK*1 chunks, so apparently only *FID are shared?!

AFID

Same structure and semantics as in M2.AFID.

BFID

Same structure and semantics as in M2.BFID.