Jump to content

Musumaker Translation Project (Mikan, Karin, Ichigo, Suika, Zakuro, Yuzu routes complete!)


Recommended Posts

37 minutes ago, Hoshimaru said:

To trace it properly, i need the unedited musumaker hd files or how to extract the bin files.

You can download the tool to extract the .bin files from here.

Usage: in cmd, type:

exdxa <inputfile.bin> _taskforce_


Link to comment
Share on other sites

58 minutes ago, Hoshimaru said:

That's very weird, i've tested it and voice for all girls works well for me even after loading from schedule screen.

Oh okay that's good, I guess I must have just broken something in my install. I didn't get voices even after starting a new game.

Link to comment
Share on other sites

I found the reason why loading fails when text gets displayed.

It's the extra lines in the translation files.


ERROR : (60057行目)


TL File:

Yes, she's asleep now.


She looks in front of her at Karin breathing softly in bed.


There was no bad-mouthing when I came into her room today.


layerchange    1,"chara\美雨\小HD\メイド\閉_哀.png"

Thankfully, it was just fatigue, but...


I know...

Original file:




layerchange    1,"chara\美雨\小HD\メイド\閉_哀.png"




Every line has to be at the exact same position it was, no extra line, no extra @ where it doesn't belong.

As test, i did a quicksave where i know it will throw an error. I removed a few empty lines > loaded > worked BUT it jumped to a few lines after " Thankfully, "

Edited by Hoshimaru
Link to comment
Share on other sites

@Hoshimaru just a hunch and without having looked into it myself, but... is this excerpt from the start of a file or from a random point in it? If the latter, could the issue of jumping ahead be because some lines in the English translation are split, while in the Japanese version they're not due to the language being much more condensed? That would result to the translated text strings ending up on different line numbers even if there are no new lines introduced in the translation, and while it would seemingly work at the point in the game you are at, it would still result in the wrong lines being picked and would probably still break down the line.

On the other hand, it's weird that this issue only becomes apparent when saving/loading a game, and not while playing the game, because it means that the redundant empty lines and split lines do not break the game while it's running. This to me implies an issue not with the translated scripts themselves but with how the game stores the current line when it saves the game and/or how it retrieves it when it loads. This could be because the .exe uses the original, internal scripts with the original file numbers for matching lines when saving or loading and not the decompiled ones (in the Eng folder) with the altered line numbers, and only after the line number is found does it try to match it with the accompanying text, but this time it uses the decompiled script and so it fails or at best prints the wrong line. If this is so, and if editing the way saved games are handled by the .exe is at all possible (i.e. in the same way it can be told to use stuff in the Eng folder instead of in the .bin files while running the game), it could end up being an easier solution than having to remove empty lines etc in order to conform perfectly with the original text's line numbers.

But anyway, this is all baseless speculation on my part, because I still have no real idea of how the .exe is supposed to be working. I'll try to look into it as well and report back.

Link to comment
Share on other sites

If you take a look at the savegame, it remembers the text when saved:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000000F0  F6 54 68 61 6E 6B 66 FF 75 6C 6C 79 2C 20 69 74  öThankfÿully, it
00000100  FF 20 77 61 73 20 6A 75 73 FF 74 20 66 61 74 69  ÿ was jusÿt fati
00000110  67 75 FF 65 2C 20 62 75 74 2E 2E FF 2E 00 74 6F  guÿe, but..ÿ..to
00000120  20 68 65 72 FF 20 72 6F 6F 6D 20 74 6F FF 64 61   herÿ room toÿda

I compared all files with kdiff3 and searched for broken lines, and yes, the main problem is the saving / loading behavior from the game.

Luckily, it doesn't happen when saving at schedule or decisions to make.

I have already translated a few games, i learned that the best solution is not to make huge changes when encountering such problems like in musumaker hd.

To keep files close to their original, also allows easier tracing if you encounter any problems.


Link to comment
Share on other sites

Okay, well there's a couple options:

1. Leave the patch as is and just rely on saving at schedule or decisions.

2. Revert back to scripts without line breaks or @ character for narration. This will keep the scripts closer to their original, but will make the quality of the text box worse. It will A) introduce an indent to all narrated text and B) make new lines in between words in the game.

Link to comment
Share on other sites

1 hour ago, Hoshimaru said:

As the state is already around 56%, i would personaly go with option 1. until the translation is 100% complete.

Later ingame, it's just a few lines away from next schedule or decisions. Just stamp it as known Bug for greater justice :)

Thus, i think the translation is more important - thank you for your work @RaurosFalls

I agree, it is easy enough to save at each schedule. Better to focus on the translation and maybe someone will fix the save bug somewhere down the road. Just add a note to the patch download about it to prevent people saturating the posts about it.

Edited by Alistoru
Link to comment
Share on other sites

@RaurosFalls I too think that you should move forward with the translation. For starters, there is the already known workaround: saving on the schedule and decision screens, where there aren't any strings involved, should be absolutely safe; and seeing as these two screens are very frequent, it should suffice for the time being - just make sure to warn users on the first page about the beta nature of the patch. Meanwhile, @Hoshimaru and I (or Tymmur, or whoever else decides they're interested enough to give it a try) will be looking into the issue and trying to find what causes it and how it can be resolved. Hopefully, by the time you're done with the translation (not to mention the editing) it will have been fixed.

Now, about the issue itself, what I think I know (read: I could be completely off the mark) is the following.


Let's say we have this script:

1 @Itsuki
2 So, Mikan. Let's begin.
4 @Mikan,A00483
5 What are we doing today?
6 ...

When this script first loads, the dialog box displays the string "So, Mikan. Let's begin."

I save the game as Save1, then I move forward one line so "What are we doing today?" displays in the dialog box; then I save again as Save2.

Now, if I try to load Save2 I will get an error, like so:


ERROR : ...
What are.

This apparently means that the game tried to load the script at line 5.

Let's say I then edit the script and add an extra empty line so that line 5 contains the '@' string (which is presumably what the game is really trying to load):

1 @Itsuki
2 So, Mikan. Let's begin.
5 @Mikan,A00483
6 What are we doing today?
7 ...

Voila, the game correctly loads Save2 and "What are we doing today?" is displayed on the screen.

But then let's try this: I reload Save1, move once more 1 line forward so "What are we doing today?" is displayed, and save the game again as Save3. What happens if I try to load Save3? Yup, I get the same error again, apparently because Save3 yet again points to the wrong 'n+1' line (which by now is line 6) instead of line 'n' (i.e. line 5). And this off-by-one error manifests itself every single time I save the game (line 6 becomes line 7, line 7 becomes line 8... ad infinitum), even on successive tries.

So, this is my guess: as already attested, when the game saves the current state it doesn't store a line number but the actual string itself (which IMHO is kind of dumb in and of itself, but anyway). The problem is that it needs to be saving the string containing the '@' symbol, but for some reason it instead saves the next line, so when it loads it back it erroneously ends up fetching a seemingly malformed string and it fails. Or some such.

That's all for now. Oh, and Rauros, I think this probably isn't an issue with the line breaks because the original files contain the exact same line breaks as the translated ones, and they worked properly when I tested them; and also because this issue happens even on lines that are only a few words long, without any custom splits.

Also, I noticed you said "Revert back to scripts without line breaks or @ character for narration". I thought the '@' character was present and used in the originals as well? If it's not, then does that mean the originals I'm looking at (which include '@') are not the real originals?

Edited by Bokun
Link to comment
Share on other sites

Alright, I'll include a note on the first page about the save issue.

1 hour ago, Bokun said:

Also, I noticed you said "Revert back to scripts without line breaks or @ character for narration". I thought the '@' character was present and used in the originals as well? If it's not, then does that mean the originals I'm looking at (which include '@') are not the real originals?

You're looking at the real originals. It's just that the translated scripts contain @ on narration lines too, with nothing after it. This is what's mucking up the line numbers.

Link to comment
Share on other sites

Yeah, I realized what was meant right after I posted. But I'm not so sure that is what's responsible here. If one starts a new game and then at the very first dialog line ("Dad, look at this!") saves the game and reloads, the error will still pop up. There are no extra @ lines for narration there, nor anything else that makes the script different from the original up to that point. So unless there is some other script loaded before what I presume is the very first one (prologue/youzyo.txt) that could potentially mess things up, then it is almost certainly something else at fault here.

EDIT: Alright, so I took the original, completely clean and devoid of any extra @ characters, Japanese youzyo.txt script and replaced the translated one with it. Result: the game that I had saved at the very first dialog block while running the English version of the script, the one that crashed just like all the others, loaded correctly and showed the Japanese text. I then replaced just the first dialog block (@Itsuki + "Dad, look at this!") with the English text. Result: the game gave me the usual '='がありません error and crashed. Then I replaced only the @ line, result: error. I replaced only the dialog line leaving the @ line in Japanese, result: error. Then on a hunch I replaced both the @ line and the dialog line with the English text, but this time I left the Japanese quotation marks「」in as well, and what do you know... it worked. So then I put the English version of the script back, with all its extra lines and extra @ characters and what have you, and I added some「」to the dialog lines, and guess what - it worked again. Finally, I took a random problematic save from about a month's game time in (the one I used in my previous tests), I added「」to the respective dialog lines and it too worked without a hitch.

So, barring the possibility that I'm chasing butterflies here, it seems that internally the engine is using these「」(well, probably only the leading「 is needed, but visually they come as a set) as the actual string delimiter between the nameplate and the dialog text (just as it's using the @ to delimit between whole dialog blocks) and removing them is what breaks the parser.

Pinging @RaurosFalls: could you maybe produce a version of the patch that leaves all the「」alongside the English text, without changing anything else, so we can test if what I'm seeing here is true? Thanks.

EDIT 2: Some more concrete observations.


1) It doesn't have to be a「 after all, all that's needed is to have a Japanese character in the first position of the string, e.g. a 。would be enough. But some characters apparently won't work, e.g. I tried 〜 and unfortunately it crashed with the same '='がありません error.

2) The lines that belong to the narration do not need a @ as the nameplate designator as far as I can tell, they load properly without it; BUT, they also need to begin with a Japanese character (in the original scripts this character is just a normal kana belonging to the narration text) otherwise they break as well. I guess in the translated scripts they seem to be working at first glance due to that @ character which probably counts as "a Japanese character in the first position of the string", but on reload the script breaks due to the text being interpreted as a split line (see nr3 below).

3) When the string begins with a Japanese character, deliberately split lines are a no-go because when reloading a saved game, the parser will yet again try to load the last string it finds in the dialog block and it will break with the '='がありません error. If there is any way that this behavior can be altered, I guess it would be by tweaking the .exe itself (assuming the save/load mechanism is actually stored in there).

4) On the other hand, if one follows these guidelines (@ for the nameplate, Japanese character in string's first position, no split lines) one can add as many extra dialog blocks as desired and they will all display and reload correctly. Which means, the game can be considered moddable :P

Please take the above with a grain of salt, I haven't really had the time to test extensively so I may have overlooked something crucial and thus reached completely wrong conclusions.

Edited by Bokun
Link to comment
Share on other sites

@darkmage2015 and @Raum

You're playing the non-fixed karin_qa script. You have to reapply the updated patch.


Thanks, you found the reason why the game won't save. I'm working on making a patch now that has a Japanese character at the start of every line.

Edit: Okay, I've updated the patch so that saveload works now. For dialog, it has 「」wrapping and for narration, there is a space/indent. I should've known this would be an issue. There was the same limitation in the 2008 version of the game.

Edited by RaurosFalls
Link to comment
Share on other sites

Hmm, I realized there's still a couple issues with the current patch:

1. For lines with that are split (i.e., have multiple lines for one text dialog), the saveload function is still broken.

2. I have not added 「」wrapping to all the scripts -- only about half of them. I have someone working on adding it to all of them.

Edited by RaurosFalls
Link to comment
Share on other sites

When I start the game and get to the title menu, a box pops up saying

CSurface::"updates\Parts\title\button_manual.png" File not found

When I click ok, it then says the same with button_manual_over.png, button_movie.png, button_movie_over.png.

The menu works fine, so that part isn't a problem. The real problem is that when I get to the interactive part of the training scenes, the same thing happens, with the various parts of the girls bodies, and only parts of the bodies appear. With Ichigo, there is just a bald head that shows up without the body.

The error messages there show as:

CSurface::"updates\training\ev_ich_140\ev_ich_140_hair_front.png" File not found,

and with ev_ich_140_body_back.png, ev_ich_140_body_front.png.

I tried redownloading and applying the patch, but still the same problem. Am i missing part of the files? The rest of the game properly shows up in english.

PS: I tried the regular Japanese EXE and it works fine.

Edited by Random8261
Missing info
Link to comment
Share on other sites


That's a problem on your end and not the patch. It sounds like you need to reinstall the game.


Now that I look at it, it seems to be an issue with your updates.bin file maybe look and see if it's still there


Edited by Raum
Link to comment
Share on other sites


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...