The problem is hkArray<hkStringPtr>.
This appears in hkx as a null-terminated string, but I am having a very hard time fixing it because the rules for the correct binary data are not clear at all.
Knowledge of hkStringPtr
field: hkArray<hkStringPtr> <- written consecutively without align16
field: hkStringPtr <- align16
The rule I am assuming:
String\0String\0
Actual:
String\0\0String\0 <- What the heck is this pattern?
No matter how many times I try with hkxcmd, I can't figure out the rule at all, because it separates when \0 comes twice and when it doesn't.The data will be the same no matter how many times it is converted below. In other words, a mysterious rule with reproducibility.
In the case of hkArray, it is align2. (This is the second bug)
Arrays not of type Ptr in hkArray also had to do align16 after serialization was done, but they didn't (this is the third bug).
I'm done now and all hkx in DMCO.hkx are reproducible.
Version
0.3.1
Reproducible errors
The problem is
hkArray<hkStringPtr>
. This appears in hkx as a null-terminated string, but I am having a very hard time fixing it because the rules for the correct binary data are not clear at all.Knowledge of hkStringPtr
field: hkArray<hkStringPtr>
<- written consecutively without align16field: hkStringPtr
<- align16The rule I am assuming:
String\0String\0
Actual:String\0\0String\0
<- What the heck is this pattern?No matter how many times I try with hkxcmd, I can't figure out the rule at all, because it separates when \0 comes twice and when it doesn't.The data will be the same no matter how many times it is converted below. In other words, a mysterious rule with reproducibility.
I don't see how to fix it because I don't know the regularity of it.
Expected behavior
Rule Clarification
Relevant log output
No response