Investigate MBIN.PC / TkGeometryData oddities

[emoose]

So far what I've noticed:

• Magic set to 0xDDDDDDDD instead of 0xCCCCCCCC
• Data at 0x8-0x10 set to 0xFFFF... (normally 00, but some files have data here which looks to be a build date, e.g. inside GCDEBUGOPTIONS.GLOBAL.MBIN this data is 06 C3 B9 F0 2E 00 00 00, which as an int64 becomes 201607201542)
• Data at 0x58-0x60 set to 0xFEFE... (normally 00)
• List magic set to 01 00 00 00 instead of 01 AA AA AA

Probably some other differences too, will have to look into these further.

EDIT: cc29d10 should fix reading lists that use 01 00 00 00 magic, though it doesn't write lists using that magic yet, need to check if we actually need to or whether the game will still work with us using 01 AA AA AA inside MBIN.PC files.

[yretenai]

What if the list magic is actually 1 byte and 3 padding bytes?

Do "normal" lists still load normally by the client with the AAAAAA bytes set to 000000?

The templates seem to skip over the last four bytes entirely.

[emoose]

Hmm, well if the AA AA AA part was padding I'm not sure why that'd be set to AA AA AA while other padding bytes in the same file are 00, could be a compiler quirk I guess.

I've got a feeling that the compiler for models is different to the compiler for the other files, mostly because of the MBIN header differences, perhaps the plugin they use for exporting models to MBIN is from a different codebase than their main MBIN compiler.

Do "normal" lists still load normally by the client with the AAAAAA bytes set to 000000?

Haven't tried that but it might be worth a go, like you said it doesn't seem like this "magic" gets checked by the game, though MBINCompiler checks it just to make sure it's not reading an invalid list, helps a lot to get template structures right.

EDIT: Actually you might be onto something with the data being padding, in TkAnimMetadata it uses 01 FE FE FE instead of the others, and it looks like FE is being used as padding throughout the file too, hmm..