[Cain]

Hi everyone.

After learning that Crimson Nocturnal shut down I decided to take it upon myself to translate SaGa 3.  SaGa 3 (or FFL3) was one of my favourite games as a kid along with FFL2.  I love the remake of SaGa 2 and I'm sure I'd enjoy the SaGa 3 remake as well.  This is my first hack for the DS and first translation ever.  I'll eventually have to find a translator since I can't read Japanese, but in the mean-time I'm been working on getting the menus done.  The game seems to be built to be translated since it supports shift-jis and has variable width font support.   Progress is going well but I need to start manipulating pointers so I can fit the text properly so I have a few questions.

1. Is it best to work directly with the ROM with hex editor (or similar tool) or should I unpack the game first and then repack it?  One thing that I noticed is that when a game is unpacked and repacked the files don't seem to go back in the same order.  I doesn't seem to be an issue though, at least not that I've encountered.

2. How do I figure out where the pointers are for the text so I can change them?  For example a string that I'm looking for starts at address 0x1104 in FileA.  FileA starts at 0x508D4E0 in the ROM.  It looks like pointers are relative to the start of the file rather than the position in the ROM (based on packing/repacking with files in a different order).  Doing a search for 0x1104 returns about a million (exaggeration) results so going through it manually isn't feasible.  I tried using Cartographer to extract the text but when I give it the sjis table file on this site it complains because there's duplicate entries in it.

I'm sure I'll have some more questions as I continue to play with things, but this is where I'm at now.  Thanks in advance for any help.

[Gideon Zhi]

You'll definitely want to work on each file individually. Text pointers generally *should* be local to the file they're in, but of course that's not always the case. If you just work with one file by itself, then you'll at least have a much smaller area to search.

[Cain]

You'll definitely want to work on each file individually. Text pointers generally *should* be local to the file they're in, but of course that's not always the case. If you just work with one file by itself, then you'll at least have a much smaller area to search.

Ok it looks like the pointers are in fact in the files.  At least the one I'm working on at the moment.  Thanks for the tip.

EDIT:  If pack/unpack the game which will result in the files in a different order, wouldn't that cause a rather large patch file to be created?

EDIT2:  now if I could only get cartographer to work...keeps on crashing for me.

EDIT3:  Ok here's the deal with cartographer.  I can get it to find the pointers ok, but if the string doesn't end with \0 then cartographer can't seem to handle it.  For example:

This is sentance one.This is sentance 2.

I get:

STRING #0 @ $00
This is sentance one.This is sentance two.

STRING #1 @  $15
This is sentance two.

The reason it works in the game is because in the pointer table, it defines the length of the string.  So it will say pointer 0x00 has a length of 21 bytes.  Cartographer either can't handle that, or I don't have it set up right.  Crystal Tile 2 picks up the pointers correctly though but trying to get it extract/insert text hasn't been working either for some reason.  Hopefully the problem is between the chair and the keyboard.

[KaioShin]

I dunno if Cartographer can handle this specific case, but it's actually pretty common that you won't get far with a generic tool since there are just too many possiblities in which pointers can be layed out. You might consider just writing your own little dumper, at least how you describe the system it should be pretty simple in this case.

[Ryusui]

EDIT:  If pack/unpack the game which will result in the files in a different order, wouldn't that cause a rather large patch file to be created?

Not if you use xdelta.

http://www.romhacking.net/utils/598/

[Cain]

I dunno if Cartographer can handle this specific case, but it's actually pretty common that you won't get far with a generic tool since there are just too many possiblities in which pointers can be layed out. You might consider just writing your own little dumper, at least how you describe the system it should be pretty simple in this case.

That's when I ended up doing.  Since the files are self contained it was easy to write a dumper for it.  Now I just have to write the other part of the tool which rebuilds the file based on the dump.  Spending the time to write the tools now will save a lot of time in the long run.  Especially if all the script files follow the same format.

Not if you use xdelta.

http://www.romhacking.net/utils/598/

Awesome, thanks.

[Cain]

Not if you use xdelta.

http://www.romhacking.net/utils/598/

So I tried out xdelta, but I'm getting a patch that's 60MB, which is half the size of the rom.  I believe the reason is because when I unpacked and re-packed the rom, the files are in a different order.  Is there any way to avoid this?  I've tried using both DSLazy and DSBuff but I have the same problem.

[Klarth]

Are the files decompressed then recompressed?  If so, then even if you only change a few bytes per file...the patch size will be very large.  Try to 7z the xdelta patch and see what you end up with.
Otherwise, maybe you didn't set the window size large enough in xdelta?

[Cain]

Are the files decompressed then recompressed?  If so, then even if you only change a few bytes per file...the patch size will be very large.  Try to 7z the xdelta patch and see what you end up with.
Otherwise, maybe you didn't set the window size large enough in xdelta?

All the dialogue is compressed.  By messing with the memory settings I got the patch down to 17MB and I'll zip it up to see if I can get it smaller.  Thanks!