Digimon World Re:Digitize

[Cloud452]

999 files located in the "INSDIR", sample file: 00000001.BIN

[Falo]

This is the wrong file ^^
the INSDIR is for data installation, you need to extract the decrypt key from EBOOT.BIN and decrypt all files with JPCSP Connector.

The real bigfile is ARCV0.BIN + file table -> ARCVINFO.BIN it contains all files unencrypted with real filename + path.

I already finished an extracting tool, and i'm working on a text translation tool

tool + source (.NET): http://www.mediafire.com/download.php?sb74rim5hj38oa7

here the ARCVINFO.BIN format: (some structs are incomplete, but you can extract all files with it)

Code: Select all

//--------------------------------------
//--- 010 Editor v3.2.1 Binary Template
//
// File:
// Author:
// Revision:
// Purpose:
//--------------------------------------
struct{
    char magic[4];
    int unk1;
    int numFiles;
    int szSector;
    int szFile;
    int unk4;
    int unk5;
    int unk6;
    struct{
        struct ENTRY entry[numFiles]<optimize=false>;
    }Files;
}VCRA;

struct ENTRY{
    local int fTemp;
    int Size;
    int unk1;
    int ofsFileName;
    int Offset; // sector
    int ofsMARV;
    int ofsData;
    fTemp = FTell();

    FSeek(ofsFileName);
    char Filename[];

    if (ofsMARV)
    {
        FSeek(ofsMARV);
        struct MARV marv;
    }

    if (ofsData)
    {
        FSeek(ofsData);
        struct DATA data;
    }

    Printf("%d;%d;%s\n",Offset*0x800,Size,Filename);
    FSeek(fTemp); // go back to filetable
};

struct MARV{
    char magic[4];
    int unk1;
    int unk2;
    int unk3;
    int unk4;
    int unk5;
    int unk6;
    int unk7;
};

struct DATA{ // not finished
    int unk1;
};

[StorMyu]

Omg guys, the game just came out yesterday and my pre-order still isn't here, what the fuck ?

[irony]Oh yes piracy... my bad[/irony]

And just in case, please don't do a menu patch, it's really horrendous !

[Falo]

And just in case, please don't do a menu patch, it's really horrendous !

Why not ?

My text editor is nearly finished, only saving edited text makes problems (game uses some text length based padding...)
But i can export every text in the game as csv and edit it with excel.

map\text\*text.pack = all story/npc text
Keep\LanguageKeep_jp.res = all menu, item, ... text


here the text file structure:
works with all *text.pack files, only LanguageKeep_jp.res has an extra Pack Header, remove it and it should work too...

Code: Select all

//--------------------------------------
//--- 010 Editor v3.2.1 Binary Template
//
// File:
// Author:
// Revision:
// Purpose:
//--------------------------------------
local int i;
struct KCAP pack;

struct KCAP{ // PACK Header, LanguageKeep_jp has 2 Pack header
    char magic[4];
    int unk1;
    int szPack;
    int unk2;
    int numFiles;
    int unk3;
    int ofsFT;
    int unk4;

    FSeek(ofsFT);
    struct ENTRY entry[numFiles]<optimize=false>;
};

struct ENTRY{
    local int fTemp;
    int Offset;
    int Size;
    fTemp = FTell();
    FSeek(Offset);
    struct ChunkHeader chunk_header;
    FSeek(fTemp);
};

struct ChunkHeader{
    char magic1[4];

    if( magic1 == "BTX ") // only LanguageKeep_jp
    {
        struct BTX1 btx1;
    }
    else // all other *text.pack files have 4 Byte Size and then the magic
    {
        char magic2[4];
        if( magic2 == "BTX ")
        {
            struct BTX2 btx2;
        }
    }
};

struct BTX1{
    int unk1;
    int unk2;
    int unk3;
    int unk4; // only LanguageKeep_jp
    int numText;
    struct TEXT_HEADER text_head[numText]<optimize=false>;
};

struct BTX2{
    int unk1;
    int unk2;
    int unk3;
    int numText;
    struct TEXT_HEADER text_head[numText]<optimize=false>;

    // not in  LanguageKeep_jp
    // after the text comes 28 Byte of data, don't know what it does
};

struct TEXT_HEADER{
    local int iStart,iLen,fTemp;
    iStart = FTell();
    int ID;
    int Start;
    fTemp = FTell();
    FSeek(iStart + Start);

    wchar_t text[]; // text is common Unicode Little Endian text

    iLen = Strlen(text) *2;
    if(iLen % 4 > 0) byte padding[iLen % 4];

    FSeek(fTemp);
};

[StorMyu]

Why not ? Well most of the time you have a menu patch => Fame level +10 => Stop working on it => Project fail.
I just think it's better to give a 100% operational (by that I mean bug free) version fully translated.
But good job working on it.

Btw I'll be happy to look at the game once it'll arrived.
Also, try replacing with ASCII, see if there's a variable-width font and not just a fucked up Fixed-width one.
Because any translation with this will be horrible =/

[finale00]

Who cares whether it looks bad or not. If it looks bad then just leave the source files and have someone else continue it. Better than having to figure out how to do everything from scratch.

And much better than not bothering to develop tools because "fame +10 => project fail"
A lot of groups feel that if you're going to do something, you better do it 100% and even provide bug support. No, I think someone should provide the tools and some samples and if people don't like it they can take the tool and make a better one.

People will complain about anything anyways even if they can't do anything so there's no pleasing them.

[StorMyu]

Who cares whether it looks bad or not. If it looks bad then just leave the source files and have someone else continue it. Better than having to figure out how to do everything from scratch.

I never said something like that, and yeah having something like that is grantly appreciated. But seriously... if you don't care that it looks "bad", you really should peek at most of the difference in quality when you have something serious and just attempt to "do" something.
The first Digimon game on Psx was really a good game which this one tries to "return to THIS basic" so it looks freakin awesome to me, and thus I was asking if they really try to do a translation, to do it right. no more/no less.

No, I think someone should provide the tools and some samples and if people don't like it they can take the tool and make a better one.

That's exactly why translation project fail...
Bare minimum is: One hacker / one translator
if there is no connection between them it's messy, and the hacker can (if possible) do something to fix some troubles the translator can have (by that I mean Assembly hacking of course, because it's not just about the files...)

People will complain about anything anyways even if they can't do anything so there's no pleasing them.

When I'm doing a translation project, I'm mostly doing it for me, I'm not trying to please anyone. That's what I was talking about people who were happy to release a patch full of bug with 1% of the game translated just because they want to "please" the public which is... not a good idea.

imho a good project is a project release day one

None of this is mean btw finale00, I was just giving my opinion on that ^^

[finale00]

Hmm ya I haven't really seen any really "nice" translation projects where the translators are off doing their own thing and can do all of the art and magic that they would like.

Maybe in the future there will be more advancements in the translation scene.

[Falo]

To make this clear, i'm not going to translate this game, i know 0 about japanese, i'm just making the tools to do it...
And i finished the tool, translation works perfectly:



No text limit and it should support all unicode characters.

[finale00]

Looks pretty nice, but then again I'm not a hardcore gamer so I don't know what to look for.

How easy is it to use the tool?

[Falo]

For all *text.pack files, just open it, select what file to edit, select what text to edit and then edit it ^^
for LanguageKeep_jp.res, cut of the first 48 Byte (the first Pack Header), then translate it, re-add that 48 byte header, fix sizes.

I should make a repacker tool, i manually repacked ARCV0.BIN for this small test.
But it's very easy to use, you can export all text from one file to csv, edit it with excel/google/whatever and then reimport it and save as text.pack.

http://www.imagebanana.com/view/sotrvcp ... est002.jpg

[finale00]

Is there a way to automatically calculate the sizes of the new data and do that 48-byte header process?

[Forte]

Man, KCAP is wild. Depending on what's in the 4th int (the one you have as unk2), it's possible that there is no file table at all (example: the msh files) and of course, as the language keep file demonstrates, a KCAP can be a container for other KCAPs.

Also, both BTX are the same file format, unk2 tells you how much management info there is (if you leave out the magic number like you did, it's basically the offset of numText)

By the way, any clue how the ARCVINFO.BIN is structured? I get that the table has an entry for each file (20 bytes), but what about the part after that, the "MARV" stuff? Looks like a file table entry can have a pointer to an entry in the MARV table but doesn't have to. I'm equally clueless what the table after MARV is supposed to be. (hashes?)
I guess it doesn't matter since the edited text works anyway, but I'm just curious.

Is there a way to automatically calculate the sizes of the new data and do that 48-byte header process?

It is, but what you'll be doing is basically saying "if file == the language keep one: add extra header", but I guess that's still better than having the user do it.

(by that I mean Assembly hacking of course, because it's not just about the files...)

It's not? What part of the game would you say requires assembly hacking in this game?
There are no font related issues since they used a nice library (and even then: just edit the library). I guess some of the boxes could use some resizing, but I wouldn't anticipate an official, paid localization to even do that (similar to DW1)

[eycaramba]

Great to hear that you have nearly finished the text tools, Falo
Can't wait to play around a little. Have been a big fan of Digimon when I was younger ^.^

[Falo]

By the way, any clue how the ARCVINFO.BIN is structured? I get that the table has an entry for each file (20 bytes), but what about the part after that, the "MARV" stuff? Looks like a file table entry can have a pointer to an entry in the MARV table but doesn't have to. I'm equally clueless what the table after MARV is supposed to be. (hashes?)
I guess it doesn't matter since the edited text works anyway, but I'm just curious.

I think it has to do with how the psp handle's it's VRAM (VRAM = reversed MARV), but i can't tell what info it has, some values matches the size, but not always...

My text tool can now detect the extra pack header and writes it by saving, so only a repacking tool and it's finished.
But now that i know MARV contains size data, this could be a problem.