Dragon Quest Delocalized Projects

[Chicken Knife]

I'm sorry if this was covered elsewhere, but I was wondering why the copyright symbol " © " on the title screen of DW1 was replaced by a frowny face?

@svenge

Great observation. Like the person who noticed the foreign background tile graphics, this looks like another vestige of that graphic hack that was listed on rom sites as the legitimate version. I've been looking at it so long I hadn't questioned it. It's been fixed and I'll update the file on the first post of this thread.

January 21, 2019, 10:26:27 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
@abw

I took your formatting, attempted the insertion, and I'm getting error messages.

attempt to write beyond 131087 at C:\Rom Editing/abcde/Atlas.pm Line 470 <COMMAND_FILE> line 2380

attempt to write beyond 131087 at C:\Rom Editing/abcde/Atlas.pm Line 470 <COMMAND_FILE> line 2434

attempt to write beyond 131087 at C:\Rom Editing/abcde/Atlas.pm Line 470 <COMMAND_FILE> line 2492

There are about 8 more of these messages with the line up to 3107

I'm not sure what this means

Here are my files if you want to take a look:

https://www.dropbox.com/s/ysnvek2o1vwivcd/dw2_Atlas.txt?dl=0
https://www.dropbox.com/s/b1tow1cygj8pgwz/dw2_script.tbl?dl=0

FYI I chose [FF] as the end token after monster names for the insert file because that seemed to be the way it was formatted in the table file. If I did that wrong let me know.

And to answer your question, I've been managing all my item / monster / spell lists for the first three DQ games in a hex editor and recalculate my pointers manually. You should know by now I will always use stone age methods until forced to adopt better ones. 

[Tyrantnyx]

You seem to have accidentally uploaded the Dragon Quest 2 Delocalized patch instead of the Dragon Quest 1 Delocalized 1.04 to the project page.

[Chicken Knife]

You seem to have accidentally uploaded the Dragon Quest 2 Delocalized patch instead of the Dragon Quest 1 Delocalized 1.04 to the project page.

Thanks for the heads up Tyrantnyx. I've just submitted another update with the right file attached (hopefully)

The first page of this thread should have the correct patch if you want to grab it.

[abw]

I took your formatting, attempted the insertion, and I'm getting error messages.

Short answer: paste the monster list stuff after the main script, add the table file you were already using for the monster list (the one with 0A=a, 0B=b, etc.), and try it again.

Longer answer: as it stands, this script sets the insertion point to $14010 (start of the main script) but then doesn't insert anything there and instead changes the insertion point to $1D050 (start of the new monster list), inserts the monster list using the 5/10-bit table file for the main script instead of the 8-bit table for the monster list, and then after the monster list is finished, it keeps going and inserts the main script immediately afterwards, which eventually overflows the insertion upper bound of $2000F and triggers those warning messages.

And to answer your question, I've been managing all my item / monster / spell lists for the first three DQ games in a hex editor and recalculate my pointers manually. You should know by now I will always use stone age methods until forced to adopt better ones. 

At least with the lists there are only a few pointers to update, but still .

[Chicken Knife]

Short answer: paste the monster list stuff after the main script, add the table file you were already using for the monster list (the one with 0A=a, 0B=b, etc.), and try it again.

Longer answer: as it stands, this script sets the insertion point to $14010 (start of the main script) but then doesn't insert anything there and instead changes the insertion point to $1D050 (start of the new monster list), inserts the monster list using the 5/10-bit table file for the main script instead of the 8-bit table for the monster list, and then after the monster list is finished, it keeps going and inserts the main script immediately afterwards, which eventually overflows the insertion upper bound of $2000F and triggers those warning messages.

Makes sense. Took care of this and I have a problem unfortunately. I received a satisfactory message that everything seemed to have inserted. Within the game, all the NPC text is back in order but there is an issue: the game is still pulling monster names from the old list in the original bank. I've tested and my naming updates to the monsters did not take effect.

Not much has changed with my insert file besides the reordering but this is the new one.

https://www.dropbox.com/s/thjl1pts2b9uhk9/dw2_Atlas.txt?dl=0

[abw]

And by "the monster list stuff", I meant all the monster list stuff . Remember a few posts back where I explained how the game finds the monster list and provided some code for altering that behaviour to load the new list instead? Crazy as it may sound, you do actually need that code in order for the game to load your new list . Stick the rest of it (reproduced below for convenience) just before the "#JMP($1D050, $2000F)" and you should get better results.

Code Select Expand


#JMP($3F3EE)
// update monster list bank/address pointers
<$F4><$F5><$FA><$FB>

#JMP($3FFA7, $3FFC9)
// new code to read pointer from $9000,X instead of $8000,X
//PHA
<$48>
//LDA $05F6
<$AD><$F6><$05>
//STA $60D7
<$8D><$D7><$60>
//PLA
<$68>
//JSR $FF33
<$20><$33><$FF>
//LDA $9000,X
<$BD><$00><$90>
//STA $57
<$85><$57>
//LDA $9001,X
<$BD><$01><$90>
//STA $58
<$85><$58>
//RTS
<$60>

#JMP($3F3E5)
// update JSR to target new code
<$97><$FF>


[Chicken Knife]

@abw



I did that addition, went to test, and I'm getting totally garbled tiles from the enemy names now.

And as far as me missing that critical piece of information several posts back, well...
I just pray to Rubiss that your patience with me lasts until the first four games are complete

The new file

https://www.dropbox.com/s/thjl1pts2b9uhk9/dw2_Atlas.txt?dl=0

[abw]

Ooh, fancy garbledness. It looks like it's one step closer to working, but the monster names are still being inserted with the the 5/10-bit table file for the main script instead of the 8-bit table for the monster list (the one with 0A=a, 0B=b, etc.). You'll need to add something like this in between the end of the main script and the start of the monster list:

Code Select Expand


// switch to the right table if your script isn't currently using this table
#VAR(nonScriptTBL, TABLE)
#ADDTBL("dw2.tbl", nonScriptTBL) // or whatever you named your table file
#ACTIVETBL(nonScriptTBL)


And as far as me missing that critical piece of information several posts back, well...
I just pray to Rubiss that your patience with me lasts until the first four games are complete

Heh, once you get the hang of the first one, the others should be much easier .

[Chicken Knife]

@abw

I added the instructions for the table change. I also had the rare bit of sense to tweak the table file I was using to match the formatting of my monster list. And voila, all the expanded monster names are now working in the game. Thank you so much abw. These projects of mine would be excrement without your help. This exercise has definitely helped me get a clearer sense of the structure of how insertion file instructions work. That doesn't mean I won't be asking stupid questions the next time around. But it might be several less of them! 

@Everyone

At this point I'm going to be expanding the item names in DQ2 to their uncompromised forms with my newly acquired space, and then spending time over the next few weeks with Sparrow Dearden and Masafumi Sato (we've named our little group "Translation Quest"  ) continuing to refine namings and other miscellanous text for DQ2. While we did a great job following x_loto's blueprint document previously for all the NPC and story related text as a rough base to work from and refine, he didn't catalogue battle and out of battle miscellaneous text like he did for DQ1 so I plan on doing a playthrough in the japanese game to capture all that myself so I can represent it accurately for a really nice update.

On that note, if anyone knows of a place I can get save states or .sav files for the Japanese Dragon Quest game I would appreciate it so I don't have to slog all the way through the Cave to Rondarkia (Rhone) just to learn the text when you shoot lighting from the lightning sword.

Wasn't I saying I was going to take a little rest from this stuff after my big DQ1 update? Oh well.. perfectionism is never satisfied.

[abw]

I added the instructions for the table change. I also had the rare bit of sense to tweak the table file I was using to match the formatting of my monster list. And voila, all the expanded monster names are now working in the game. Thank you so much abw. These projects of mine would be excrement without your help. This exercise has definitely helped me get a clearer sense of the structure of how insertion file instructions work. That doesn't mean I won't be asking stupid questions the next time around. But it might be several less of them! 

Huzzah! If you want to test your grasp of the setup, try incorporating the item and spell lists into your insert script. If you want to get more ambitious, it is entirely possible to have each and every text change in your insert script!

(we've named our little group "Translation Quest"  )

While we did a great job following x_loto's blueprint document previously for all the NPC and story related text as a rough base to work from and refine, he didn't catalogue battle and out of battle miscellaneous text like he did for DQ1 so I plan on doing a playthrough in the japanese game to capture all that myself so I can represent it accurately for a really nice update.

On that note, if anyone knows of a place I can get save states or .sav files for the Japanese Dragon Quest game I would appreciate it so I don't have to slog all the way through the Cave to Rondarkia (Rhone) just to learn the text when you shoot lighting from the lightning sword.

You may also be interested in dumping the text directly from the Japanese ROM. Based on a quick peek, it looks like the text is stored using a single 8-bit table, so you should be able to read it fairly easily (if you decide to pursue this option, the dictionary for the 8D to EB table entries is stored at 0x18C4E - 0x18E13). It's not quite the same as actually seeing the text on-screen, but you might find it useful for a variety of things.

[KingMike]

On that note, if anyone knows of a place I can get save states or .sav files for the Japanese Dragon Quest game I would appreciate it so I don't have to slog all the way through the Cave to Rondarkia (Rhone) just to learn the text when you shoot lighting from the lightning sword.

Dragon Quest 1 and 2 for Famicom are password-save games. (DQ3 was the first RAM-save DQ game)
Meaning, they'd need to give you a password (which would be in kana) or an emulator-specific savestate.

[Chicken Knife]

Huzzah! If you want to test your grasp of the setup, try incorporating the item and spell lists into your insert script. If you want to get more ambitious, it is entirely possible to have each and every text change in your insert script!

Let's take back the word grasp. Far too strong of a word at this point. There is painfully more I don't grasp then I do grasp, and that's after my going back through our threads this morning plus rereading the abcde documentation as well as the atlas documentation. Here's what I do grasp (at least I think)

#w16 commands automatically update the 16 bit pointer listed after the command

#VAR(Table, TABLE)
#ADDTBL("dw2.tbl", Table)
#ACTIVETBL(Table)

I'm a little unclear on the purpose of the #VAR part but I I understand that this sequence loads and activates the specified table file and I understand why I needed to switch the table file based on the bit compression schedule for the main text body.

When I said things were becoming clearer, I was really talking about the order of what commands should go where based on the flow of the operations. Obvious to most people but not to this programming impaired brain of mine.

#HDR($14010)

I'm not sure why the values of this header command keep changing. For my main script insert the HDR value is $C010. Shouldn't the HDR consistently be $10 to account for the actual header? Is this being used to swap rom banks somehow?

* EDIT Going back over previous posts, I see that you provided some explanation how to compute this number (i.e. 0x1D050 / $07:9040) to 0x1D038 / $07:$9028). I still don't understand what's going on with those numbers but I see that we are using the HDR to change rom banks. I think I need to better understand how to verify where rom banks start and end and what's all going into this HDR number

#JMP($3F3EE)
// update monster list bank/address pointers
<$F4><$F5><$FA><$FB>

I see that the game overwrote the data starting at this address with those following bytes. These look like new pointers that you are using instead of the ones that were stored above the original monster list. Is this because the pointers must be in the same rom bank as the new list address?

Code Select Expand


#JMP($3FFA7, $3FFC9)
// new code to read pointer from $9000,X instead of $8000,X
//PHA
<$48>
//LDA $05F6
<$AD><$F6><$05>
//STA $60D7
<$8D><$D7><$60>
//PLA
<$68>
//JSR $FF33
<$20><$33><$FF>
//LDA $9000,X
<$BD><$00><$90>
//STA $57
<$85><$57>
//LDA $9001,X
<$BD><$01><$90>
//STA $58
<$85><$58>
//RTS
<$60>

#JMP($3F3E5)
// update JSR to target new code
<$97><$FF>

Is this stuff essentially rewritten code instructions telling the game where to access the new pointers you created above? You are suggesting I do this all on my own but dealing with this aspect of it seems far beyond my grasp at this point.

*EDIT

I just realized I don't need to create new code, new pointers, etc. I can just have abcde update the existing pointers based on the existing list locations since I have room to expand. I think I might be able to figure that out!

Out of mostly curiosity, I pulled up the rom data in a hex editor and I saw a ton of miscellaneous code appearing immediately after my new monster list that ends at appx 0x01D3E6. I immediately became concerned about pushing up against a block of code when I thought I had previously seen lots of free space. A backup rom where I did not insert the new monster list continues to have free space in that large empty section all the way until 0x01FFE8. Going back to my rom with the new monster list added, that entire section of space is completely full of data. What other information would those instructions have written? And what happens if I increase the size of my monster list and overwrite this new data that has appeared. I'm a little puzzled. I can send you files if you want to see it.

#JMP($1D050, $2000F)
#HDR($14010)

I see my new monster list is exactly in the location of $1D050. I believe that $2000 is the limit on how far the insert script will write the script as to not spill over into other code and also provide me that characters left indication.

In summary:

This really isn't easy for me. I'd never say no to you wanting to be my project partner rather than my professor, but the problem is you also love translation and I thus have nothing to contribute to the partnership... Alas, your terrible student shall soldier onward!

As far as your other point:

You may also be interested in dumping the text directly from the Japanese ROM. Based on a quick peek, it looks like the text is stored using a single 8-bit table, so you should be able to read it fairly easily (if you decide to pursue this option, the dictionary for the 8D to EB table entries is stored at 0x18C4E - 0x18E13). It's not quite the same as actually seeing the text on-screen, but you might find it useful for a variety of things.

This is a great idea and I thought about how helpful this would be, especially since x_loto never did a translation of Dragon Quest IV and my translation team has just begun to discuss actually taking that on. This would probably be the ideal way to do it rather than me taking ten thousand screenshots. However, I think it's best for me to take on one activity that puts my brain in a state of agony at a time. Once I understand enough to get my insert script managing my item names, I'll start thinking about extracting the kana scripts

@King Mike

Dragon Quest 1 and 2 for Famicom are password-save games. (DQ3 was the first RAM-save DQ game)
Meaning, they'd need to give you a password (which would be in kana) or an emulator-specific savestate.

I'm not sure how little sleep I had or how much I was drinking when making that comment, but I actually have played through the famicom versions of all the DQ games and I know that there are passwords for the first two games.

In fact, you jogged my memory on where I can probably get some. Thank you.

[abw]

Let's take back the word grasp. Far too strong of a word at this point.

Well, let's see if I can help with that a little bit...

#VAR(Table, TABLE)
#ADDTBL("dw2.tbl", Table)
#ACTIVETBL(Table)

Basically #VAR just declares a new variable, giving it a name and a type, so that you can initialize it later on, sort of like saying "hey, this here word 'foo', it's going to be a TABLE variable". #VAR is probably kind of useless (we can infer the variable's type by its initialization method), but it was part of Atlas so you'll have to take that one up with Klarth .

#ADDTBL reads your table file from disk and checks it for e.g. syntax errors etc., and the #ACTIVETBL makes it the table to start from when translating text to binary. You only need to use #VAR and #ADDTBL once per table file, but you can switch back and forth between which table to use as many times as you want. E.g. for DW2, if you wanted to insert the item list, then the main script, then the monster list, you could do both #VARs and #ADDTBLs right at the start and then do #ACTIVETBL(nonScriptTBL) + item list, #ACTIVETBL(Table) + main script, and #ACTIVETBL(nonScriptTBL) + monster list. It gives you some flexibility in how you you organize your insert script.

* EDIT Going back over previous posts, I see that you provided some explanation how to compute this number (i.e. 0x1D050 / $07:9040) to 0x1D038 / $07:$9028). I still don't understand what's going on with those numbers but I see that we are using the HDR to change rom banks. I think I need to better understand how to verify where rom banks start and end and what's all going into this HDR number

#JMP says where to start writing data in the ROM, with an optional upper bound to prevent overwriting stuff you don't want to clobber if you aren't sure your new data will fit within the original space. Having an upper bound is almost always a good idea, but sometimes I'm lazy and don't bother specifying one.

The various pointer writing commands (there's a bunch of them, but #W16 is pretty useful for NES games) all take whatever ROM file address the insertion process is currently at, do some math on it to convert it from a ROM address to a RAM address, then write that RAM address to the ROM address you tell it to. For some systems that math is really easy (e.g. RAM address = ROM address), but for NES games, that math gets complicated by the cartridge's memory mapper. If you look at Atlas' documentation, I think the "correct" way to handle that is to set #HDR to the real size of the ROM file's header, create different custom pointers with #CREATEPTR based on which ROM bank you're inserting into and which RAM bank that ROM bank gets loaded into when the game is running, and then use those custom pointers to write the pointer values, but again, I'm lazy. With the default setting of linear addressing, pointer values are calculated as RAM address = ROM address - header size, or flipping it aroung, header size = ROM address - RAM address. So, by tweaking the #HDR value appropriately, you can get the right RAM addresses. As an example, when we insert the monster list starting at ROM 0x1D050, that's going to appear in RAM as $9040 (we know this because DW2 uses a $4000 RAM bank size [and we know that because FCEUX tells us the mapper number in its Message Log and we can look up mapper #1 on nesdev] and everything except the fixed PRG ROM bank gets loaded into RAM at $8000 - $BFFF, so the RAM address is $8000 + (ROM address - $10 iNes header) modulo $4000 RAM bank size), so $1D050 - $9040 = $14010. On the other hand, the main script gets inserted starting at ROM 0x14010, but it appears in RAM starting at $8000, so the difference between ROM and RAM addresses is $14010 - $8000 = $C010, and that's the fake header value we use to make the math work.

Or in other words, the real iNes header is still $10 bytes long, but we can cheat with the math and pretend there's a different header size instead so that we get the right pointer values.

#JMP($3F3EE)
// update monster list bank/address pointers
<$F4><$F5><$FA><$FB>

That was to update the pointers to the pointers to the monster list to have the game load the new bank instead of the old bank. Pointers don't necessarily have to live in the same bank as the data they point to, but in this case the game code assumes the pointers and the data are in the same bank, so it was less work to let the game keep assuming that than to add new code to swap in a different bank after reading the pointers.

Is this stuff essentially rewritten code instructions telling the game where to access the new pointers you created above? You are suggesting I do this all on my own but dealing with this aspect of it seems far beyond my grasp at this point.

Yes to the first part. For larger chunks of code, you'll want to use an assembler rather than a text insertion utility, but for a small section like this where I was really only changing one byte, inserting the code as a sequence of text bytes is only a slightly horrible abuse of semantics . For the second part, I didn't want to muddy the waters with a tutorial on ASM, but you can definitely work your way up to that later as and when you find you need or want to make changes that can't be made by changing text; one thing at a time!

I just realized I don't need to create new code, new pointers, etc. I can just have abcde update the existing pointers based on the existing list locations since I have room to expand. I think I might be able to figure that out!

That's right - you'll need to know where the existing pointers are (e.g. the spell list pointer is at 0x18036) and then stick a #W16 statement with that pointer address just before the data you want the pointer to point to. You'll also need to make sure you've got the right #HDR value in effect before the #W16 statement happens.

Out of mostly curiosity, I pulled up the rom data in a hex editor and I saw a ton of miscellaneous code appearing immediately after my new monster list that ends at appx 0x01D3E6.

Are you starting every insert with a clean ROM, or are you inserting new stuff on top of old stuff? Remember that time when you inserted the entire main script after the monster list and filled the whole ROM bank? If you're inserting new stuff on top of old stuff, all that main script data will still be there instead of empty space.

This really isn't easy for me. I'd never say no to you wanting to be my project partner rather than my professor, but the problem is you also love translation and I thus have nothing to contribute to the partnership... Alas, your terrible student shall soldier onward!

If it was easy, everybody would do it . Like many things in life, this will get easier with practice .

This is a great idea and I thought about how helpful this would be, [...]

Oh, I should have remembered to check the wiki before reverse-engineering the encoding myself. If/when you want to dump the Japanese text, you should check the wiki too. "Do as I say, not as I do" .

[Chicken Knife]

@abw,

I am pleased to report that after many, many re-readings of your explanations--particularly with the HDR and rom bank concepts, I have successfully set up the item lists to be managed by the insert file. It seems almost simple to me now, but the "modulo" operation you described where the ram address starts at and resets to $8000 after every additional $4000 was the most mystifying. But I got it. Thank you for your patience. Up until now I've been so focused on achieving the next success in the project that I haven't been sufficiently prioritizing learning what's going on on a technical level. It's time for me to make that the greater portion of my role. This leads me to my next statement.

@everyone

nejimakipiyo has recently joined this site and made an introduction in the newbie forum. She is actually the person I've referred to as Sparrow who I was lucky enough to meet in a Facebook group of Dragon Quest fans. I can't overstate how enthusiastic, committed and resourceful nejimakipiyo has been as a collaborator in translation. Most of the recent improvements in these projects have been a direct result of her involvement.

I've asked if she would be willing to take the lead role on translation and writing going forward so I can shift to prioritizing learning the technical stuff and I am delighted that she accepted. Trust me--she is better than I am and knows Japanese which is pretty important.

We will be putting out some fresh updates based on our continued refinement of DQ1 and DQ2 and are truly excited to get moving with DQ3 in the near future.

FYI, nejimakipiyo is not only a big Dragon Quest fan but she has a deep love of the Arc the Lad series and a particular passion for translating the Wonderswan game Arc the Lad Kishin Fukkatsu. I intend to eventually try to help with the technical side of that project, but if a more talented hacker likes the idea of taking that on by all means, reach out. Just as these Dragon Quest projects are my dream, that Arc the Lad project is hers. If anyone is interested in checking out her work (not in games up until now) see the web sites below.

I look forward to seeing you on the forums nejimakipiyo.   

http://demonpassion.yolasite.com

http://ajisai-translations.tokyo

[nejimakipiyo]

Hello Chicken Knife and everyone!

I'm super stoked to be part of this project. The actual hacking stuff is way over my head, so I'll probably be pestering people for help when it comes to inserting my translations into game script, at least until I get the hang of translating in this kind of format! I feel like I'm going to learn a lot here and also have a lot of fun. Refining translations with Chicken Knife has been extremely fun so far.

[abw]

I am pleased to report that after many, many re-readings of your explanations--particularly with the HDR and rom bank concepts, I have successfully set up the item lists to be managed by the insert file.

Congratulations!

It seems almost simple to me now, but the "modulo" operation you described where the ram address starts at and resets to $8000 after every additional $4000 was the most mystifying. But I got it. Thank you for your patience. Up until now I've been so focused on achieving the next success in the project that I haven't been sufficiently prioritizing learning what's going on on a technical level. It's time for me to make that the greater portion of my role.

I foresee a lot more reading in your future . It'll take some time and effort, but the documents section and sites like nesdev will eventually get you pretty much everything you need to know about what's really happening, and combining that knowledge with experience will vastly increase your powers. +10 levels minimum . Achieving the next success in a project can be a good motivator in many ways; it gives you a definite goal to work towards, a certain measure of focus (depending on the goal, of course), and a feeling of accomplishment when you achieve the goal. Just remember to keep it fun - it's sad when your hobbies turn in to chores.

nejimakipiyo

Speaking of fun, isn't it great to have friends?

@nejimakipiyo, welcome! After looking through the sites Chicken Knife linked to, I was half convinced you were one of my offline friends in disguise .

[nejimakipiyo]

@nejimakipiyo, welcome! After looking through the sites Chicken Knife linked to, I was half convinced you were one of my offline friends in disguise .

Thanks! If you have an offline friend who is interested in Japanese indie band translations they sound like my kind of person indeed.

That hobby has given me skills and experience which lend themselves rather nicely to Chicken Knife's project (mainly, searching up Japanese monster names on Japanese wikis and rooting out obscure references) but nothing could have prepared me for seeing the game script file for the first time. Yikes! That's so intimidating! But I'm committed now so you'll all hopefully be able to put up with me until I figure it out.

[Chicken Knife]

@abw

You may also be interested in dumping the text directly from the Japanese ROM. Based on a quick peek, it looks like the text is stored using a single 8-bit table, so you should be able to read it fairly easily (if you decide to pursue this option, the dictionary for the 8D to EB table entries is stored at 0x18C4E - 0x18E13). It's not quite the same as actually seeing the text on-screen, but you might find it useful for a variety of things.

I'm looking at the Japanese DQ2 extraction seriously now and working on setting up a cartographer file. I used the info on http://datacrystal.romhacking.net/wiki/Dragon_Warrior_II:TBL for the table file, which I know I need to organize with the end tokens before it will be effective. The only thing I can't seem to find here or under rom information is the script pointer table that I have to reference in the cartographer file. Any recommendations on how to locate that? I know the last pointer probably has a different string # but I'm not too concerned as long as abcde will spit out the majority of the text. Most if not all of the battle and miscellaneous text we need would be in the earlier strings.

* EDIT

As I think about this, I'm probably going to have to locate them manually by searching the address bytes for the beginning of the script strings. This is complicated a bit by the fact I can't get WindHex32 to properly display the Japanese characters. That said, I could just figure out the first one based on the script start address in ROM information and assume there are exactly as many pointers in a row as in the US version.

@nejimakipiyo

but nothing could have prepared me for seeing the game script file for the first time. Yikes! That's so intimidating!

Don't worry we will help you learn what little bit of the gobbledygook you really need to understand, what can be moved around--and what cannot (hint--most of it!)

[abw]

Thanks! If you have an offline friend who is interested in Japanese indie band translations they sound like my kind of person indeed.

Not only that, she also studied Biology at a Canadian university!

The only thing I can't seem to find here or under rom information is the script pointer table that I have to reference in the cartographer file. Any recommendations on how to locate that? I know the last pointer probably has a different string # but I'm not too concerned as long as abcde will spit out the majority of the text. Most if not all of the battle and miscellaneous text we need would be in the earlier strings.

If you spend some time going throuh a trace log, you can track a string back to its source and then keep going further back to find the pointer to that string. Since I already did that while making my own table file earlier, try looking at 0x14014 - 0x14021; based on the pointer values, it looks like DQ2 uses 64 strings per pointer (but the individual strings are 1 byte per character and so short that it's still faster than reading through 16 English strings), and based on me tracking down a couple of random strings, the Japanese strings are not stored in the same order as the English strings.

This is complicated a bit by the fact I can't get WindHex32 to properly display the Japanese characters.

If you save your table file in Shift-JIS instead of UTF-8 and then select the Option -> View Text Data as Unicode (Ctrl+D) menu option, you should get Japanese characters showing up correctly. Just remember that abcde still expects its table files to be encoded in UTF-8!

@nejimakipiyo

but nothing could have prepared me for seeing the game script file for the first time. Yikes! That's so intimidating!

Don't worry we will help you learn what little bit of the gobbledygook you really need to understand, what can be moved around--and what cannot (hint--most of it!)

Or at least what can be moved around without much work. Technically almost everything in both the insert script file and the ROM itself can be moved, it's just that when you move one thing, you also need to update every single other thing that was expecting to find the first thing in its original location without breaking anything else, and doing that can sometimes be a royal pain.

As for intimidating... there are plenty of games that are both smaller and simpler to work with than DW2, so we're not exactly swimming in the shallowest end of the ROM hacking pool, but the deep end goes much, much deeper than this .

[nejimakipiyo]

I enjoy my life far too much to get bogged down in all of the technical stuff that's over my head.
I'll learn what I have to so that I can insert the translations without bugging everything up but my intent is to stick to the words... and the research behind those obscure monster names.
We just defeated all of the monsters from the Roto trilogy!