currently translating unchained blades exxiv

Discussion in 'PSP - Hacking & Homebrew' started by kaikaiser, Aug 12, 2015.

  1. sephurchin

    sephurchin GBAtemp Regular

    Member
    237
    95
    Sep 28, 2015
    United States
    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?
     
    Last edited by sephurchin, Aug 16, 2016
  2. flame1234

    flame1234 GBAtemp Advanced Fan

    Member
    727
    409
    May 17, 2009
    United States
    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

    1.png

    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.
     
  3. sephurchin

    sephurchin GBAtemp Regular

    Member
    237
    95
    Sep 28, 2015
    United States
    Great news!! That would explain why the game crashed when I tried. Looks like we are finally making head way with this. Great job.
     
  4. flame1234

    flame1234 GBAtemp Advanced Fan

    Member
    727
    409
    May 17, 2009
    United States
    sephurchin likes this.
  5. sephurchin

    sephurchin GBAtemp Regular

    Member
    237
    95
    Sep 28, 2015
    United States
    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.
     
  6. BlackDog61

    BlackDog61 Advanced Member

    Newcomer
    80
    75
    Nov 30, 2013
    Indonesia
    Have you tried without any modification?
    What do you mean by that?
    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?
     
    sephurchin likes this.
  7. flame1234

    flame1234 GBAtemp Advanced Fan

    Member
    727
    409
    May 17, 2009
    United States

    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.
     
    sephurchin likes this.
  8. sephurchin

    sephurchin GBAtemp Regular

    Member
    237
    95
    Sep 28, 2015
    United States
    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.
     
  9. flame1234

    flame1234 GBAtemp Advanced Fan

    Member
    727
    409
    May 17, 2009
    United States
    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.
     
    sephurchin likes this.
  10. sephurchin

    sephurchin GBAtemp Regular

    Member
    237
    95
    Sep 28, 2015
    United States
    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.
     
  11. BlackDog61

    BlackDog61 Advanced Member

    Newcomer
    80
    75
    Nov 30, 2013
    Indonesia
    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).
     
  12. flame1234

    flame1234 GBAtemp Advanced Fan

    Member
    727
    409
    May 17, 2009
    United States
    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.
     
    Last edited by flame1234, Aug 18, 2016
    kaikaiser likes this.
  13. BlackDog61

    BlackDog61 Advanced Member

    Newcomer
    80
    75
    Nov 30, 2013
    Indonesia
    I agree. Couldn't find a better method so far.

    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. ;)

    Yep, it looks perfect to that regards. Thanks!

    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.

    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?
     
    kaikaiser likes this.
  14. flame1234

    flame1234 GBAtemp Advanced Fan

    Member
    727
    409
    May 17, 2009
    United States
    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:
    Capture.JPG

    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.
    Capture1.JPG
    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.
    NPJH50648_00012.jpg

    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
     
    Last edited by flame1234, Oct 6, 2016
    kaikaiser likes this.
  15. kaikaiser
    OP

    kaikaiser GBAtemp Regular

    Member
    145
    52
    Aug 12, 2015
    United States
    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.
     
  16. robin5968

    robin5968 Newbie

    Newcomer
    1
    0
    May 15, 2017
    Taiwan
    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
     
    Last edited by robin5968, May 18, 2017
  17. Guren no heya kara

    Guren no heya kara Advanced Member

    Newcomer
    53
    11
    Jul 8, 2014
    Italy
    I really hope that this gets finished in a way or another.
     
  18. Tenacious Dingo

    Tenacious Dingo Newbie

    Newcomer
    8
    0
    Feb 20, 2016
    Cote d'Ivoire
    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.
     
  19. ArianNuhan

    ArianNuhan Member

    Newcomer
    24
    7
    Mar 11, 2017
    Bulgaria
    bumping in the hopes it gets some attention.
     
  20. kaikaiser
    OP

    kaikaiser GBAtemp Regular

    Member
    145
    52
    Aug 12, 2015
    United States
    Thank you black dog this was a huge help