#10530 closed defect (invalid)
SCUMM: Zak McKracken (FM-Towns) - Cutscene stack overflow after ending
Reported by: | d0k3 | Owned by: | AndywinXp |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | FM-Towns | |
Cc: | d0k3 | Game: | Zak McKracken |
Description
After finishing the game, the console pops up and I get:
ERROR: (25:139:0xB): Cutscene stack overflow
SCUMMVM v2.0.0 on Android
Zac McKracken (FM-TOWNS, english), with applied german translation from https://www.la-patches.de/patches.php
Assuming the problem happens with an unpatched Zac McKracken (FM-TOWNS), too. Will replay it in english. Maybe someone has an endgame save for that to do this quicker.
Attachments (1)
Change History (10)
comment:1 by , 6 years ago
Summary: | Cutscene stack overflow after Zac McKracken (FM-TOWNS) ending → ZAK: Cutscene stack overflow after (FM-TOWNS) ending |
---|
comment:2 by , 6 years ago
I am not able to reproduce a crash after the ending happens for the English FM-Towns version.
comment:3 by , 6 years ago
@dafioram, no I didn't. I don't have a english version save, and I played this version beginning to end.I guess the problem is for the german translation patch specifically then.
comment:4 by , 4 years ago
Keywords: | FM-Towns added |
---|---|
Summary: | ZAK: Cutscene stack overflow after (FM-TOWNS) ending → SCUMM: Zak McKracken (FM-Towns) - Cutscene stack overflow after ending |
comment:5 by , 4 years ago
This is not a bug in ScummVM, and also not in the original game/data. IMHO this bug can be closed.
comment:6 by , 2 years ago
I tried reproducing this by triggering the ending credits this way in the debugger:
room 25 script 139 run
but I couldn't reproduce the problem with the German patch.
I see that this fan translation added a \013
(or \x0D
) character at the end of every string inside the game. This is probably because they used scummtr to do the translation, with its -w
option for CRLF line returns during the initial export, but they probably forgot to use it during the import, causing the insertion of real \r
carriage returns inside the game strings.
I'm not sure the game is happy with this. Padded strings that should end with @@@
now end with @@@\013
. Internal sequences such as \255\004\175\000\255\002
now become \255\004\175\000\255\002\013
, which is unexpected. ScummVM prints this kind of warnings with this version, for example:
'!RNING: findVirtScreen(200) failed, therefore printChar cannot print '
I'm not sure the stack overflow came from there, but I think it's quite possible. I'm not aware of a similar problem with the original English version or with the French fan translations I know (but the German version also changed some other objects, such as as Zak's floor).
The strings inside the la-patches.de fan translation could maybe be fixed with something like this:
scummtr -g zaktowns -c -of tmp.txt perl -pi -e 's/\\013$//' tmp.txt scummtr -g zaktowns -c -if tmp.txt
but then all past saves for this version would be invalidated, I believe.
With no way to reproduce this at the moment, and knowing than this fan translation has a problem in its string format, I don't think ScummVM can do much about this...
comment:8 by , 6 months ago
Owner: | set to |
---|---|
Resolution: | → invalid |
Status: | new → closed |
comment:9 by , 2 months ago
Just for internal documentation... I'm told by gabberhead that there exists a fan-made German translation of the FM-TOWNS release of Indy3, also having some \013
bytes at the end of some strings, because of some scummtr misusage.
I don't think we can do much about this, fixing them on-the-fly wouldn't be worth it IMO. We could maybe add them to the detection tables and flag them as "buggy", in case people report subtle bugs with them... so far, this ticket is the only reported case.
I'm guessing you tried to load your save from an unpatched version and it did not work?