Open monkeyman192 opened 2 years ago
Ok, so after some recent discussions I think it's time to revisit this issue. There are some good benefits to implementing this, and the tools which use the exml data could utilise a simpler structure.
One issue to be overcome will be the issue of arrays or lists of strings. We'll need to add an extra attribute to accomodate this so that we can specify the length of the array as well as the length of the string.
It has been proposed that we use Size
to indicate the actual size of the object within the array/list (if required), and Length
or Count
to indicate the number of elements in the array (Count
being a bit more explicit in it's meaning and difference I guess)
So previously when we have something like
[NMS(Size=0x15)]
public NMSString0x10[] fieldName;
It will become this
[NMS(Size=0x10, Count=0x15)]
public string[] fieldName;
Similarly, lists will change like so
public List<NMSString0x10> fieldName;
to
[NMS(Size=0x10)]
public List<string> fieldName;
A while ago I made some changes to simplify how strings are handled in the .cs files: https://github.com/monkeyman192/MBINCompiler/commit/1425662f31d551320e1958985d338350bfac3275 This had implications I didn't fully realise at the time, and since then there has been numerous issues around this change. It has been suggested we revert back to the original mechanism. I think this should be done, but with one caveat, we introduce the
Alignment
attribute for strings that need it so that we continue to not need to include explicit padding bytes.Ie.
will get mapped to
And
will get mapped to
All others will be mapped like:
to
This will have implications to anyone using the API as the method to get the value of the string will now no longer need the
.Value()
call on the field.