Hacking currently translating unchained blades exxiv

[Deleted User]

For anyone Interested this does work. Now we have some menu images to translate. If anyone is good at editing Images let us know and we can translate and get them edit.

FLAME is it possible to make a python script to import/export the .kbd. files?

 

[flame1234]

Yes, everything is UTF-8.

I looked into this a little tiny bit.
世界は――悠久の昔から変わらない。
それは、この世界が、全知全能の\n『女神クリューネア』によって統治されて\nきたからである。
女神クリューネアこそ――世界を創りし者。
OK, those are the first three lines.

The first script file is, within all.cpk \kbd\EV00_0100.kbd

There are three boxes (or at least part of three boxes) in this screenshot.
Green: This value 0x38 seems to identify dialogue boxes. (The 0x3C bytes before this I can't make sense of. There don't seem to be any pointers.)
Blue: Experience tells me this value is referencing a voice clip. So that's something we don't need to change. You see it is 0xAC2 in the 1st, 0xAC3 in the 2nd and 0xAC4 in the 3rd.
I confirmed that this has to do with voice clips by changing the value in memory viewer.
Purple: No idea. One of these values, probably the 3rd, is the speaker ID.
Yellow: Specifies the length of the text. You multiply by 2 to get the actual length. Set your breakpoint on 0x088512E4 to watch it load the length parameter, and then multiply it by 2.

Notes:
The text is terminated with a null byte. An extra null byte is added if necessary to get an even number of bytes total for the string.
When the developer wanted "one line centered vertically within the box", 0xA (linebreak) is used as the first character. You see this in box 1 and box 3 above.

How about the repacking technique? We need to repack, without changes, and boot the game to see if it will run.

This doesn't look that hard. No way to know until we get a repacking method. Nope, this definitely works. I just modified the memory adding nulls after a line and it worked fine.
Basically you'll be limited to three characters for every 1 character used by Furyu. In practice it ends up being not much of a limit. I am pretty sure the game will ignore nulls on the end, so we'll just do it that way and there won't be a need to understand pointers.

Need that repacking method. Then repack and boot the game, without changes.

 

[Deleted User]

Yes, everything is UTF-8.

I looked into this a little tiny bit.
世界は――悠久の昔から変わらない。
それは、この世界が、全知全能の\n『女神クリューネア』によって統治されて\nきたからである。
女神クリューネアこそ――世界を創りし者。
OK, those are the first three lines.

The first script file is, within all.cpk \kbd\EV00_0100.kbd

View attachment 59131

There are three boxes (or at least part of three boxes) in this screenshot.
Green: This value 0x38 seems to identify dialogue boxes. (The 0x3C bytes before this I can't make sense of. There don't seem to be any pointers.)
Blue: Experience tells me this value is referencing a voice clip. So that's something we don't need to change. You see it is 0xAC2 in the 1st, 0xAC3 in the 2nd and 0xAC4 in the 3rd.
I confirmed that this has to do with voice clips by changing the value in memory viewer.
Purple: No idea. One of these values, probably the 3rd, is the speaker ID.
Yellow: Specifies the length of the text. You multiply by 2 to get the actual length. Set your breakpoint on 0x088512E4 to watch it load the length parameter, and then multiply it by 2.

Notes:
The text is terminated with a null byte. An extra null byte is added if necessary to get an even number of bytes total for the string.
When the developer wanted "one line centered vertically within the box", 0xA (linebreak) is used as the first character. You see this in box 1 and box 3 above.

How about the repacking technique? We need to repack, without changes, and boot the game to see if it will run.

This doesn't look that hard. No way to know until we get a repacking method. Nope, this definitely works. I just modified the memory adding nulls after a line and it worked fine.
Basically you'll be limited to three characters for every 1 character used by Furyu. In practice it ends up being not much of a limit. I am pretty sure the game will ignore nulls on the end, so we'll just do it that way and there won't be a need to understand pointers.

Need that repacking method. Then repack and boot the game, without changes.

Great news!! That would explain why the game crashed when I tried. Looks like we are finally making head way with this. Great job.

 

[flame1234]

http://gbatemp.net/threads/major_tom-explains-game-dumping-mods-on-3-60.436515/page-9#post-6580803
Try following this tutorial for repacking. I really don't think you'll be successful. But if your new file is the same size as the original, then you will be.

 

[Deleted User]

http://gbatemp.net/threads/major_tom-explains-game-dumping-mods-on-3-60.436515/page-9#post-6580803
Try following this tutorial for repacking. I really don't think you'll be successful. But if your new file is the same size as the original, then you will be.

Thanks flame. What I tried was very similar to this video. I am very familiar with these tools. Use BMS to extract .cpk and cripack to recreate. The file I got back was the same size as the original, but the game still froze at the opening. The text that I replace was also missing. I also edited directly from the .kbd file with madedit as well. Another thing I tried was to use a file explorer to open the .kbd files for direct edit. When I saved and tried to close the file, the file format changed. This was my experience with it.

 

[BlackDog61]

Thanks flame. What I tried was very similar to this video. I am very familiar with these tools. Use BMS to extract .cpk and cripack to recreate. The file I got back was the same size as the original, but the game still froze at the opening.

Have you tried without any modification?

The text that I replace was also missing.

What do you mean by that?

Another thing I tried was to use a file explorer to open the .kbd files for direct edit. When I saved and tried to close the file, the file format changed. This was my experience with it.

Could it be an editor problem? The files don't seem to contain only UTF8 text, but also a fair bit of binary. So editing with a text editor as if they were UTF8 text would likely corrupt them, right?

 

[flame1234]

Yep, works. Just the font problem left.
If possible, I would also like a narrower font so we can fit even more letters in.
Screen space is the issue. In most situations we have plenty of bytes to work with because of UTF-8 and all.

 

[Deleted User]

Yep, works. Just the font problem left.
If possible, I would also like a narrower font so we can fit even more letters in.
Screen space is the issue. In most situations we have plenty of bytes to work with because of UTF-8 and all.

OK confirmed and working. I understand now. So for the stupid question of the day, does the entire script have to be edited through a hex editor? If I am correct there are 176 files that are up the script. 4 more at the bottom with strange file name also contain a lot of text.

 

[flame1234]

Of course not. No one would ever ask you to do that.
Need help on the font problem. Would not want you to translate an entire game worth of text if that problem could not be solved.
Keep in mind there will be length limits but they will not matter most of the time. That is, you won't need the entire amount of space you're allowed most of the time.

 

[Deleted User]

Of course not. No one would ever ask you to do that.
Need help on the font problem. Would not want you to translate an entire game worth of text if that problem could not be solved.
Keep in mind there will be length limits but they will not matter most of the time. That is, you won't need the entire amount of space you're allowed most of the time.

Good to hear. Then we just wait on the font problem for now. Maybe see if we can do an image edit and insertion test.

 

[BlackDog61]

Would you share the insertion test from the video in patch format? It would be more convenient for VWF investigations (no matter from me or anyone else).

 

[flame1234]

This game is hard to work on because of CriFileSystem. No, that's inaccurate. Just another problem to be solved, it has been, see below.
I did diff of the whole ROM and it was 900+ MB (there's 1.1GB of data here).
Then I did diff of modified all.cpk vs all1.cpk (the original) and it was 212MB (there's 378MB of data in all.cpk...that's for both the original and the modified one).
The best way is probably scripts. But you need crifilesystem and we can't distribute that here.
Urk I'm doing it wrong. Let me try again. So 200MB in bytes is...
Alright, just kill it with fire. 1.2GB in bytes is...
You need to use xdelta's -B option as suggested by: http://www.romhacking.net/utilities/928/ because the default settings are not appropriate for our application. This uses a ton of memory, but it's OK. My system has 16GB of RAM...it won't be an issue. The xdelta unpacking algo uses the regular amount of RAM (i.e., not very much) so no need to worry about that.
http://www.romhacking.net/utilities/928/

http://www.mediafire.com/download/z6v54b5cxd525a5/UBE_test.xdelta
I changed the test text to be better for font hacking.
I can make a version with items and stuff inserted a little bit later. The ROM you get is 80MB smaller than the original. Some dummies (\data\movie\old) and the firmware update files have been deleted. It will still boot in PPSSPP, probably on a real PSP too.
The patch is only about 100kB. Most of the rest of the differences are due to differences between crifilesystem versions. It should not contain any copyrighted data.

When building with crifilesystem, you need the -mode=FILENAME command line option or the resulting CPK won't work in game (you get a hang at the opening loading screen). It defaults to -mode=ID which the game engine is not expecting so you get the hang.

 

[BlackDog61]

You need to use xdelta's -B option as suggested by: http://www.romhacking.net/utilities/928/ because the default settings are not appropriate for our application. This uses a ton of memory, but it's OK.

I agree. Couldn't find a better method so far.

My system has 16GB of RAM...it won't be an issue.

Lucky you. I'm less able to use my PC for a while when I generate a patch... But it works, so no need to complain.

http://www.mediafire.com/download/z6v54b5cxd525a5/UBE_test.xdelta
I changed the test text to be better for font hacking.

Yep, it looks perfect to that regards. Thanks!

I can make a version with items and stuff inserted a little bit later.

If I can just get the items patch (which I should probably look for earlier in this thread), i'll just compare them. So I'd say don't bother. I'm out of time for a little while, but i'll go have a look. As usual, not sure if I can achieve that VWF thing, but I'll give it a try.

When building with crifilesystem, you need the -mode=FILENAME command line option or the resulting CPK won't work in game (you get a hang at the opening loading screen). It defaults to -mode=ID which the game engine is not expecting so you get the hang.

Yep, noted, and works.
I've noticed the same all.cpk contents as original (all Japanese) yields a smaller size still. (But you can force offsets in UMDGen to be able to generate & run the iso). Is that also happening on your side?

 

[flame1234]

I do not use the force offsets option in UMDgen for this game, because the resulting image will be smaller. This game does not need fixed LBAs, it gets them at run time. It uses sce methods to identify LBAs rather than hardcoding.

crifilesystem games only need to get cpk LBA information once or twice (once for each .cpk file they have). I find they always use sce methods to find the LBA of the cpk file because it doesn't impact loading time. As such, it won't matter where on the ROM you put it as long as it's there somewhere.

Games with tons of files (i.e., Falcom) have lists of LBAs always resident so LBA info can be gotten quickly when UMD loading is required. crifilesystem has its TOC always resident too, I'm pretty sure. The real LBA is only a quick addiu away!

Alright, here's the test patch with various things inserted:
1) EBOOT text
2) message.csv
3) data_msg_txt.dat which, contrary to the name, is a string database. It doesn't contain messages at all!

http://www.mediafire.com/download/abbvuhmfb0gyksc/UBE_test2.xdelta

I've got my test text up on the screen here:


See VADDR? That's important, tells us where the vertex data is. Two means there's two vertices, enough to draw a square. RECTANGLES means we're going to draw a square (or box or whatever).
The other important one is SetVertexType but I'm not sure exactly what's going on. u16 texcoords mean unsigned 16-bit so 2 bytes. s16 positions mean signed 16-bit (also 2 bytes).
Let's hope and pray there's not dynamic memory for this. We go to the address that it says and look at our vertex data.

OK that didn't work at all. At 0xB4 (shorthand for 0x09C321B4 above), you see BA006C00 the tex x-position and y-position for the lower-left corner of the square. 0xB8 is 184, the distance from the left of the frame in pixels to the left side of the drawn square. 0xBE is 190, distance from the left of the frame in pixels to the right side of the drawn square. At 0xB8, you see the same numbers, this is the position. 0x6C, 108, is distance from the top of the frame to the top of the square, and 0x79, 121, is the distance to the bottom.

Basically this means it is copying a texture onto the frame, because the texcoords and positions are the same.

We need to set our breakpoint on some value in here. We need to adjust x-position, so let's pick 0x09C321B4 for a breakpoint.
We eventually get a break inside the function at 0898C78C which is writing the display list.

Is this it?
0886048C li t0,0xE
I guess t0 when 0883EA94 is jumped to.
So if t0 is -0x1, that means "use the VWF routine" so I guess we're done. Just need to message Sephchurchin.

The 2nd script file is: EV00_0200.kbd
EV00_0300.kbd is the third script file
Tutorial_Inn is the fourth
Tutorial_Navigate is the fifth
Tutorial_Master_Follower01 is the sixth
Tutorial_Master_Follower02 is the seventh
Tutorial_Menu_Master_Follower is the eighth
Tutorial_Master_Follower03 is the ninth
Tutorial_Master_Follower03 is the tenth
Tutorial_Skill is the 11th
Tutorial_Menu_Skill is the 12th
Tutorial_SkillMap is the 13th
Tutorial_Menu_SkillMap is the 14th

Routine at 088EA8AC is building battle text texture

 

[kaikaiser]

Hello everyone! Wow its been a while. I had an amazing (albeit busy) trip. Glad to be back and even more exited to see all of the hard work and effort put forth to keep this project alive. So how goes it on the script? Is anyone translating it and have you tested it beyond what you have posted? Let me know if there's anything I can do to help.

 

[robin5968]

Alright, maybe this post will no longer be concerned...... but I'm also interesed in this series.
Though my ability is only enough to make a small part of the translation, little of picture editing, testing lots of bug and little programing. I still want to help this translation and patch all done, too.

I've downloaded the online excel sheet as tsv and use with python to manually patch the data_msg_txt, message.tsv, and then reinsert with WQSG_UMD_R31, all work good.
However, a little thing that need to confirm such as change line issue as the message box is not enough, or line changed at wrong word.
(EX: Second line has only one word and not finished, then the sentence was cut and continue display at third line.)
Another thing, if run games with decrypted and patched eboot with the tsv and script, the game will get randomly crash when open some box of monster inside and finish beating them (not always).

As I read the thread from start to the end, I know that the biggest problem now is character spacing issue. Though it seems to be solved, but no one want to do this any more? QAQ

P.S
I can using both real PSP2K and PPSSPP to test it though I've just use PSP2K now. No screenshot recently due to forgot to take it back from my brother.
Sorry for poor english cause by Taiwanese orz

 

[Guren no heya kara]

I really hope that this gets finished in a way or another.

 

[Tenacious Dingo]

So, this project seems to be as dead as it gets...

RIP the dream.

Still bookmarking in the unlikely event more progress ever gets done.

 

[ArianNuhan]

bumping in the hopes it gets some attention.

 

[kaikaiser]

Hi there, Sephurchin and all!

Would it be possible to sort of list exactly what is done, to be done, and the exact blocking points?
I've re-read the thread and I'm not sure who's done what.
- It was said the data_msg_txt.dat has been taken care of, along with the eboot, in order to provide a "menu patch". is that a correct statement?
- I think I've read that re-inserting into kbd files doesn't work anymore. Could someone elaborate on this? And if we think it's a size issue, have we determined the max size that works?
- I've read something about not knowing how to handle .tpk files. Please find a suggestion below.
- Opening the CPK seems to work OK with the procedure provided by zero_g_monkey. Has this been used?
- What's the currently blocking part for the story?
- Is something blocking further progress on the "menu patch" front?

With regards to TPK files, as was mentioned, these contain (potentially among others) a collection of GIM files. I don't have an easy way of handling them, but I have a convoluted one to propose. (It's up for improvement, obviously.)
- Get TextER (texture extractor)
- Get Gimconv
- Get pngout.exe
- Save the following into extract_graphics.bat file:

@Echo[/USER] off
set GIMCONV="C:\where you put GimConv\GimConv.exe"
set PNGOUT="C:\where you put \pngout.exe"

rem Extract GIM files from binaries - could limit to window, map and graphics:
for /F "delims=" %%a IN ('dir /b *.tpk') do TextER.exe -e  "%%a" -gim

rem convert to PNG with 8-bit colour:
For /R . %%G IN (*.gim) do %GIMCONV% "%%G" -o "%%G_8.png"
rem Convert the new 8bit+Alpha PNG to 32bit PNG using pngout:
For /R . %%G IN (*_8.png) do %PNGOUT% "%%G" "%%G_32.png" /c6 /force

- run it in every directory where you have tpk files.
- Note: you could alternatively replace the first "for /F" with a "for /R" to go through all directories in a single go. Not sure it will extract things nicely, up to you.
- The result is a crapton of png files where "_8.png" files contain the raw extracted image, and "_32.png" files contain the same image, but in 32-bit-per-pixel.
- Edit _32.png files of interest in Gimp.
- IMPORTANT: Gimpwill stupidly assume these are RGB files instead of palette-driven files. So first thing after opening: menu->image->mode->indexed (and create a palette with up to 256 colors).
- Never use a new color in your edits.
- you could dump the palette too - it is just before the pixels in the TPC (see the spec.log file for the right place in the source tpk).

From what I can check, the following contain kanji/katakana:
http://pastebin.com/2xg7jsCd
(One of the files only has blurred out Japanese writings, but you can tell it's Japanese nonetheless. )

Thank you black dog this was a huge help