Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
That is definitely it; amazing! I'm just going to touch that up in Hex Workshop and it should do the trick. Hold tight.
Edit: Interesting. Replaced the board inside battle_pack.bin and it's still not updating. Where else can this be pointing to?
Not particularly, no. Basically just cut/paste jobs when someone knowlegable points out where to look.
Yeah, tried it and it didn't work for me either.
Perhaps this is one of the occassions where the localised versions of the bin files DO come into play? After all:
And there are localised versions of battle_pack.bin.
(By the way, as I have said: if we can crack this mystery we have probably cracked custom licence nodes)
I'm wondering if the localisation isn't just a simple case of strings, but rather a custom letter "grid lookup" sort of system (it would explain why grep didn't return any results for spell/item names, and there is an A-Z and a-z pattern further in the file).
Now that localised files are confirmed to be important for battle_pack.bin (but not for the board_{x}.bin files), what happens if you replace just the relevant bytes in your localised language directory?
Well, the localized version of battle_pack.bin has more lines than what I assume is the "international" file. Replaced the bytes and packed it by itself; no change. Maybe the /in/ version needs to have the same bytes modified in conjunction?
Perhaps.
In which case the next puzzle is "How is priority handled?". Clearly there is some handling of that as not all localisation directories have every file. My guess is each section has its own header of sorts, and the priority handling is dependent on each "section" -- some prioritise /in/ over localised, others localised over /in/. A cookie to anyone who can solve this.
By the way... If you're playing around with this sort of thing and fancy picking up from where I left off with licence definitions, here is the link to the spreadsheet again for analysing licence data:
https://pastebin.com/Ym2DBSpE
Not sure I posted that version earlier -- I know I did in the Discord chat, but not sure if I did here -- but the version I have just linked is the most recent one fixing an earlier derp I made.
edit: another theory I have is that there is some parity check done; if it fails, it falls back to license_board.bin. Similarly, for licence definitions, it falls back to license_data.bin. Though the fallback only occurs if there is a mismatch between /in/ and localised files in the relevant sections (or the section is missing), otherwise it utilises what is inside battle_pack.bin, license_data.bin, etc.
The only difference is the first time every localization was written over with the bin from /in/.
No, but I did manage to remove the L3 map when mucking about that json as well as parametersmanageruisizestruct.csv. That corner minimap might be somewhere else entirely, but I'll keep looking later.
That's basically where I'm at, I've tried to look around but all I've managed is breaking weird stuff:
https://cdn.discordapp.com/attachments/412582927344336896/412583057095393280/unknown.png
Lol, I can't wait to see a "EVERY NPC IS NOW VAAN" mod.
More like the "I’m Captain Basch fon Rosenburg of Dalmasca!" mod. Replace all their lines and animations with that.
Edit: Though that is one way to make Vaan relevent to the story.
https://www.youtube.com/watch?v=vSyfGm6wXgs