Clannad Game Translation Project

[Jecht2]

Originally Posted by Polarem

That's the plan! Would be better if we can get hold of the core team though; anyone know where to find them?

You can always try contacting Velocity7 through his twitter feed. He seems to update that semi frequently.

[Xcandescent]

Originally Posted by Polarem

The Python script needs to be changed (I don't know how)... Currently, any spaces we add to to the end of a line in kepago_translations.txt will be stripped.

It does compile as-is though... you'll just see lots of missing spaces whenever Sunohara gets kicked around by Tomoyo.

Hmm ... OK. I don't know Python either, but it shouldn't be too hard to figure out what's happening in that script just from reading the Python documentation. If I have time, I'll poke at it.

Originally Posted by Polarem

If you're happy to install the Qt SDK and PM me your email address, I'll send you the source code for the program I wrote to grab the Wiki pages. Or, I can send you the binaries for Windows if you don't want the SDK (it's 32-bit, but should run under 64-bit Windows)

Source is fine. I'll PM you my E-mail later.

Originally Posted by Polarem

No... all my environments are 32-bit, sorry.

Don't be; I think that's why you were ultimately able to build the tools.

On further poking around, I think the issue I ran into is something similar to this bug in 3.11.0. Since I'm not a complete masochist, I'm not going to try another rebuild ... but maybe that'll be a good starting point if anyone else wants to try a 32-bit build under a 64-bit OS. Fun fact: the last official OSX binaries for OCaml 3.09 were built for Tiger ... which was the last 32-bit iteration of OSX.

Originally Posted by Polarem

Yea, I saw the de-sync incident. It was a shame, since his changes were great! Oh, did they have a script hat could tell which lines to keep? I compared them manually and imported them into the Wiki. Looking back now... I must be crazy.

Check out the "wiki-merge" branch. There's a bit of JavaScript there that seems to have been used to sync changes from SVN to the Wiki. Of course, if you went back and manually synced things by hand, you would actually know if that script had been run or not, but from the discussion, it looks like that was the plan.

Originally Posted by Polarem

Hehe, I hear ya! I thought Clannad is too good a story to be told with a mediocre presentation. Some of the graphical text is crucial to the story too, like...

Spoiler for important story bit:

...the last thing said by the girl in the Illusionary World: "Sayounara, Papa". I misread it as "sayounara pa-pat-su" at first, so was very confused. Got goosebumps when I realized the proper meaning later.

Yeah, the graphical text is crucial, esp. when you realize how much of it is spoken out loud (and translated) on the DVD's for the anime.

Originally Posted by Polarem

It'll be great if you can find Jap-speakers to pitch in; I've been unsuccessful so far Feel free to pick a SEEN and proofread, too.

I've pointed a couple of people to the BT wiki, and mentioned that there's basically only a couple pages left to translate. Hopefully something good will happen.

I have no problem with proofreading things in English, but it's frowned upon by the core team, due to the potential for rewording things in a way that doesn't match the meaning/intent of the original Japanese. That said, I've seen a fair bit of awkward wording just playing through the beginning, and I don't think a little clean-up would hurt ... but it's not something I'd be comfortable doing on the Wiki.

-XCN-

[Xcandescent]

Originally Posted by Khu

Wow, this thread has become the home for the team.

CARRY ON, GOOD SIRS.

Well, to be fair, it started as the home for the core team, before they vanished into thin air.

I wouldn't consider myself to be part of that team; more like a random fan who's desperate to see the project wrapped up, and knows just enough to be able to run build scripts, but not much more. There's not a whole lot I can do, besides be a cheerleader for new translators.

Given the choice, I'd much rather see the core team finish this up ... but given that the last beta (r78) shipped in July 2009, you can understand why I'm skeptical of that ever happening. So I'm just doing what I can.

Or, to be blunt: if this was a stalled-out open source project, it would've been long since forked by another team, finished, and released as a completed rough edit/beta. I don't know the etiquette of how that works with fan translations (or what sort of drama that would entail), but that's definitely how it works for open source code.

-XCN-

[Xcandescent]

The good news is I think I've fixed the Python script. The bad news is I've had a closer look at the .ke files in the keksmeister_bugfix branch from SVN, and they're in some weird half-fixed state -- some of the strings have already been replaced, some haven't. Example: SEEN0414.ke already has English replacements on lines 14-15.

So if there are already places where "Whump!" or "Whuump!" have been previously inserted, they'd have to be found and replaced with extra space versions BEFORE replacing the remainder of the Japanese text. Either that, or there would need to be code to check whether there's trailing spaces before an EOL. Probably a piece of cake for anyone familiar with Python ... which I am not.

Anyway, in apply_ke_translation.py, replace line 19 with:

tl_dict[lines[i].rstrip('\r\n')] = lines[i+1].rstrip('\r\n')

Then add extra spaces at the end of the "Whump!" and "Whuump!" lines in the kepago_translations.txt file before you run the new script.

I thought about regenerating the .ke files in a disassembly and running the script on that ... but I just found out my build of rldev (the patched version from Assembla SVN) isn't disassembling properly, as the outputs are subtly different from the working versions in keksmeister_bugfix; it's adding extra lines that shouldn't be there, and it's not outputting font size tags properly. No idea why, and no real way to troubleshoot. I can still build a working SEEN.txt, thankfully.

-XCN-

[Polarem]

Originally Posted by Jecht2

You can always try contacting Velocity7 through his twitter feed. He seems to update that semi frequently.

Ok, I will do that. Thanks!

Originally Posted by Xcandescent

Check out the "wiki-merge" branch. There's a bit of JavaScript there that seems to have been used to sync changes from SVN to the Wiki. Of course, if you went back and manually synced things by hand, you would actually know if that script had been run or not, but from the discussion, it looks like that was the plan.

Ah, so they did. Hmm... that script only replaces the entire Wiki page with the SVN version though... it would've been Bad News if the script was run, as any updates on the the Wiki would've been wiped.

Originally Posted by Xcandescent

Yeah, the graphical text is crucial, esp. when you realize how much of it is spoken out loud (and translated) on the DVD's for the anime.

There's a good point for consideration... do you think we should make the VN dialogues match their anime counterparts?

Originally Posted by Xcandescent

I've pointed a couple of people to the BT wiki, and mentioned that there's basically only a couple pages left to translate. Hopefully something good will happen.

Huzzah!

Originally Posted by Xcandescent

I wouldn't consider myself to be part of that team; more like a random fan who's desperate to see the project wrapped up

Same here... I jumped on board hoping to help iron out the final wrinkles in the project. Was a bit shocked to find it stalled, and wasn't quite sure what to do, so I decided to start cleaning until the core team comes back.

Originally Posted by Xcandescent

I don't know the etiquette of how that works with fan translations (or what sort of drama that would entail)

That's something I forgot to consider :-S Maybe I should stop editing until I talk to one of the project leaders.

Originally Posted by Xcandescent

Anyway, in apply_ke_translation.py, replace line 19 with:

tl_dict[lines[i].rstrip('\r\n')] = lines[i+1].rstrip('\r\n')

Then add extra spaces at the end of the "Whump!" and "Whuump!" lines in the kepago_translations.txt file before you run the new script.

That did the trick; great work!

Spoiler for Before+after screenshots:

Originally Posted by Xcandescent

The bad news is I've had a closer look at the .ke files in the keksmeister_bugfix branch from SVN, and they're in some weird half-fixed state -- some of the strings have already been replaced, some haven't.

That's actually not an issue They only translated names to fix certain bugs (as seen from the SVN logs and diffs). No "Whumps" or anything like that have been inserted.

Now that reminds me: There are still some bugs to fix (e.g. Fuuko prank selections aren't spaced properly, + they "spill" out of their text boxes; there are still BGM issues when gaining Fuuko Master). Time to learn Kepago...?

Originally Posted by Xcandescent

I thought about regenerating the .ke files in a disassembly and running the script on that ... but I just found out my build of rldev (the patched version from Assembla SVN) isn't disassembling properly

rldev's algorithms are "lossy"; you can't regenerate the source files from the output, especially if it's translated (I think kprl relies on the presence of Japanese text as guidance).

BTW, did you manage to get proper English .utf files from kprl? When I tried, my lines were filled with "\s{strS[1901]}" instead of translated game text.

[Xcandescent]

Originally Posted by Polarem

There's a good point for consideration... do you think we should make the VN dialogues match their anime counterparts?

Well, they'll sort of match anyway, since they're basically the same thing, but the translation should be a translation of what's actually said in the game (which I'm finding can differ in subtle ways from the anime).

Originally Posted by Polarem

That's something I forgot to consider :-S Maybe I should stop editing until I talk to one of the project leaders.

Well, it's a moot point while B-T is down, but there are guidelines for changes and submissions. I don't believe they'd discourage a contribution, and ultimately it's their responsibility to keep the Wiki cleaned up. What we're doing here isn't really forking the project at all; it's more or less wrapping up the .0001% that's left for a rough translation.

I personally think it's OK to fix blatant errors like misspellings or word swaps (one of which I ran into during a play test today), but anything concerning word choice should be left to a translator (and probably * for an editor's attention).

Speaking of B-T ... does that script you sent me request files from the Wiki one at a time, or all at once?

Originally Posted by Polarem

That did the trick; great work!

Sweet! I haven't gotten to that point in the game yet, so I had no way to test it.

Originally Posted by Polarem

That's actually not an issue They only translated names to fix certain bugs (as seen from the SVN logs and diffs). No "Whumps" or anything like that have been inserted.

OK, cool. Actually, on the topic of weirdness in files -- have you noticed untranslated <9999> lines in some of the UTF's? Because I have, and I don't get what they're there for. They usually show up in the middle of a file, seemingly out of line order.

Originally Posted by Polarem

Now that reminds me: There are still some bugs to fix (e.g. Fuuko prank selections aren't spaced properly, + they "spill" out of their text boxes; there are still BGM issues when gaining Fuuko Master). Time to learn Kepago...?

(shudder) It may be an easier fix than that ... hopefully.

Originally Posted by Polarem

rldev's algorithms are "lossy"; you can't regenerate the source files from the output, especially if it's translated (I think kprl relies on the presence of Japanese text as guidance).

Well, the problem isn't getting back source files -- it's that I'm not generating identical .ke bytecode dumps to what's in SVN. That bothers me because I don't know if it's an issue with kprl, with ocaml, or something else. As it stands, I still can't get OCaml 3.09.3 to pass its own bootstrap test on Cygwin -- it always fails at the exact same point. I can build the native code compiler and the rldev toolset, but I have no guarantee that they're built correctly.

Oddly enough, I was able to get a proper OCaml 3.09.3 build running on Leopard (which defaults to 32-bit builds). However, the resulting kprl build keeps choking on SEEN7500. However, the questionable kprl on Cygwin has no issues with it, and the resulting SEEN.txt seems to run fine (at least, as far as I can tell without 300 hours of testing). Basically, I have zero confidence in the toolchain, and would feel much more comfortable if the code was updated to OCaml 3.11 or 3.12 -- but that ain't happening.

Originally Posted by Polarem

BTW, did you manage to get proper English .utf files from kprl? When I tried, my lines were filled with "\s{strS[1901]}" instead of translated game text.

I'm a little confused -- are you saying that your SEEN.txt builds are causing weird characters to be printed in-game? Or is this a question about disassembling one of the beta builds which already have some translated text? I haven't tried the latter yet.

-XCN-

[Polarem]

Originally Posted by Xcandescent

I personally think it's OK to fix blatant errors like misspellings or word swaps (one of which I ran into during a play test today), but anything concerning word choice should be left to a translator (and probably * for an editor's attention).

I see. Besides the awkward expressions, there are numerous mistranlations in the current text (e.g. see this diff), so it's in the "awkward + altered" state. My thought was that if we remove the awkwardness and move it into just the "altered" state, it'll still be a step forward.

When I first started I restricted myself to correcting typos (there's many of those in the After Story), but the urge to work on the awkward expressions was hard to ignore. As a precaution, for any edit that caused subtle (or massive) changes in meaning, I marked the line and retained the original in the comments for review if necessary. Ended up making many many marks though

Originally Posted by Xcandescent

have you noticed untranslated <9999> lines in some of the UTF's?

In SEEN6430, the text isn't displayed properly when 2 people speak simultaneously. I THINK the Jap version duplicates the line but rlBabel can't do that, so the devs hard-coded a new line (labelled <9999>, because that's easier than re-numbering all the other lines) into the script.

Not sure about the rest though... I marked them in my "to-investigate" list but haven't looked at it since.

Originally Posted by Xcandescent

I'm not generating identical .ke bytecode dumps to what's in SVN.

Do you mean your SEENxxxx.ke are different from the SVN's? If I'm not mistaken, the SVN files were disassembled from the Japanese SEEN.txt, and then modified by hand (e.g. the <9999> hack) so the code structure would be different from how a machine would produce it. Plus, rldev seems to be unable to understand an English SEEN.txt the same way it understands a Jap one... When I disassemble a beta build (or my own personal build), I get:

Spoiler for code comparison:

// Pre-compiled English SEEN7500.utf
<0000> Tap, tap, tap... so Misae-san runs inside.
<0001> She stops in front of a single door.
<0002> \{Misae} "Here, right?!"

// After compiling and dececompiling
<0000> \s{strS[1901]}
<0001> \s{strS[1901]}
<0002> \s{strS[1901]}

The text is left in the .ke file, andthe \s{} code was extracted into the .utf file. I wanted to know if you get this too, to see if it's because of rldev's code or because of my installation.



Regarding OCaml and rldev, the same Cygwin bootstrap problem drove me to Ubuntu. Even then, the tests failed on extlib's database and graphics modules, so mine's not a fully-stable build... I actually have trouble with SEEN7500 too; if you got a Ulex exception, try removing the {- -} block quotes.

[Xcandescent]

Originally Posted by Polarem

Besides the awkward expressions, there are numerous mistranlations in the current text (e.g. see this diff), so it's in the "awkward + altered" state. My thought was that if we remove the awkwardness and move it into just the "altered" state, it'll still be a step forward.

When I first started I restricted myself to correcting typos (there's many of those in the After Story), but the urge to work on the awkward expressions was hard to ignore. As a precaution, for any edit that caused subtle (or massive) changes in meaning, I marked the line and retained the original in the comments for review if necessary. Ended up making many many marks though

Yeah; reading through those diffs was painful; I can't believe some of the original wording made it in at all.

OK, I can see where you're coming from, and given that everyone else is AWOL, I think you're correct in addressing the awkward wording, as long as it's flagged for review. Of course, in the cases above, you had an alternate option given to you by another translator, so that's an easier call than changing up wording without knowing Japanese.

What's really needed here is another translator. Not an editor, but a translator on-call, who can give us options whenever you run into really awkward lines. That would keep the project moving forward, and if an editor from core-team wants to revert the changes, they can do so later. Maybe put up a "to fix" log pointing to things that need re-translation?

Originally Posted by Polarem

Do you mean your SEENxxxx.ke are different from the SVN's? If I'm not mistaken, the SVN files were disassembled from the Japanese SEEN.txt, and then modified by hand (e.g. the <9999> hack) so the code structure would be different from how a machine would produce it. Plus, rldev seems to be unable to understand an English SEEN.txt the same way it understands a Jap one... When I disassemble a beta build (or my own personal build), I get:

// After compiling and dececompiling
<0000> \s{strS[1901]}
<0001> \s{strS[1901]}
<0002> \s{strS[1901]}

The text is left in the .ke file, andthe \s{} code was extracted into the .utf file. I wanted to know if you get this too, to see if it's because of rldev's code or because of my installation.

OK, it's good to know that the code was hand-edited later. I didn't notice any comments in the diffs on the one file I ran, so I assumed something went wrong in the disassembly of my Japanese SEEN.txt.

I probably won't have the time to try a disassembly of an English SEEN.txt today, but I will check it as soon as I can. (I'll have to do it in both Cygwin and Leopard for comparison.)

Originally Posted by Polarem

Regarding OCaml and rldev, the same Cygwin bootstrap problem drove me to Ubuntu. Even then, the tests failed on extlib's database and graphics modules, so mine's not a fully-stable build... I actually have trouble with SEEN7500 too; if you got a Ulex exception, try removing the {- -} block quotes.

OK, I'll try that the next time I hit Leopard. It was throwing Ulex errors ... something about missing commands. It's good to know that it may just be issues with that one file, and not the build.

B-T looks to be back up again. May need to look into scripts to back up the wiki for the next time it implodes.

-XCN-

[Polarem]

Originally Posted by Xcandescent

What's really needed here is another translator. Not an editor, but a translator on-call, who can give us options whenever you run into really awkward lines. That would keep the project moving forward, and if an editor from core-team wants to revert the changes, they can do so later. Maybe put up a "to fix" log pointing to things that need re-translation?

Agreed... we need to be able to know what the lines mean on demand before we can make truly useful progress. I don't know where to find them though; this is the first translation project I got involved in. The only translator I've ever spoken to is GundamAce who's currently translating Never7 by himself, and he has also signed up for a few other projects. I guess it won't hurt to try asking him for occasional help.

I grew up in a Chinese elementary school (so Kanji isn't too daunting) and am learning Japanese now, but haven't reached the competency required for Clannad... really felt it when I was trying to decipher the After Story. Should've started learning earlier!

The wiki did have a log system going, but it's starting to look unmanageable. Inline asterisks and comments are easier to use... Ctrl+F (or grep) finds them quickly.

Originally Posted by Xcandescent

It was throwing Ulex errors ... something about missing commands.

Uh oh... mine simply says "Fatal error: exception Ulexing.error" after loading SEEN7500.utf, with no mention of missing commands. I hope that doesn't mean that different builds have different issues.

Originally Posted by Xcandescent

B-T looks to be back up again. May need to look into scripts to back up the wiki for the next time it implodes.

Tarballs.

[Polarem]

First attempts to modify reallive.exe and graphical text... success!

Spoiler for Movie settings:

Spoiler for Kotomi's almost-epilogue:

Almost 4 months too early for Kotomi's birthday, but oh well.

When translating reallive.exe, there seems to be odd limitations on how much text I can embed... write too much and the .exe blows up in size, then refuses to run. I haven't figured out the rules yet... It seems like the I'm allowed less English text than Japanese text.

As for Kotomi's story text, the top-left corner of each line is defined in SEEN.txt. I can safely make each line wider, but it'll be off-center. If we want longer lines we'll need to modify the .ke code.

[Xcandescent]

Originally Posted by Polarem

The wiki did have a log system going, but it's starting to look unmanageable. Inline asterisks and comments are easier to use... Ctrl+F (or grep) finds them quickly.

It's only unmanageable, because the editors aren't editing. (There's entries in there from 2008.) If we can find more translators, then a separate log that actually gets updated and cleaned out may be OK.

Originally Posted by Polarem

Uh oh... mine simply says "Fatal error: exception Ulexing.error" after loading SEEN7500.utf, with no mention of missing commands. I hope that doesn't mean that different builds have different issues.

I tried it again in Leopard, and this time it threw the Ulex error. However, the error didn't go away when I eliminated the block quotes (which a quick look at the RLdev manual says shouldn't be there anyway, because they're un-nestable). I think the fact that I can build it to completion in Windows means that there ARE platform-specific build issues -- and because of OCaml 3.09.3 being a trainwreck on Cygwin, there's no real way to sort out where the problem lies.

Also, I attempted to disassemble r78 on Cygwin and Leopard. The results were flat-out disastrous -- it kept choking and aborting on each file. Curious, I tried disassembling one of my own SEEN.txt builds; it still choked on Leopard, but on Cygwin, it was slightly better; there were only a few files it couldn't decompile. HOWEVER, it was utterly unable to separate the text strings from the code, resulting in .utf files with the \str[] nonsense you mentioned, and .ke files with the dialogue still embedded in the code.

So, as of right now, I have no rldev toolchain that can properly decompile its own SEEN.txt builds. However, on reading (and re-reading, and re-reading) the INSTALL readme, I did notice a couple of things I missed the first few times (specifically, that configure default encoding option.) (facepalm) However, a cursory search through the rldev manual shows only two references to default encoding -- and for the purposes of kprl, specifying "-e UTF-8" (which I always do) should do the exact same thing. A quick grep of the source code seems to confirm this; the variable "default_encoding" is only referenced in kprl and rlc; it acts as default output encoding for kprl, and default input encoding for rlc. I don't think it warrants a rebuild.

Originally Posted by Polarem

First attempts to modify reallive.exe and graphical text... success!

Awesome!

Originally Posted by Polarem

When translating reallive.exe, there seems to be odd limitations on how much text I can embed... write too much and the .exe blows up in size, then refuses to run. I haven't figured out the rules yet... It seems like the I'm allowed less English text than Japanese text.

Huh. If it's throwing errors on a byte-for-byte replacement, then I guess there are other things at play. I do recall the DirectX dialog having multiple lines per option, but I dunno how those lines are packed in the executable.

Originally Posted by Polarem

As for Kotomi's story text, the top-left corner of each line is defined in SEEN.txt. I can safely make each line wider, but it'll be off-center. If we want longer lines we'll need to modify the .ke code.

Oof. Well, I guess it can't be helped.

-XCN-

[Polarem]

Originally Posted by Xcandescent

It's only unmanageable, because the editors aren't editing. (There's entries in there from 2008.) If we can find more translators, then a separate log that actually gets updated and cleaned out may be OK.

Good point. I've dropped a message at Velocity7's blog (message was too long to fit in a Twitter feed). Fingers crossed for a reply!

Originally Posted by Xcandescent

the error didn't go away when I eliminated the block quotes (which a quick look at the RLdev manual says shouldn't be there anyway, because they're un-nestable).

Odd... they've been on the Wiki for years now, so I assumed that others could compile it, just me...

Anyway, there are two blocks of quotes: After <1408> and <2702>. Did you get rid of both?

Originally Posted by Xcandescent

because of OCaml 3.09.3 being a trainwreck on Cygwin, there's no real way to sort out where the problem lies.

I think so too. So now I'm just using the parts of rldev that work. Being able to compile a working SEEN.txt was what I was most concerned with, hehe. It would've been great if OCaml had better backwards compatibility.

Originally Posted by Xcandescent

Also, I attempted to disassemble r78 on Cygwin and Leopard. The results were flat-out disastrous -- it kept choking and aborting on each file.

Does this help?

Originally Posted by Xcandescent

it was utterly unable to separate the text strings from the code, resulting in .utf files with the \str[] nonsense you mentioned, and .ke files with the dialogue still embedded in the code....

....I don't think it warrants a rebuild.

I'm getting more and more convinced that rldev is incapable of properly disassembling English SEEN files, not because the build is broken. kprl -S suggests to me that it looks for Japanese text to decide what to extract. Also, I'm able to use my build to disassemble a Japanese SEEN.

[Zenemis]

Don't mean to be a stalker or 'nothin, but Velocity7 is active on the forums, so you might be able to PM him

[Xcandescent]

Originally Posted by Polarem

Odd... they've been on the Wiki for years now, so I assumed that others could compile it, just me...

Anyway, there are two blocks of quotes: After <1408> and <2702>. Did you get rid of both?

Both are fixed now, as well as a word swap in SEEN3416 I ran across during gameplay. All files from Wiki will now compile in my Leopard toolchain.

There are a couple of things that are telling about this bug. The first is that my Leopard toolchain was behaving correctly, because the RLdev manual clearly states that you cannot nest comments. The second is that, when playing through my freshly-built SEEN.txt from Leopard, I realized that my old build from Cygwin had at least one major bug: it was skipping one of the choices during the "rap" sequence in Sunohara's room -- a choice that was both available AND produced the correct responses later in the classroom with my Leopard rldev.

Conclusion: My rldev toolchain on Cygwin is completely broken. It's producing incorrect builds, and it's doing so silently. If core-team was building using a similar toolchain, they would've never seen the compilation error. I plan on doing all my test builds on Leopard from here on out.

Originally Posted by Polarem

Does this help?

Nope; the FV key is actually built into the version of rldev in SVN, and should be invoked by default.

Originally Posted by Polarem

I'm getting more and more convinced that rldev is incapable of properly disassembling English SEEN files, not because the build is broken. kprl -S suggests to me that it looks for Japanese text to decide what to extract. Also, I'm able to use my build to disassemble a Japanese SEEN.

That's my gut feeling as well, though I haven't had time to dig into the code to verify it.

On a different topic, I have a feeling that this bug is going to be hell to troubleshoot. The weird formatting on the save/load screens is somewhat minor, but having poorly formatted choices during Fuuko's route is bad news.

-XCN-

[Polarem]

Originally Posted by Xcandescent

Both are fixed now, as well as a word swap in SEEN3416 I ran across during gameplay. All files from Wiki will now compile in my Leopard toolchain.

Error-free compilations are great, eh? Now, to eliminate those compiler warnings! Keep those corrections coming too.

Originally Posted by Xcandescent

my Leopard toolchain was behaving correctly, because the RLdev manual clearly states that you cannot nest comments.

I thought that meant we can't nest BLOCK comments, like C/C++, so that the preprocessor doesn't need to keep track of how many block openings it has encountered so far; it's trivial to ignore line comments in a block comment.

My rldev also borks when I put the line "{- -}" anywhere in a .utf file. But we don't have to worry about those anymore.

Originally Posted by Xcandescent

I realized that my old build from Cygwin had at least one major bug: it was skipping one of the choices during the "rap" sequence in Sunohara's room -- a choice that was both available AND produced the correct responses later in the classroom with my Leopard rldev.

Do you mean that you didn't get to choose to say something fitting/stupid even though you wanted to mess up his tape? That's the expected behaviour IF it's your first playthrough... The option to say stupid things only comes up after you start "New game" again. (confirmed with an unpatched Japanese game)

Originally Posted by Xcandescent

Nope; the FV key is actually built into the version of rldev in SVN, and should be invoked by default.

You're right, it chooses the correct key once the target is supplied. What's even better is that it can decompile Clannad ME too! (haven't tested the output yet though)

Originally Posted by Xcandescent

The weird formatting on the save/load screens is somewhat minor, but having poorly formatted choices during Fuuko's route is bad news.

Oyes...

Spoiler for Prank screenshots:

It looks somewhat acceptable if the text is within the box... A possible workaround is to shorten the text, if we can't fix rlBabel.

[Polarem]

Originally Posted by Zenemis

Don't mean to be a stalker or 'nothin, but Velocity7 is active on the forums, so you might be able to PM him

*facepalm* ... I can't believe I didn't think of looking up his stats... just assumed he's inactive here 'cause he hadn't posted in Clannad forums in ages. I need to improve my stalking skills.

Thanks for the tip, Zenemis. But just so that I don't act like a stalker, I'll wait a bit more for a reply before sending him another message.

[Xcandescent]

Originally Posted by Polarem

Error-free compilations are great, eh? Now, to eliminate those compiler warnings! Keep those corrections coming too.

Well, it was nice while it lasted, but ...

Originally Posted by Polarem

Do you mean that you didn't get to choose to say something fitting/stupid even though you wanted to mess up his tape? That's the expected behaviour IF it's your first playthrough... The option to say stupid things only comes up after you start "New game" again. (confirmed with an unpatched Japanese game)

To be clear: if you start a New Game without finishing it, save it, and start another New Game, you get the new options? Or is this some sort of "New Game+" feature that kicks in after you've completed a route? (And where the heck is the code that checks for that? Ick.)

So far, I've ALWAYS gotten the additional options to say stupid things, using the SEEN.TXT built with my Leopard toolchain. Arrrrgh. I suspect this is going to require a lot of Kepago debugging.

Originally Posted by Polarem

I thought that meant we can't nest BLOCK comments, like C/C++, so that the preprocessor doesn't need to keep track of how many block openings it has encountered so far; it's trivial to ignore line comments in a block comment.

I don't know. The manual does not define the proper behavior, outside of nesting blocks in blocks (which you can't). The test would be to use block comments with no nested line comments, and see what happens.

Originally Posted by Polarem

It looks somewhat acceptable if the text is within the box... A possible workaround is to shorten the text, if we can't fix rlBabel.

Shizuka's read of the problem is that rlc is not hooking in the necessary calls to rlBabel when parsing calls to select_s(). That's the Kepago function that generates multiple choice buttons in the middle of the screen, and I'm guessing it has a direct bytecode equivalent in RealLive (vs. being implemented in rlc using custom bytecode routines). The only ways to confirm this are to either step through the compiled bytecode to see what's being called (which implies knowing the bytecode calls involved in triggering rlBabel and/or select_s()), or to dig through the rlc source, and compare how ordinary text strings are processed, to strings passed to select_s(). Neither approach is trivial. There's a third possibility, which is that rlBabel IS being called, but the #SELBTN variables in GAMEEXE.INI aren't set properly (specifically the MOJI variables, which have caused problems in the past with normal text). This is unlikely, as there is zero documentation for those variables, and we don't know if rlc even processes them.

-XCN-

[Xcandescent]

Originally Posted by Xcandescent

To be clear: if you start a New Game without finishing it, save it, and start another New Game, you get the new options? Or is this some sort of "New Game+" feature that kicks in after you've completed a route? (And where the heck is the code that checks for that? Ick.)

UPDATE: I went back and re-tested this after nuking the savegame directory. I don't get the secondary option anymore for the Sunohara rap, even after saving and restarting. If that option really was intended for a New Game+ (or whatever the RealLive equivalent is), I'm guessing it was some weird fluke.

Since I work most of the time on Snow Leopard, I have also been playing on rlvm. I consistently get the secondary option there, even after nuking saves. I'm guessing it's a bug in rlvm.

So, after a moment of panic, the Leopard toolchain does seem to be holding up.

-XCN-

[GundamAce]

Hey, I just noticed your conversation. If you need an on-call translator, I'll volunteer to do it. Of course, I can't work with you as a full time translator due to my commitment to translating Never7, but I'm willing to work with you as a consultant of sorts if you want to.

[Polarem]

Ah sorry, that was a pretty vague description. From my experience in RealLive, the rap options get updated each time you dub Sunohara's tape, AND finish listening to him complain in class (no saving required). It worked for me when I returned to title screen when he said "You really know how to get on someone's nerve, don't you?!" (reading that again... should that be "nerves"?). Restarting before he finishes complaining does not trigger an update.

The first time round, the update enables the option to "say something fitting"; subsequent updates give you a different dumb rap when you choose "say something fitting" (I don't know what happens if you choose "Forget it, this is stupid", but it probably doesn't update).

I found a bug in my rlvm installation too: In my Jap version, when I restarted after I the "Mongolian chop" rap, Tomoya says "Forget it, this is stupid" no matter which option I choose :-S

The test would be to use block comments with no nested line comments, and see what happens.

Mine still threw an exception.

Shizuka's read of the problem is that rlc is not hooking in the necessary calls to rlBabel when parsing calls to select_s(). That's the Kepago function that generates multiple choice buttons in the middle of the screen, and I'm guessing it has a direct bytecode equivalent in RealLive (vs. being implemented in rlc using custom bytecode routines). The only ways to confirm this are to either step through the compiled bytecode to see what's being called (which implies knowing the bytecode calls involved in triggering rlBabel and/or select_s()), or to dig through the rlc source, and compare how ordinary text strings are processed, to strings passed to select_s(). Neither approach is trivial. There's a third possibility, which is that rlBabel IS being called, but the #SELBTN variables in GAMEEXE.INI aren't set properly (specifically the MOJI variables, which have caused problems in the past with normal text). This is unlikely, as there is zero documentation for those variables, and we don't know if rlc even processes them.

That sounds like a messy job alright... is it something you'd take up? I might start digging into the rlc code on Monday (it's probably good coding experience, although I have no idea how long it'll take). BTW, where did you find Shizuka's diagnosis?



Ok, I fixed 2 of the rlc compiler warnings, and unearthed a few more Japanese lines (see Wiki project page), which accounts for the rest of the warnings. I also started making use of the translation category. There was no warning for untranslated #character directives though, like the "Jet Man" in SEEN0422. "Jet Saito" seems to allude to some kind of in-joke, but none of the English discussions I read really knew what it's about...

Also found some translations for the graphical text! Here and here. The latter is by DGreater1 who did lots of work on the Wiki, so I'm inclined to use it.