Closed lobolmart closed 7 years ago
Hmm, seems like GcGameplayGlobals might be too big? I noticed this with GcGalaxyGlobals, sometimes there was padding inserted but then later on there was data declared at the same offset as the padding, so the padding was adding some extra bytes: https://github.com/emoose/MBINCompiler/commit/09d0d5a8e141ddfeb0115a871769c1c578ee4386#diff-06631c085aaa983f610cf8f52dde4aa8L139 At line 139 there's a Padding424 field, but then a few lines down there's a Unknown424 field, maybe something similar is happening here too?
3008 is the last offset for a DWORD, so that means that the size of data which is set is 3012. 12 bytes of padding at the end should make it fit the size of 3024 (BD0), but instead it inflates to 3044.
odd, i need to check this.
It might be because of some fields being out of order, like in that example I linked it seems that the field at 0x430 got declared before 0x424, which made your tool add padding from 0x424 up to it, and then your tool added the 0x424 stuff after:
// missing 12 bytes at offset 1056
// could be a subroutine, padding or something that the parser skipped
[NMS(Size = 0xC, Ignore = true)]
public byte[] Padding424; // offset: 1060, sz: 12, comment: auto padding
public float Unknown430; // offset: 1072, sz: 4, origin: 1065353216, parsed: 1 // line: *(_DWORD *)(v7 + 1072) = 1065353216;
public float Unknown424; // offset: 1060, sz: 4, origin: 1065353216, parsed: 1 // line: *(_DWORD *)(v7 + 1060) = 1065353216;
Just checked with the exe to confirm and it seems like that's the case, for GcGalaxyGlobals at least anyway, not sure if it's the same issue here but this is what was inflating GcGalaxyGlobals:
*(_DWORD *)(v7 + 0x420) = 0x3F800000;
*(_DWORD *)(v7 + 0x430) = 0x3F800000;
*(_DWORD *)(v7 + 0x424) = 0x3F800000;
*(_DWORD *)(v7 + 0x428) = 0x3F800000;
yep understood, there is definitely no check for out-of-order offsets. i need to manually edit the input file to make them in-order and delete any cases of multiple operations on the same offset, in that matter.
looking for the issue in GcGameplayGlobals.
Did a quick check and it seems like the problem might be in GcShipHUDTargetData:
// missing 16 bytes at offset 1008
// could be a subroutine, padding or something that the parser skipped
[NMS(Size = 0x10, Ignore = true)]
public byte[] Padding3F4; // offset: 1012, sz: 16, comment: auto padding
public float Unknown404; // offset: 1028, sz: 4, origin: 1038039908, parsed: 0.109 // line: *(_DWORD *)(v1 + 1028) = 1038039908;
public float Unknown408; // offset: 1032, sz: 4, origin: 1065353216, parsed: 1 // line: *(_DWORD *)(v1 + 1032) = 1065353216;
public float Unknown40C; // offset: 1036, sz: 4, origin: 1065353216, parsed: 1 // line: *(_DWORD *)(v1 + 1036) = 1065353216;
// line: result = 0i64;
public float Unknown400; // offset: 1024, sz: 4, origin: 0, parsed: 0 // line: *(_DWORD *)(v1 + 1024) = 0;
// missing 12 bytes at offset 1024
// could be a subroutine, padding or something that the parser skipped
[NMS(Size = 0xC, Ignore = true)]
public byte[] Padding404; // offset: 1028, sz: 12, comment: auto padding
There might be more to it though, a small hack I use to check these quickly is to just comment out a lower part of the structure, then rerun the TestTemplateSizes test, see what size it gives and compare it to the last field I commented out, if it matches then comment out a lower portion etc until it doesn't, then you should be able to work out the problem area.
i've improved the parser a little and added some manual edits here and there. the size checks should pass now.
Good stuff, glad you got it sorted, I'll look into the child templates for these later.
GcShipHUDTargetData & GcShipHUDTargetIconData have instances in GcGameplayGlobals.