Repository navigation
Revert string types back to system strings #499
Description
A while ago I made some changes to simplify how strings are handled in the .cs files: 1425662
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.
public NMSString0x20A field_name;will get mapped to
[NMS(Size = 0x20, Alignment = 0x8)]
public string field_name;And
public NMSString0x10 field_name;will get mapped to
[NMS(Size = 0x10, Alignment = 0x8)]
public string field_name;All others will be mapped like:
public NMSString0xXYZ field_name;to
[NMS(Size = 0xXYZ)]
public string field_name;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.
Activity
monkeyman192 commentedon May 30, 2024
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
Sizeto indicate the actual size of the object within the array/list (if required), andLengthorCountto indicate the number of elements in the array (Countbeing a bit more explicit in it's meaning and difference I guess)So previously when we have something like
It will become this
Similarly, lists will change like so
to