search

eglaysher / rlvm

RealLive clone for Linux and OSX
http://rlvm.net
GNU General Public License v3.0
150 stars 25 forks source link

The Fuwanovel Clannad patch doesn't work #56

Closed eglaysher closed 9 years ago

eglaysher commented 10 years ago

The reports from people complaining about the game locking up on the first voice call of the game all seem to be running the Fuwanovel patch.

(SEEN9600)(Line 30)[koePlay]: No such voice archive or sample
(SEEN9600)(Line 33)[strsub]: Error in strsub: offset is greater then string length
(SEEN9600)(Line 79)[strsub]: Error in strsub: offset is greater then string length
(SEEN9600)(Line 82)[strsub]: Error in strsub: offset is greater then string length
eglaysher commented 10 years ago

After investigating this some more...

We're getting stuck in this endless loop because on line 32 of SEEN9600 in Fuwanovel's patch, there isn't a ret_with(). In the unpatched Japanese version, the Doki patch, and I assume the Assembla patch (though I haven't checked that last one), there's a ret_with() immediately after the koePlay(). This would explain the behaviour where we hear Nagisa sigh, and then the interpreter starts executing the next gosub block (which inconveniently forms a nested loop).

I am unsure if this is the patch's fault or is rlvm not parsing things correctly. (The obvious question is, if the problem is with the patch, then why does it work in the official interpreter?)

eglaysher commented 10 years ago

I instrumented rlvm's loading to get a raw bytecode dump. Here's an excerpt.

00000180: 0000 5d0a 1e00 2301 1700 0002 0001 2824  ..]...#.......($
00000190: 0b5b 24ff 0a00 0000 5d24 0b5b 24ff 0b00  .[$.....]$.[$...
000001a0: 0000 5d29 0a20 000a 2100 2301 0a05 0004  ..]). ..!.#.....
000001b0: 0001 2824 0a5b 24ff 0100 0000 5d24 0a5b  ..($.[$.....]$.[
000001c0: 24ff 0000 0000 5d24 ff01 0000 0024 ff01  $.....]$.....$..
000001d0: 0000 0029 0a22 0023 010a 0400 0200 0028  ...).".#.......(

That corresponds with this block of code:

#line 30
koePlay(intL[10], intL[11])
#line 32
#line 33
strsub(strK[1], strK[0], 1, 1)
#line 34

0a 1e00 is the "#line 30" on the first line of the dump. Note that the line markers "0a 2000" and "0a 2100" are right next to each other, suggesting that rlvm is interpreting the code correctly and that this is just a problem with the patch. (0x20 is integer 32 and 0x21 is integer 33.) So it looks like the patch is just broken.

(But again, if that were true, why does it work in the official interpreter?)

AlicesReflexion commented 10 years ago

(But again, if that were true, why does it work in the official interpreter?)

IIRC, it doesn't.

eglaysher commented 10 years ago

In that case, this isn't an rlvm bug, and I'll close this. And given that Sekai just bought the rights to Clannad...

ghost commented 9 years ago

Sorry about re-opening an old issue, but this issue seems to be with the rlvm interpreter. I am using the unofficial English patch for clannad and can confirm that it works in Windows (running the official REALLIVE.EXE interpreter) but not in Linux running rlvm. Is it that the patch relies on a bug in the official interpreter, or are you looking at it the wrong way? (I'm sorry I am of little help when it comes to reading the bytecode as I am completely unfamiliar with it.)

Of course, if rlvm devs are completely done looking into it. I could attempt to fix it myself. If that's the case it'd be nice if anyone could refer me to any documentation as a starting point. The simplest workaround I can think of right now is to replace that whole section with no-ops (whatever serves as a no-op in reallive bytecode) and just skip it entirely (and of course hope that this issue does not re-appear.) This is of course a "fix" unrelated to rlvm.

Thanks beforehand.

AlicesReflexion commented 9 years ago

Seeing as Clannad is getting an official translation in the near future, I don't think there's really much need to support the fan patch anymore.

eglaysher commented 9 years ago

... replace that whole section with no-ops (whatever serves as a no-op in reallive bytecode) and just skip it entirely (and of course hope that this issue does not re-appear.)

Such a workaround wouldn't be accepted; Clannad is licensed, and I don't want to add any patch specific workarounds in general.

Now, if you figure out the difference in behaviors between rlvm and the official interpreter, that's a different matter. One possibility that comes to mind is that maybe the reason the call stack has a maximum size, and on stack overflow, gosubs just fail. Testing that though would require having rldev installed, making a test case against the official interpreter to verify that that's whats going on though.

As a quick sanity check before you do that, you could see if refusing to gosub after some big number of stack frames fixes things (2048 is probably safe). You might also need to make sure that the instruction pointer gets implemented; I'm fuzzy as to whether this case would need manual instruction pointer advancement.

stack manipulation: https://github.com/eglaysher/rlvm/blob/master/src/machine/rlmachine.cc#L403 gosub opcode: https://github.com/eglaysher/rlvm/blob/master/src/modules/module_jmp.cc#L231

If you then want to make a test case, your best bet is rldev. This is documented here: http://dev.haeleth.net/rldev/manual.html