NMS_LOC1_*.MBIN files conversion issue

[Lo2k]

Hi everyone,

I just tried to rename some data labels from NMS_LOC1 files placed in the LANGUAGE folder (like "component theta" into "component v3" like in v1.0) and got some kind of mess into ingame labels (like "ship" tab name appearing as "shipdiscovered", or in options menu, planet "reports" section renamed "reportsdiscovered"). I rechecked my changes twice and finaly just converted original (french) language file into .exml then back to .mbin and noticed file size changed between original .mbin file and decompiled/recompiled one (final one is smaller). Looking into it with Hex Workshop, it seems a lot of bytes were twisted in the conversion and as far as I can see, some of them might not be really expected.

Could this be checked and confirmed ? I assume other language files might suffer the same issue.

Sorry if this was already reported. I checked most of the issues reported and I couldn't find one pointing to this one.

Best regards

PS : By the way I also edited NMS_LOC1.MBIN that seems to be a all in one languages strings file but it seems unused in game. PPS : reading more of the threads, it could be related to issue #69

[Lo2k]

edit1 : I dug a little more this morning. It seems all strings relative offsets (32bits values after each 0x1AAAAAAA) are correctly pointing to each string in the string table at the end of the .mbin But looking at .exml file before and after recompiling/redecompiling, it seems end of strings are trimmed at their end, from 1 character to more and more as further as we go down into the strings. Is there a string length value for each of them that could have not been updated correctly and that could trim them ?

There's at least a clear difference between original .mbin and decompiled/recompiled one : original has 16bytes of extra 00 after each of them in the string list while new .mbin has a variable amount of them

[Lo2k]

edit2 : OK, got it. There's indeed a string length data and as I feared, this one is not correct in the recompiled .mbin. ie : in original (french) .mbin, the first translated word string length is set to 46 (0x2E) while in the decompiled/recompiled it is set to 45 (0x2D). My strong guess is that accentuated characters (and maybe other special chars) are counted as 1byte while their real length is 2bytes.

I don't know how exactly this could be modified though (it seems to be UTF8 related). I hope this could be easily fixed :)

PS : I assume you already perfectly know it but the string length is the 3rd 32bit data after 0x1AAAAAA, first one being the relative offset to the translated string, second one being zero (always ?).

[emoose]

Should be fixed in 8bd8ce73219e4367d9c3ec9f3ac6aacc0e00c811, we weren't null terminating the VariableSizeString / dynamic strings, which isn't a problem for strings that have data but when they were missing data it was meant to put a null in it's place, because it didn't this threw a bunch of stuff off.

Let me know if its fixed for you and I'll close the issue, hopefully all should be well since the recompiled data seems to match 1:1 in the files I've tested on my end.

[monkeyman192]

The issues I was having the language mbins seems to be fixed. I haven't checked all of them (just the two english specific ones), but modifying and recompiling them works now with no side effects in the game it would appear. Thanks!

[Lo2k]

Indeed, issue is fixed. Thanks so much ! I just noticed 5 bytes changed at position 88 (decimal) from 0x00 to some (random?) value in the resulting file but it doesn't seem to be a trouble (same behavior with english and french files).

[Lo2k]

Result is online (with credits of course :)

[emoose]

I just noticed 5 bytes changed at position 88 (decimal) from 0x00 to some (random?) value in the resulting file but it doesn't seem to be a trouble (same behavior with english and french files).

That's just setting the padding to the date/time the MBIN was built:

Padding58 = ulong.Parse($"{DateTime.Now:yyyyMMddhhmm}"); // may as well make use of this field too

MBINs used to have this feature during NMS development where the build date/time was stored at 0x8, but they removed that for some reason and only early MBIN files have it set.

Seeing as 0x58 goes unused we store it there, and store a "MBINCompiler 1.0" string at 0x8, no real reason for doing this, but we may as well make use of these bytes :)

Anyway looks like this issue can be closed now, thanks for reporting it.