Gaming Digimon World Re:Digitize - Anyone making translation?

[Dragonlord]

I tried getting the files opened with my VB2010 but to no avail. VB2010 can't handle these files. Can you tell me what VB Version these files have been created with? Maybe I find a way to import them somehow. Right now the files just result in tons of compile errors.

i think there is a add on for vb10 that lets you open most files or hex editor shows you a certain coding i think ile look

Actually taking a closer look it seems not all files have been included in the archive. The frmMain references variables never defined anywhere so I assume some source files are missing. Visual Studio has a notorious liking to spread your files all over the place making it easy to miss important files while packing 'em up.

yeah you can say that again you can try notepad++ that might be able to view them and edit fine without error

The editing is not the problem. I can do this with Code::Blocks but without compiling I can't check if it works as it should. Blind coding is not getting you far in general.

That said I noticed something strange. I took the pre-compiled tool, opened the untranslated sample file and just saved it out again without any changes. Hexing the file it shows the offset table is rebuild as it should. The translated file included in the same archive though does not have an altered offset table. Are you guys not using the same executable?

 

[shinagami]

I tried getting the files opened with my VB2010 but to no avail. VB2010 can't handle these files. Can you tell me what VB Version these files have been created with? Maybe I find a way to import them somehow. Right now the files just result in tons of compile errors.

i think there is a add on for vb10 that lets you open most files or hex editor shows you a certain coding i think ile look

Actually taking a closer look it seems not all files have been included in the archive. The frmMain references variables never defined anywhere so I assume some source files are missing. Visual Studio has a notorious liking to spread your files all over the place making it easy to miss important files while packing 'em up.

yeah you can say that again you can try notepad++ that might be able to view them and edit fine without error

The editing is not the problem. I can do this with Code::Blocks but without compiling I can't check if it works as it should. Blind coding is not getting you far in general.

That said I noticed something strange. I took the pre-compiled tool, opened the untranslated sample file and just saved it out again without any changes. Hexing the file it shows the offset table is rebuild as it should. The translated file included in the same archive though does not have an altered offset table. Are you guys not using the same executable?

notepad ++ lets you re -compile and yeah i think everyone is using the same tool unless someone can modify the tool to do what is needed

 

[Dragonlord]

I tried getting the files opened with my VB2010 but to no avail. VB2010 can't handle these files. Can you tell me what VB Version these files have been created with? Maybe I find a way to import them somehow. Right now the files just result in tons of compile errors.

i think there is a add on for vb10 that lets you open most files or hex editor shows you a certain coding i think ile look

Actually taking a closer look it seems not all files have been included in the archive. The frmMain references variables never defined anywhere so I assume some source files are missing. Visual Studio has a notorious liking to spread your files all over the place making it easy to miss important files while packing 'em up.

yeah you can say that again you can try notepad++ that might be able to view them and edit fine without error

The editing is not the problem. I can do this with Code::Blocks but without compiling I can't check if it works as it should. Blind coding is not getting you far in general.

That said I noticed something strange. I took the pre-compiled tool, opened the untranslated sample file and just saved it out again without any changes. Hexing the file it shows the offset table is rebuild as it should. The translated file included in the same archive though does not have an altered offset table. Are you guys not using the same executable?

notepad ++ lets you re -compile and yeah i think everyone is using the same tool unless someone can modify the tool to do what is needed

I don't think you do. If I try to open the translated file you guys included the tool crashes as expected (since the offset table is broken). If I open though the untranslated file I save with the tool first it opens properly and shows the edited content. There's only one possible conclusion from this: whoever created this translated file in the archive is not using the executable included in the archive. Otherwise he should get the same result as I just did.

 

[shinagami]

I tried getting the files opened with my VB2010 but to no avail. VB2010 can't handle these files. Can you tell me what VB Version these files have been created with? Maybe I find a way to import them somehow. Right now the files just result in tons of compile errors.

i think there is a add on for vb10 that lets you open most files or hex editor shows you a certain coding i think ile look

Actually taking a closer look it seems not all files have been included in the archive. The frmMain references variables never defined anywhere so I assume some source files are missing. Visual Studio has a notorious liking to spread your files all over the place making it easy to miss important files while packing 'em up.

yeah you can say that again you can try notepad++ that might be able to view them and edit fine without error

The editing is not the problem. I can do this with Code::Blocks but without compiling I can't check if it works as it should. Blind coding is not getting you far in general.

That said I noticed something strange. I took the pre-compiled tool, opened the untranslated sample file and just saved it out again without any changes. Hexing the file it shows the offset table is rebuild as it should. The translated file included in the same archive though does not have an altered offset table. Are you guys not using the same executable?

notepad ++ lets you re -compile and yeah i think everyone is using the same tool unless someone can modify the tool to do what is needed

I don't think you do. If I try to open the translated file you guys included the tool crashes as expected (since the offset table is broken). If I open though the untranslated file I save with the tool first it opens properly and shows the edited content. There's only one possible conclusion from this: whoever created this translated file in the archive is not using the executable included in the archive. Otherwise he should get the same result as I just did.

oh i get what you mean now my bad for misunderstood you that might be a program floating around the net somewhere romsstar is the translator i think you will have to ask him... how can you tell the were the table is if the coding shows blocks with null writing in them if so you can tell me were to edit and save it see if that works ?

 

[Romsstar]

@[member='Dragonlord']:

I compile included files with Visual Studio 2010 and it works fine for me.
http://www.sendspace.com/file/henulm Here, I run my created project file included here and it compiles just fine.

From what you wrote I understand you say it is not the program?
Try and edit something with english letters. Save then. And try and insert it back to the game.
We ran lots of tests it never worked.
If you find a way to make it work tell us please.

 

[Dragonlord]

@[member='Dragonlord']:

I compile included files with Visual Studio 2010 and it works fine for me.
http://www.sendspace.com/file/henulm Here, I run my created project file included here and it compiles just fine.

From what you wrote I understand you say it is not the program?
Try and edit something with english letters. Save then. And try and insert it back to the game.
We ran lots of tests it never worked.
If you find a way to make it work tell us please.

The missing file is now included but unfortunately still no love. The designer can't load the form as it crashes out with a null object error. I guess you installed some add-on that I do not have... or you have the SP installed and it contains something that is not there without SP. I could not be bothered to download 3GB of SP just for a minor testing platform. But since VB doesn't tell which definition in the designer file it bails out on I can't do much about that right now. Also in the form file btnSave-handler is defined but no btnSave object definition exists for it in the designer file. VB refuses to compile if such a definition is missing. I REMed that one out as I don't think it's used anyways. This way I can compile the thing now.

Something is though strange. The included executable is not the same as the one compiled. Nevertheless the newly compiled executable as well as the included precompiled one update the offset table on saving a new file. I entered various over-length English gibberish text in random strings and saved. The offset table is adjusted and also the file size entry is written in both executable versions. I can not reproduce the broken offset table as in your translated file.

In my opinion the tool has been working all day long. I have no idea how you ended up with a broken offset table.

This doesn't mean there could be something else causing troubles since re-saving the unaltered Japanese file does produce a smaller file which it definitely should not. This though I can not test as I don't have the tool to re-pack the ISO. I can just speak of the file produced by the tool.

EDIT: I re-saved the Japanese file without any changes and compared it to the original. Obviously this should yield a 1:1 copy of the file which the tool doesn't. The file is considerably smaller. I have to take a closer look at this tomorrow but the tool certainly doesn't save the blocks correctly. Smells from the shape of the difference like a buffer over/under-run problem. Most probably somebody didn't pay attention to the fact that writing fixed-length Strings to files in VB is a pain in the rear. Otherwise what goes for the offset table the tool creates this seems legit to me.

 

[Phantom_User]

Go Go Go Progress!

 

[Roxas75]

The real problem is that we proper re-create the packages that contain the text, but the game still doesn't work, and i cannot get why.
I'm studying all the possibly causes...

 

[shinagami]

@Dragonlord

this is a table not the table from this file that we been looking at but if we can find this we can change it and recompile some how take a look tell me if this is what i need to find

const UI32 MultiRecordSize = 12L;
const UI32 TileRecordSize = 26L;
const UI32 MapRecordSize = 3L;
const UI32 MultiIndexRecordSize = 12L;
const UI32 StaticRecordSize = 7L;
const UI32 StaticIndexRecordSize = 12L;
const UI32 MapBlockSize = 196L;

 

[Dragonlord]

What's that table coming from?

Anyways. Whacked up a Python script to get the info out of the file quicker. Checking the tool-created file my first guess seems to be correct, the blocks are written incorrectly. The string table in the block is wrong and most probably the written strings too. See here (a snippet from the tool-created, unaltered Japanese file):

block   1: offset=1152 size=1372 stringCount=25 (1348 1 12 1) 200
sub string  0: id=100 offset=200 stringLen=0
sub string  1: id=200 offset=196 stringLen=1
sub string  2: id=300 offset=192 stringLen=1
sub string  3: id=305 offset=240 stringLen=11
sub string  4: id=310 offset=300 stringLen=15
sub string  5: id=320 offset=396 stringLen=18
sub string  6: id=330 offset=500 stringLen=22
sub string  7: id=340 offset=604 stringLen=26
sub string  8: id=390 offset=800 stringLen=31
sub string  9: id=400 offset=796 stringLen=33
sub string 10: id=500 offset=792 stringLen=35
sub string 11: id=590 offset=820 stringLen=21
sub string 12: id=600 offset=816 stringLen=23
sub string 13: id=700 offset=944 stringLen=50
sub string 14: id=800 offset=940 stringLen=52
sub string 15: id=900 offset=936 stringLen=54
sub string 16: id=910 offset=984 stringLen=30
sub string 17: id=980 offset=1040 stringLen=2
sub string 18: id=985 offset=1036 stringLen=4
sub string 19: id=990 offset=1032 stringLen=6
sub string 20: id=991 offset=1028 stringLen=8
sub string 21: id=992 offset=1056 stringLen=27
sub string 22: id=1000 offset=1052 stringLen=0
sub string 23: id=1100 offset=1104 stringLen=3
sub string 24: id=1200 offset=1112 stringLen=31

Look at for example string 13 and 14. S14 has been written to start at 940 with length of 52 characters. The next entry is S13 starting at 944 which is 4 bytes later. The offset should have been though 108. Otherwise you overwrite strings and worse you can end up outside the block. The problem is a bit more mean here. In the original file the same is done, hence S14 and S13 are also 4 bytes apart although S14 is longer. The reason is that the devers made a funny "compression". Let's say you have the following text: "Hallo", "allo" and "llo" (nonsense, but enough for the example). I only have to store "Hallo" once and simply set the three strings to start at offset 0, 4 and 8 into this string and I get the three strings I started out with. The tool doesn't handle this pseudo-compression and ends up creating nonsense.

The solution is to fully rebuild the string table from scratch either with or without pseudo-compression. This should fix the problem (hopefully).

 

[shinagami]

What's that table coming from?

Anyways. Whacked up a Python script to get the info out of the file quicker. Checking the tool-created file my first guess seems to be correct, the blocks are written incorrectly. The string table in the block is wrong and most probably the written strings too. See here (a snippet from the tool-created, unaltered Japanese file):

block   1: offset=1152 size=1372 stringCount=25 (1348 1 12 1) 200
sub string  0: id=100 offset=200 stringLen=0
sub string  1: id=200 offset=196 stringLen=1
sub string  2: id=300 offset=192 stringLen=1
sub string  3: id=305 offset=240 stringLen=11
sub string  4: id=310 offset=300 stringLen=15
sub string  5: id=320 offset=396 stringLen=18
sub string  6: id=330 offset=500 stringLen=22
sub string  7: id=340 offset=604 stringLen=26
sub string  8: id=390 offset=800 stringLen=31
sub string  9: id=400 offset=796 stringLen=33
sub string 10: id=500 offset=792 stringLen=35
sub string 11: id=590 offset=820 stringLen=21
sub string 12: id=600 offset=816 stringLen=23
sub string 13: id=700 offset=944 stringLen=50
sub string 14: id=800 offset=940 stringLen=52
sub string 15: id=900 offset=936 stringLen=54
sub string 16: id=910 offset=984 stringLen=30
sub string 17: id=980 offset=1040 stringLen=2
sub string 18: id=985 offset=1036 stringLen=4
sub string 19: id=990 offset=1032 stringLen=6
sub string 20: id=991 offset=1028 stringLen=8
sub string 21: id=992 offset=1056 stringLen=27
sub string 22: id=1000 offset=1052 stringLen=0
sub string 23: id=1100 offset=1104 stringLen=3
sub string 24: id=1200 offset=1112 stringLen=31

Look at for example string 13 and 14. S14 has been written to start at 940 with length of 52 characters. The next entry is S13 starting at 944 which is 4 bytes later. The offset should have been though 108. Otherwise you overwrite strings and worse you can end up outside the block. The problem is a bit more mean here. In the original file the same is done, hence S14 and S13 are also 4 bytes apart although S14 is longer. The reason is that the devers made a funny "compression". Let's say you have the following text: "Hallo", "allo" and "llo" (nonsense, but enough for the example). I only have to store "Hallo" once and simply set the three strings to start at offset 0, 4 and 8 into this string and I get the three strings I started out with. The tool doesn't handle this pseudo-compression and ends up creating nonsense.

The solution is to fully rebuild the string table from scratch either with or without pseudo-compression. This should fix the problem (hopefully).

that sounds fun how did you access the files coding i just get a load of blocks with null writing in them and the table i got is from a different code i was asking is this what needs to be found to edit and change to get it to work

 

[Roxas75]

I'm making some experiments.. Just tell me how you think it should done, if you want i can implement this pseudo-compression too.

EDIT: I tryed to re-pack the file with a new version of my tool without changing it, and the game loaded it and worked with some digimon dialogues, but freezes with some other digimons. this could be a VRAM problem, maybe becouse the dialogues are stored at the end of the file. In fact my file is a bit bigger than the original (that becouse i didn't use the compression).
Now i'll try more experiments...

 

[Dragonlord]

that sounds fun how did you access the files coding i just get a load of blocks with null writing in them and the table i got is from a different code i was asking is this what needs to be found to edit and change to get it to work

As mentioned I wrote a Python script printing out the information in the form I like it. Okteta+Python is all a skilled reverse engineer needs.

I'm making some experiments.. Just tell me how you think it should done, if you want i can implement this pseudo-compression too.

EDIT: I tryed to re-pack the file with a new version of my tool without changing it, and the game loaded it and worked with some digimon dialogues, but freezes with some other digimons. this could be a VRAM problem, maybe becouse the dialogues are stored at the end of the file. In fact my file is a bit bigger than the original (that becouse i didn't use the compression).
Now i'll try more experiments...

I think if you store the strings non-overlapped the problem should go away. Your assumption about the VRAM is most probably right. When I saw the pseudo-compression I was like "WTF?!" already since using such a compression scheme is usually only attempted if you hit serious memory limitations late in development. This though doesn't paint a good image of the game developers there as a skilled game dever should never end up in such a pinch he needs to do a last-resort compression like that. Most probably they access the file in a large block and if it goes beyond the block size the app freezes. So I guess you have to limit yourself on some text there as I don't think with English you can do well a pseudo-compression as with Japanese. Should be though not difficult to implement since with a max of roughly 25 strings and at most 100 characters a string on average you can do a brute force greedy depth-search to find the optimal compression combination of strings. If space really is the problem this and limiting the translation should buy you out.

 

[Tareblo]

you made progress, good job guys!

 

[Roxas75]

I think if you store the strings non-overlapped the problem should go away. Your assumption about the VRAM is most probably right. When I saw the pseudo-compression I was like "WTF?!" already since using such a compression scheme is usually only attempted if you hit serious memory limitations late in development. This though doesn't paint a good image of the game developers there as a skilled game dever should never end up in such a pinch he needs to do a last-resort compression like that. Most probably they access the file in a large block and if it goes beyond the block size the app freezes. So I guess you have to limit yourself on some text there as I don't think with English you can do well a pseudo-compression as with Japanese. Should be though not difficult to implement since with a max of roughly 25 strings and at most 100 characters a string on average you can do a brute force greedy depth-search to find the optimal compression combination of strings. If space really is the problem this and limiting the translation should buy you out.

Yeah, i think i'll use some tricks to save some space, becouse if the problem is the file size, the PACK file has to be of the original size, but all the BTX files size can be edited (obviusly toghether they have to match the right size of the PACK).
I'l try some things.

 

[shinagami]

I think if you store the strings non-overlapped the problem should go away. Your assumption about the VRAM is most probably right. When I saw the pseudo-compression I was like "WTF?!" already since using such a compression scheme is usually only attempted if you hit serious memory limitations late in development. This though doesn't paint a good image of the game developers there as a skilled game dever should never end up in such a pinch he needs to do a last-resort compression like that. Most probably they access the file in a large block and if it goes beyond the block size the app freezes. So I guess you have to limit yourself on some text there as I don't think with English you can do well a pseudo-compression as with Japanese. Should be though not difficult to implement since with a max of roughly 25 strings and at most 100 characters a string on average you can do a brute force greedy depth-search to find the optimal compression combination of strings. If space really is the problem this and limiting the translation should buy you out.

Yeah, i think i'll use some tricks to save some space, becouse if the problem is the file size, the PACK file has to be of the original size, but all the BTX files size can be edited (obviusly toghether they have to match the right size of the PACK).
I'l try some things.

i have program that might help not sure its called neo hex editor it allows you to change the file size to the desired size you want not sure if it will be anything usefull just thought it might help

 

[Romsstar]

I think if you store the strings non-overlapped the problem should go away. Your assumption about the VRAM is most probably right. When I saw the pseudo-compression I was like "WTF?!" already since using such a compression scheme is usually only attempted if you hit serious memory limitations late in development. This though doesn't paint a good image of the game developers there as a skilled game dever should never end up in such a pinch he needs to do a last-resort compression like that. Most probably they access the file in a large block and if it goes beyond the block size the app freezes. So I guess you have to limit yourself on some text there as I don't think with English you can do well a pseudo-compression as with Japanese. Should be though not difficult to implement since with a max of roughly 25 strings and at most 100 characters a string on average you can do a brute force greedy depth-search to find the optimal compression combination of strings. If space really is the problem this and limiting the translation should buy you out.

Yeah, i think i'll use some tricks to save some space, becouse if the problem is the file size, the PACK file has to be of the original size, but all the BTX files size can be edited (obviusly toghether they have to match the right size of the PACK).
I'l try some things.

I trust that we are close to finally be able to translate stuff!
Keep going, I'm eager to finally start translating again. It has been weeks.xD

 

[Roxas75]

Well, finally i did it... There are some restrictions, but now the tool works properly.

Romsstar, now i'll send you the tool in a PM with some instructions.
The story translation can FINALLY begin!

 

[shinagami]

good job guys keep up the excellent work

 

[Tareblo]

thank you guys! you're great!