No, it is not Japanese. And since I don't know Japanese how could I begin translating the game to that language?
--------------------- MERGED ---------------------------
I used 0.3.
--------------------- MERGED ---------------------------
That's strange, maybe we have different rom versions what's your crc32? Let's compare binaries and output files of ShopUpgrades.
Mine in.bin has 12340 bytes, and crc32 - DC8063B3
outOrg.txt - 5826 bytes, crc32 - 9982C6A2
If bin.in is the same, outOrg.txt has to be the same if you are using v.03 and that's correct output.
And can you be more specific? If you open outOrg.txt and set charset to windows-1252 what exactly shows in the ' and " symbols. (or please tell hex values at that positions if possible)
Mine in.bin has 12340 bytes, and crc32 - DC8063B3
outOrg.txt - 5826 bytes, crc32 - 9982C6A2
If bin.in is the same, outOrg.txt has to be the same if you are using v.03 and that's correct output.
And can you be more specific? If you open outOrg.txt and set charset to windows-1252 what exactly shows in the ' and " symbols. (or please tell hex values at that positions if possible)
I'm not sure if there are any problem, telling about that binary "archive" string tables are combined from two standards. Most of them are iso 8859-1 and that special symbols (' and ") are 2 byte unicode. Tools convert that symbols from range (0x80-0x9F) on the fly, so output.txt should be different here if you compare values in hex editor. String table generator brings back unicode values again. To be sure if your tool is valid just make steps to create out.bin and compare with in.bin. Both files should be the same.
The translation is still going: so far I have translated almost the whole subscreens and at least 35% of the dialogue in the game.
Still don't know how to edit those graphics (the fancy "The End" image for example). Ending credits haven't been edited yet.
Still don't know how to edit those graphics (the fancy "The End" image for example). Ending credits haven't been edited yet.
I know I'm not updating this thread from a while, sorry. But my project is almost done. I still need to finish those damn dialogues in the game with the bosses (they're very hard to translate) and the graphics if this will ever happen. After that, betatesting, xdelta file patch creation, and presto.
You all won't believe me, but I had just finished translating the entire dialogues and menus.
Unfortunately I had to hiatus up the project for some time after I was struck by a chronic allergy attack (when this happens I don't stop sneezing until a certain moment!). But I finally did it. Now I'm asking people on Romhacking.it to help me on editing .bin graphics and the 3-letter stat abbreviations which I could not find nor modify.
Gosh, it was very long. At least this proves that I'm not so bad in ROM hacking after all.
Unfortunately I had to hiatus up the project for some time after I was struck by a chronic allergy attack (when this happens I don't stop sneezing until a certain moment!). But I finally did it. Now I'm asking people on Romhacking.it to help me on editing .bin graphics and the 3-letter stat abbreviations which I could not find nor modify.
Gosh, it was very long. At least this proves that I'm not so bad in ROM hacking after all.
I tested this translation on my R4 but it freezes when trying to show the Forms tutorial.
It does not happen with the original version.
It does not happen with the original version.
Does it work in an emulator?
Anyway usual suspect for this is the text you changed. Either you put a character it does not understand in the characters or formatting (new lines, bold, what character is speaking...), messed up the pointers such it also does not understand something or tries to start interpreting something in the wrong location and 8117 might normally be understood but start on the 17 and yeah, failure to recompress with the proper format and it tries to decompress, or your translation is too long and you have some memory issues. Outside chance it could be some kind of anti piracy thing but that is unlikely these days.
If it crashes at that point then you either get to play with assembly (if you had to drag yourself kicking and screaming to this point then probably skip that one as that is the truly hard stuff, especially debugging a crash) or you get to take the longer winded method of restore the thing you think causes the crash (typically if it is text in the Forms tutorial was the only thing changed by you then that) to the original and step by step remake the hack*
*first change a few characters and test, now try all the various characters you used in your hack and see what goes (preferably overwriting the original characters but keeping the same length), now change some pointers and test, now make the file as large as the hacked version you had when it crashed and test, if you altered a font as part of this then that too at whatever point makes sense...
If you find what makes it crash then great you can figure out a workaround or how to do it better, if you find it works fine then compare and see what is different (might be a minor typo somewhere) if you want to get better at all this or just roll with it if you are OK with that.
Anyway usual suspect for this is the text you changed. Either you put a character it does not understand in the characters or formatting (new lines, bold, what character is speaking...), messed up the pointers such it also does not understand something or tries to start interpreting something in the wrong location and 8117 might normally be understood but start on the 17 and yeah, failure to recompress with the proper format and it tries to decompress, or your translation is too long and you have some memory issues. Outside chance it could be some kind of anti piracy thing but that is unlikely these days.
If it crashes at that point then you either get to play with assembly (if you had to drag yourself kicking and screaming to this point then probably skip that one as that is the truly hard stuff, especially debugging a crash) or you get to take the longer winded method of restore the thing you think causes the crash (typically if it is text in the Forms tutorial was the only thing changed by you then that) to the original and step by step remake the hack*
*first change a few characters and test, now try all the various characters you used in your hack and see what goes (preferably overwriting the original characters but keeping the same length), now change some pointers and test, now make the file as large as the hacked version you had when it crashed and test, if you altered a font as part of this then that too at whatever point makes sense...
If you find what makes it crash then great you can figure out a workaround or how to do it better, if you find it works fine then compare and see what is different (might be a minor typo somewhere) if you want to get better at all this or just roll with it if you are OK with that.
On emulator it works perfectly. I did not do anything with text formatting (the line number is unchanged) and the script tool automatically repoints phrases. What could I possibly have done wrong?
For an emulator to work then I would usually look at memory allocation (though that should not be a thing for the DS and most emulators there, more a thing I would see on dodgy SNES emulators) or maybe a quirk with compression if it used a different one.
It could be some super obscure timing issue but that would be a first, especially for a text edit.
Just to check as well. When you loaded the modded ROM in an emulator you ran the game to that point and did not try to load a savestate or anything?
It could be some super obscure timing issue but that would be a first, especially for a text edit.
Just to check as well. When you loaded the modded ROM in an emulator you ran the game to that point and did not try to load a savestate or anything?
No, I didn't. It works perfectly on Desmume, so there is nothing wrong there at least.
In that case it is either an inaccuracy in the emulation or your flash cart making things hard.
I have not see so much of the former yet on the DS but we have seen it plenty on the NES, SNES, even some GBA before. For the GBA the last one I saw was a compression tool used the wrong type and most emulators did not complain but hardware restrictions are called that for a reason so it then failed. I don't think this will be a thing here in that exact manner, but it could be a type 10 (older format for LZ similar to the GBA BIOS style) vs type 11 (newer format that appeared later in the day, there is also type 40 but that was way late and first seen in Golden Sun) depending upon what tool you are using.
Try another DS emulator if you can (no$gba and melonds probably being the first ports of call here).
Flash cart wise. We have seen this (there is a reason you might see "unpack and repack with ndstool" if you have a TTDS I think it was in various Jump Ultimate Stars patches) but not for a while, and if it boots in the fist place long enough to crash at a point it is likely not the basics. To that end we are left with your SD card has a corrupt sector or something, or maybe it detects the game as a different one and uses a different patch set (unlikely). Change SD card if you can, do a nice format on it and see what goes there.
Third choice is there is some speed critical thing that the flash cart is too slow for (see crashing with Castlevania Portrait of Ruin). I would be shocked if text manifests as this.
Fourth choice is there is some form of anti piracy protection that is tripped. Though one would expect that in emulators too and most such things normally don't boot.
Oddball fifth choice is save files. There have been ROMs that refuse to work on flash carts without a started save present and it could be a tutorial that first sees one try to be loaded (say to try to load a name, stats, customisation or something). The solution to that for most people there is actually to run it in an emulator until it makes a save (they seem to work) and copy that to your flash cart. I would have expected it to crash on the stock ROM if it was doing that but maybe you copied a save from an emulator or had one around.
Beyond this then the step by step thing I mentioned above. Time for that -- do more and more parts of the hack until you find the step that causes the crash and then investigate.
I have not see so much of the former yet on the DS but we have seen it plenty on the NES, SNES, even some GBA before. For the GBA the last one I saw was a compression tool used the wrong type and most emulators did not complain but hardware restrictions are called that for a reason so it then failed. I don't think this will be a thing here in that exact manner, but it could be a type 10 (older format for LZ similar to the GBA BIOS style) vs type 11 (newer format that appeared later in the day, there is also type 40 but that was way late and first seen in Golden Sun) depending upon what tool you are using.
Try another DS emulator if you can (no$gba and melonds probably being the first ports of call here).
Flash cart wise. We have seen this (there is a reason you might see "unpack and repack with ndstool" if you have a TTDS I think it was in various Jump Ultimate Stars patches) but not for a while, and if it boots in the fist place long enough to crash at a point it is likely not the basics. To that end we are left with your SD card has a corrupt sector or something, or maybe it detects the game as a different one and uses a different patch set (unlikely). Change SD card if you can, do a nice format on it and see what goes there.
Third choice is there is some speed critical thing that the flash cart is too slow for (see crashing with Castlevania Portrait of Ruin). I would be shocked if text manifests as this.
Fourth choice is there is some form of anti piracy protection that is tripped. Though one would expect that in emulators too and most such things normally don't boot.
Oddball fifth choice is save files. There have been ROMs that refuse to work on flash carts without a started save present and it could be a tutorial that first sees one try to be loaded (say to try to load a name, stats, customisation or something). The solution to that for most people there is actually to run it in an emulator until it makes a save (they seem to work) and copy that to your flash cart. I would have expected it to crash on the stock ROM if it was doing that but maybe you copied a save from an emulator or had one around.
Beyond this then the step by step thing I mentioned above. Time for that -- do more and more parts of the hack until you find the step that causes the crash and then investigate.
It's complete. I cannot say anything else. I completed the translation and published it on romhacking.it.
Still, the graphics are in english and that crash still exists. I seriously think that it is the tool to edit the text - I edited it in all possible ways but nope.
Still, the graphics are in english and that crash still exists. I seriously think that it is the tool to edit the text - I edited it in all possible ways but nope.
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
RedColoredStars:
There is an actual trailer with footage too. lol. Going to watch it tonight. Grabbed it from... a place. -
-
@
SylverReZ:
@Psionic Roshambo, JonTron's back yet again until he disappears into the void for another 6 or so months.+1 -
-
-
-
-
-
-
