Hi! and... Welcome!
This is open translation project for the Moomin game. (only text boxes)
More about this game you can find on the official site - http://www.sonicpowered.co.jp/moomin/index.html
We can compare this game to Animal Crossing or Harvest Moon but is happening in Moominvalley on own peace.
Some time ago I was curious how the text is stored, and made some tools that works fine for some script files.
As we can guess story is not linear, randomly we encounter with many objects, characters...
so simultaneously editing many files i guess is needed (more than 100) and we can still guess context by name.
I was asked if I have rom map or can public something for those who would like to dig more onto this title and fly this project up.As for the reason my tools have some limitations and maybe I should tune and fix a bit, but I actually don't want to do it right now,I thought if I just share dump and inserting reports... you can check the positions, memory map and maybe make own better tools.In the first part of script file structure we don't have common pointer's table. Pointers are spreaded in different places between other binary data. Pointers are relative in value and contain offsets ( string distances from begining of textblock ). First byte before every pointer tell us what type is it. (0x0D - commmon text string, 0x0B, 0x65 - other script's filename) What is doing seeker/dumper? It's scaning first part of file and compare to offset of next string in textblock. It keeps the same order. There's enough probability to find unique and sure next result (1 byte of type and 2 byte offset). While is scaning, two different containers are created. One with pointer's positions for text, and second one for filenames. Let's say they're saved to seperated file called "pos.db". Another thing what dumper is doing is, as we can guess, extracting text to .txt file. It's adding comment lines with marks to who is talking. Inserter opens original file, "pos.db" and translated text. In first phase it gather all the pointers to filenames, make set of unique names, and recalculate thier positions, after that we are placing rest of pointers to common text strings, and strings in textblock and give them new updated values. Because of how the two type of orders are in flow in first part of file, and new two separeted sections in textblock we can't redump again with the very same autoscan method mentioned above.
That's all what i found for now so I share my findings. Maybe someone intrested can try to make something similar or better. Treat is as exhibition, challange... whatever. Extracted text is editable in notepad++ (Shift-JIS and unix LF endline)
As for limitations: we can't use textboxes in flexible way, but there are some workaround methods like fill enough spaces to
jump to next line in textbox so there's no other way than use exactly the same number of lines in .txt files, but it's working.
Tools i did succesfully make a fast instant full dump, but it needs some tune for place text back for other files support, i guess. Reports can be in a little unreadable mess like this post, but it is as it is, sorry for that. ; )
This is open translation project for the Moomin game. (only text boxes)
More about this game you can find on the official site - http://www.sonicpowered.co.jp/moomin/index.html
We can compare this game to Animal Crossing or Harvest Moon but is happening in Moominvalley on own peace.
Some time ago I was curious how the text is stored, and made some tools that works fine for some script files.
As we can guess story is not linear, randomly we encounter with many objects, characters...
so simultaneously editing many files i guess is needed (more than 100) and we can still guess context by name.
I was asked if I have rom map or can public something for those who would like to dig more onto this title and fly this project up.As for the reason my tools have some limitations and maybe I should tune and fix a bit, but I actually don't want to do it right now,I thought if I just share dump and inserting reports... you can check the positions, memory map and maybe make own better tools.In the first part of script file structure we don't have common pointer's table. Pointers are spreaded in different places between other binary data. Pointers are relative in value and contain offsets ( string distances from begining of textblock ). First byte before every pointer tell us what type is it. (0x0D - commmon text string, 0x0B, 0x65 - other script's filename) What is doing seeker/dumper? It's scaning first part of file and compare to offset of next string in textblock. It keeps the same order. There's enough probability to find unique and sure next result (1 byte of type and 2 byte offset). While is scaning, two different containers are created. One with pointer's positions for text, and second one for filenames. Let's say they're saved to seperated file called "pos.db". Another thing what dumper is doing is, as we can guess, extracting text to .txt file. It's adding comment lines with marks to who is talking. Inserter opens original file, "pos.db" and translated text. In first phase it gather all the pointers to filenames, make set of unique names, and recalculate thier positions, after that we are placing rest of pointers to common text strings, and strings in textblock and give them new updated values. Because of how the two type of orders are in flow in first part of file, and new two separeted sections in textblock we can't redump again with the very same autoscan method mentioned above.
That's all what i found for now so I share my findings. Maybe someone intrested can try to make something similar or better. Treat is as exhibition, challange... whatever. Extracted text is editable in notepad++ (Shift-JIS and unix LF endline)
As for limitations: we can't use textboxes in flexible way, but there are some workaround methods like fill enough spaces to
jump to next line in textbox so there's no other way than use exactly the same number of lines in .txt files, but it's working.
Tools i did succesfully make a fast instant full dump, but it needs some tune for place text back for other files support, i guess. Reports can be in a little unreadable mess like this post, but it is as it is, sorry for that. ; )
Last edited by plasturion,
