In many cases it will not save your changes correctly. Using the 1.4.5 version does not work perfectly, it just doesn't show any errors.

What changes did you make that led to the crash? Point 3/4: I suspected they were arrays, and if you look at the turns editor source you'll find that back then I still called them arrays, but at some point in the days between the turns editor and the esf editor I wasn't sure anymore about that, so I renamed them. Point 2: I hadn't encountered the type 9 in my save game, so I never put it in.

Point 1 does need checking, I don't change the ids of the strings (but the order can change, so the string list part of esfs are not byte-exact), but there might be problems when people copy/paste from one esf to another. OK, Binary46 is array of bytes, so it's *technically* binary data, but in any case all should be supported.Thank you for the code review taw. OK, Binary46 is array of bytes, so it's *technically* binary data, but in any case all should be supported. esfxml still doesn't decode 0x43 short arrays.īy the way none of BInary4X types are 'binary data' - they're all arrays of basic types.

ETW esfs never contained 0x03 (just another uint16 or uint16), but they contained 0x43 arrays in a few places - and at least we know for sure how to decode them.

I've just discovered it and didn't have time to add support for it to esfxml. It is probably one of: Uint64, Int64, or Double - no way to tell as long as all examples are all-zeroes.

S2TW's save games also contain node type 0x09.

esf2xml convert them correctly, but leaves unused entries to make esf->xml->esf conversion byte-exact, and therefore to make testing a lot easier.

I don't know if you ever remove things from that enumeration, or rearrange it. They must be decoded and reconverted if you change string/ascii enumeration at the end of file.

Types 0x4e and 0x4f are arrays of strings / ascii respectively.

Looking at source code, I can see a few issues:

Shogun 2 esf editor