Hacking Digimon World Re:Digitize - Translation

[Romsstar]

We are way beyond such problems. Such problems I can already solve myself. But here we have a real problem.
Guys what is at matter here is :

You have an archive format with a corresponding filelist. Those two are separate files.
The one containing the content, the other the filesizes and offsets of the big archive.
Your task is to develop a tool that not only reads and inserts text correctly (This is where most programmers fail already), but after that is done you have to check if the file inside the archive got bigger.
If it did(who am I kidding few programmers got even that far), this is where the fun starts: You have to increase the reserved space for that file (in ARCVINFO.BIN otherwise = freez) but because the files are stores sequentally you have also to update the offsets of all the other files that come next, otherwise your bigger file will corrupt the next sequence.

So you basically recreate a format but after recreating it you have to recreate the archive itself as well but you have to make sure that you don't mess up the filetable otherwise you will have freezes.
Now programmers: Your turn. I start to believe if anyone, than only Roxas can do this.


I basically know everything that needs to be done, but the only programming languages I know are scripting ones and those are not exactly fit for that task.

 

[GamerzHell9137]

We are way beyond such problems. Such problems I can already solve myself. But here we have a real problem.
Guys what is at matter here is :

You have an archive format with a corresponding filelist. Those two are separate files.
The one containing the content, the other the filesizes and offsets of the big archive.
Your task is to develop a tool that not only reads and inserts text correctly (This is where most programmers fail already), but after that is done you have to check if the file inside the archive got bigger.
If it did(who am I kidding few programmers got even that far), this is where the fun starts: You have to increase the reserved space for that file (in ARCVINFO.BIN otherwise = freez) but because the files are stores sequentally you have also to update the offsets of all the other files that come next, otherwise your bigger file will corrupt the next sequence.

So you basically recreate a format but after recreating it you have to recreate the archive itself as well but you have to make sure that you don't mess up the filetable otherwise you will have freezes.
Now programmers: Your turn. I start to believe if anyone, than only Roxas can do this.


I basically know everything that needs to be done, but the only programming languages I know are scripting ones and those are not exactly fit for that task.

Well there is SkyBladeCloud, maybe he can help you?
He's a temper too and he hacked FF Type-0.

 

[Gürkan]

Wow

 

[SkyBladeCloud]

[EDITED]

Good luck, you'll need it.

 

[Normmatt]

We are way beyond such problems. Such problems I can already solve myself. But here we have a real problem.
Guys what is at matter here is :

You have an archive format with a corresponding filelist. Those two are separate files.
The one containing the content, the other the filesizes and offsets of the big archive.
Your task is to develop a tool that not only reads and inserts text correctly (This is where most programmers fail already), but after that is done you have to check if the file inside the archive got bigger.
If it did(who am I kidding few programmers got even that far), this is where the fun starts: You have to increase the reserved space for that file (in ARCVINFO.BIN otherwise = freez) but because the files are stores sequentally you have also to update the offsets of all the other files that come next, otherwise your bigger file will corrupt the next sequence.

So you basically recreate a format but after recreating it you have to recreate the archive itself as well but you have to make sure that you don't mess up the filetable otherwise you will have freezes.
Now programmers: Your turn. I start to believe if anyone, than only Roxas can do this.


I basically know everything that needs to be done, but the only programming languages I know are scripting ones and those are not exactly fit for that task.

Those are two separate things... Your talking about the ARCV0.BIN/ARCVINFO.BIN which is the main archive however that's not needed in a text editor tool... In my mind those would be separate tools. The ARCV0.BIN/ARCVINFO.BIN is indeed quite complex and I wouldn't like to do much with that myself. The .res/.text files however are much simpler in comparison and are what needs to be edited to make a text editor.

 

[Cryum]

Wow, this is the first time seeing how the programs work, but that's intense. Are you allowed to put these on your resume? Seems like a good way to show your ability to program as well as work with others. I need to take more programming classes...

 

[Romsstar]

Those are two separate things... Your talking about the ARCV0.BIN/ARCVINFO.BIN which is the main archive however that's not needed in a text editor tool... In my mind those would be separate tools. The ARCV0.BIN/ARCVINFO.BIN is indeed quite complex and I wouldn't like to do much with that myself. The .res/.text files however are much simpler in comparison and are what needs to be edited to make a text editor.

The texteditor is not the problem but the reinsertion into ARCV0.BIN.
At this point I know so much about PACK and RES I can write an editor for that myself.
But this is not what gives the trouble.

Every textfile has to be inserted back into ARCV0.BIN. It's not like they are lying around on open display. In the end you insert more text into the pack than was there before.
Because we need that space. So the filesize of the pack increased. But the ARCVINFO.BIN stores a different filesize and so the game will freeze. But even if you fix that you have the problem that
the files in ARCV0.BIN are stored sequentally, if you increase a file you have to shift the offsets of the files that come after the increased file.
You are, of course free to unpack all files and then edit them with an editor. But hey you are still left with the messy task to get all that stuff back into ARCV0.BIN.

And this is where we're currently stuck with.

@SkyBladeCloud:

You suggest recreating a 500 MB filesize archive along with it's file descriptor?
How do you think that should work? Feel free to PM me.

 

[SkyBladeCloud]

[EDITED]

Good, luck, you'll need it.

 

[SkyBladeCloud]

You sir, just lost an opportunity to get you game fixed by an experienced computer science major, now good luck trying yourself, as you will need it.

 

[Romsstar]

You sir, just lost an opportunity to get you game fixed by an experienced computer science major, now good luck trying yourself, as you will need it.

No problem you're not the first experienced computer science major who offered to help and most likely would have failed as well.
There are so many of you, but if even one of you was capable of something, yeah that would be a nice change of pace.

@Everyone: Sorry for losing my temper but I'm sick of all those pseudo-experienced pros and programmers who didn't even look into the game and pretend to know exactly what our problem is.

Writing some pseudo-code that has absolutely nothing to do with our problem and pretending that we tackled things wrong without even LOOKING into the frickin game, that is someone on a high horse and
such people don't have the skill that this game requires.

 

[SkyBladeCloud]

[EDITED]

Good, luck, you'll need it.

 

[Romsstar]

No offense at all, but you talk you should have checked my background as romhacker before making assumptions: while there are a lot of people like me, YOU are not one of them, so next time think before talking, because fixing this game is something that I can do, that you can't.

Still, thanks for showing me what kind of person you are, now I'm sure I don't wanna have anything to do with this project.

Oh I checked your background and saw what you can do.
You came around. A bit. Nothing special. Nothing some couple of chinese didn't do better than you.
No offense: But you can't do this.

And you have no idea what person I am and you have also no idea about this project.
You should also know if your so called experience is present, that no game uses the same structure and only because something worked on FF it doesn't mean it will work on Redigitize.
Yeah I do follow your project closely and I do know what you're capable of, so when I refuse your help I know exactly what I'm doing.

 

[SkyBladeCloud]

[EDITED]

Good, luck, you'll need it.

 

[Romsstar]

Wow, this game must somehow NOT run on the PSP's MIPS, processor, so I can't understand what it does. Interesting, you obviously know what your doing lol.

We're not talking about the game mechanics and MIPS.
We're talking about file structures.

I assume you haven't looked into ARCV0.BIN otherwise maybe you wouldn't be so sure of yourself.
You have all the files in there. ARCVINFO.BIN stores the names, the offsets and filesizes.
You know what a LBA is. In this context the LBA = ARCVINFO.BIN.

You suggest that you extract the whole ARCV0.BIN. Ok let's assume this.
First of all you need ARCVINFO.BIN. We have about 5-6 different extractors lying around.
Hell even I wrote one. This is nothing difficult so far.

But then your fun starts. The text is in .pack files. in those .pack files you have .btx files.
So you have to edit the japanese text in the btx, reassamble a new pack (which will probably be bigger than the original)
and then? Reinsert everything back into ARCV0.BIN?

So you have all the extracted files lying there. So edited the pack.
You suggest next thing you do you take all this stuff and let the game rebuilt a new archive?

Ok but where does this leave us? Still at the same fricking position. You STILL have your tool to recalculate the new offset for the bigger pack file(s) and the other
files. You still have to make sure all those numbers are being generated or entered into ARCVINFO.BIN.

Do you believe you can compltely reverse engineer a file of 500 MB in such a way that you can put it perfectly back together, not to speak of its corresponding LBA?

Do you realize how much time you'd have to spend on that?
I don't say it's impossible but only very few hackers would do that. Which is why we didn't.

And yeah I know you never been that stuck, but then again: You never had to hack Redigitize.
Have you ever considered that Redigitize might be a special case?

 

[SkyBladeCloud]

[EDITED]

Good, luck, you'll need it.

 

[Romsstar]

Dude, you obviously didn't read my 2nd post in this thread, You don't have to repeat what I already read some posts ago. I obviously did check the files from Redigitize and if you think reassembling a file system is too difficult and only a few people can do it, is because you know too few programmers. I've done it dozens of time, not only for Type-0 and dissidia, I've even extracted and repacked entire file systems like this one but encrypted, like Valkyria Chronicles 2 and 3, Valkyrie Profile, and Star Ocean 1 and 2.

Heck, you should check out my Type-0 translation tools: they extract the entire package, recognize each file entry in the LBA (if you wanna call it like that) and those that I've coded support for (raw images, videos, text) are automatically decoded thanks to different program modules I code (to PNG, TXT, AVI, etc...). Then, after editing those common file types, my tools can recode them into the original format the game understands, updating every needed size reference, and repacks the main package updating the file system descriptor. tl;dr: the game can be fully extracted + decoded and coded + repacked with a double click. This is how I roll in all my projects. And yes, ASM plays an important role when one does not fully understand a data structure.

And btw, Type-0's files are way harder to figure out.

And this is what I explained in the post you didn't bother to read, but if you excuse me, I have to stop caring.

...

Then it appears you are so superior to the rest of us poor humanity that we shouldn't bother you with our little problems. lol
And you don't have to brag in front of me. If you really wanted to help you'd have come directly to me.
Otherwise there is no use to that. Writing some pseudo-code into the thread just to show you know a programming language?
Or what did you want to prove with that?

I told you I have seen enough programmers like you who said "i can do this I can do that".
Oh yeah whatever happened to those? After two weeks most of them left because they couldn't do it.
Nothing you wrote gave me the idea it would be different with you. It would just been a waste of time.

We have a programmer for this project who did brilliantly and who currently is unavaible.
But I'm sure once he's back he'll do a heck of a job. Which you maybe, possibly, could have done,
but since you're so super you wouldn't have because everyone knows you COULD do it. Right, right?
If you did look indeed into the ARCV0.BIN and this is so super easy then let me ask you one thing?
Where is your tool?

I'm sorry but I live in a world where the theoretical possibilites of a person mean nothing to me.
If something is easy and can be done I do it. I don't go around and tell people about it.

And feel free to do whatever you want. Like I said: I didn't want your help to begin with and nothing you wrote changed that.

 

[SkyBladeCloud]

[EDITED]

Good, luck, you'll need it.

 

[Romsstar]

Exactly what I did


Something you didn't understand or you didn't bother to read. That doesn't mean it was wrong.

Not really. All you did was critizing how we handle things and providing some extraction of the archive which is not the thing we need.
I understood and read what you wrote. It's not wrong. It's just not what is needen. And you didn't understand what our problem is.
That is the crucial point here.

 

[SkyBladeCloud]

Here, the output of my tool, that I'm not going to share to help on a project driven by such a condescendant person:

[NAME - OFFSET - SIZE]

http://pastebin.com/N3JUGRvV

This the ARCVINFO.BIN file perfectly decoded, my tool can also reinsert bigger files back updating all necessary sizes + offset refferences. Tested adding random 5MB files to the data package (that the game never loads anyway), and new offset + sizes are calculated correctly so the game works.

Now this is the last message I'm gonna post in this thread, don't expect any kind of answer, but do expect my previous messages to be deleted, since I don't want any word of mine to be of any kind of helpful in this project in any sense. I'm sorry for the fans that will have to wait until... god knows when. So yeah, good luck, you'll need it.

Regards:

~Sky

 

[Mirby]

Well there was hope for this project, but that ended quickly. :\