Closed CouldBeWolf closed 8 years ago
Maybe either check all txt files and add them to however the current info is stored, or check for txt file for each title at the same time it makes the list of titles?
I double checked the code - the txt files are authoritative (there's no separate database it syncs). I tried to match the rules that Luma uses.
If you don't mind can you upload a .zip file with your locales folder (or at least one file that's failing and one that's working)? I suspect there is something different between the files (encoding, file name, or something). I should be able to figure that out by looking at the file.
On that note, did you edit the files with Windows notepad? The line endings ("\r\n" vs "\n" vs no ending) shouldn't matter, but notepad likes to drop "BOM"s in the file if you specify any unicode encoding. If that's the case I don't think Luma would read it correctly either though.
I guess if LLS is deleted by later installed again, everything would also show as default with current version.
Can you verify that? I don't think that will be the case... I've removed and reinstalled it a number of times.
As far as I could tell, none of the ones I imported showed. I'll test some and then upload something.
-snip-
Figured it out, it's stored in the txt file, but it won't show up in regular notepad. It showes up in notepad++ as NUL. And it's 0A 00 in hex.
I'll include a link to 2 different locales files. One is Mario Kart that shows up in LLS, and the other one is Mutant Mudds Super Challenge. You can see that the one for Mario Kart have extra info.
https://mega.nz/#!ghsmHZqQ!3p8-AvFpseFEx-v_9lBTHdk_OOIJdr_zZD1ygGL-PbQ
Ok, I see what you're talking about... just to confirm, the one with the garbage at the end is the one that LLS is able to read, and the other on isn't read, right? And both are read by the Luma CFW?
The 0A I think is fine - it's just a line feed (which might show up funny if your editor is expecting CRLF - Windows style - line endings) but that last byte is a NUL. This is because I'm writing 8 bytes and the buffer is only 7 bytes long. The fix for that is to write only 7 bytes.
As for why it's not reading the other file... I'll have to test but I suspect it's expecting 8 bytes (it tries to read 8 bytes, but I didn't explicitly test what happens if fewer). I think the fix will be to only read in the first 6 bytes.
Can you build? I pushed a fix to master. It compiles but I can't test it since I don't have my 3ds with me right now.
Actually, here's a build if you want to test:
Keep in mind I didn't test so it might be a good idea to back up your locales directory before you try it.
Yes. LLS is the one with "garbage" at the end.
Well, I tested it. It creates new files, but they are not used at all by Luma3DS. And everything shows up as "system default" regardless of what created the txt file.
PS: I haven't currently installed the tools, but I can manage to set it up and build.
This build should fix it. Can you report back?
One note, this won't fix the garbage in existing files, since it overwrites them in place and only writes the first 6 bytes. So if that bothers you you'll want to actually delete the files altogether. That said, the NUL byte shouldn't hurt anything if you choose to leave it there (since the Luma CFW, and now LLS only read/write the first 6 bytes).
Thanks.
All looks good here.
PS: It seems slower loading titles, but that's to be expected I guess. PPS: Or it's just me having more titles to load. That's also likely
Txt files that are placed in the locales folder are not checked for information. So then the program show default even if it has a txt settings file.
Maybe either check all txt files and add them to however the current info is stored, or check for txt file for each title at the same time it makes the list of titles?
I guess if LLS is deleted by later installed again, everything would also show as default with current version.