Currently, all unknown fields are named as 'Unknown' with an offset suffix such as 'UnknownC'
This is problematic when the NMS version changes and fields are moved, removed or added as every UnknownXXX gets renamed. It's not possible/simple to correlate these fields with their successor versions without human intervention.
The simple way to fix this is to use field indices for a suffix instead of their offset.
Example, if the struct is:
int Foo
int Unknown4
float Bar
float UnknownC
it should be:
int Foo // Field 0
int Unknown1 // Field 1
float Bar // Field 2
float Unknown3 // Field3
Each time the NMS version changes, those indices would stay the same, so if Unknown1 moves to the 5th field position, it's still labelled Unknown1 (the first Unknown that was discovered). Newly added fields would follow after the last known field (even if that last known field no longer exists). I might need to explain this better.
This would improve things from one version to the next but across many versions, it will still be problematic.
Possibly a better way to handle this would be to include some new parameters in the EXML providing details of which NMS version the field is available in and what their offset should be for that version. I'd guess this would be done with Attributes in the source.
This could also be combined with the above suggestion, so that if people refer to Unknown1 for some particular MBIN, it's always the same between versions.
EXML Example:
<!-- Moved from offset 0x04 in v1.33 to 0x10 in v1.35 -->
<Property name="Unknown1" value="0" v133Offset="4" v135Offset="16" />
Perhaps including the offsets in the EXML could be optional, since they would really only be needed when porting a mod between versions.
Currently, all unknown fields are named as 'Unknown' with an offset suffix such as 'UnknownC' This is problematic when the NMS version changes and fields are moved, removed or added as every UnknownXXX gets renamed. It's not possible/simple to correlate these fields with their successor versions without human intervention.
The simple way to fix this is to use field indices for a suffix instead of their offset. Example, if the struct is:
it should be:
Each time the NMS version changes, those indices would stay the same, so if Unknown1 moves to the 5th field position, it's still labelled Unknown1 (the first Unknown that was discovered). Newly added fields would follow after the last known field (even if that last known field no longer exists). I might need to explain this better. This would improve things from one version to the next but across many versions, it will still be problematic.
Possibly a better way to handle this would be to include some new parameters in the EXML providing details of which NMS version the field is available in and what their offset should be for that version. I'd guess this would be done with Attributes in the source. This could also be combined with the above suggestion, so that if people refer to Unknown1 for some particular MBIN, it's always the same between versions.
EXML Example:
Perhaps including the offsets in the EXML could be optional, since they would really only be needed when porting a mod between versions.