Opened 6 years ago

Closed 6 months ago

Last modified 2 months ago

#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)

zak-fm.s21 (20.0 KB ) - added by dafioram 6 years ago.
English FM Towns Ending

Download all attachments as: .zip

Change History (10)

comment:1 by dafioram, 6 years ago

Summary: Cutscene stack overflow after Zac McKracken (FM-TOWNS) endingZAK: Cutscene stack overflow after (FM-TOWNS) ending

I'm guessing you tried to load your save from an unpatched version and it did not work?

by dafioram, 6 years ago

Attachment: zak-fm.s21 added

English FM Towns Ending

comment:2 by dafioram, 6 years ago

I am not able to reproduce a crash after the ending happens for the English FM-Towns version.

comment:3 by d0k3, 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 raziel-, 4 years ago

Keywords: FM-Towns added
Summary: ZAK: Cutscene stack overflow after (FM-TOWNS) endingSCUMM: Zak McKracken (FM-Towns) - Cutscene stack overflow after ending

comment:5 by BenCastricum, 4 years ago

This is not a bug in ScummVM, and also not in the original game/data. IMHO this bug can be closed.

Last edited 4 years ago by BenCastricum (previous) (diff)

comment:6 by dwatteau, 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:7 by AndywinXp, 12 months ago

So I guess this can be closed?

comment:8 by AndywinXp, 6 months ago

Owner: set to AndywinXp
Resolution: invalid
Status: newclosed

comment:9 by dwatteau, 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.

Note: See TracTickets for help on using tickets.