Opened 5 months ago

Closed 5 months ago

#13473 closed defect (fixed)

SCUMM: MANIAC: hanging cutscene when Purple Tentacle is bullying Sandy

Reported by: dwatteau Owned by: dwatteau
Priority: normal Component: Engine: SCUMM
Version: Keywords: cutscene, stuck
Cc: Game: Maniac Mansion

Description

This is with a 2.6.0git build from early May 2022.

In my gameplay, Dr Fred shut down the power and it's not back yet. A new cutscene started where Purple Tentacle is bullying Sandy, but for some reason, it just hangs once Dr Fred said "Bring her, the machine is ready. Heh, heh, heh."

Dr Fred should exit the room at that point, but he doesn't, and Sandy should scream "EEEEEEEEEK!!!!" but she doesn't, either. They just stop reacting, and the cutscene hangs until I press Esc.

The savegames below were made with my French DOS/V2 version of Maniac Mansion, but GOG has it if necessary.

Attachments (5)

maniac-v2-fr.s18 (6.0 KB ) - added by dwatteau 5 months ago.
Wait a few seconds, and the hanging cutscene should start
maniac-v2-fr.s19 (9.4 KB ) - added by dwatteau 5 months ago.
The cutscene before it hangs
maniac-v2-fr.s20 (9.5 KB ) - added by dwatteau 5 months ago.
The cutscene being stuck
maniac-v2-fr-dr-fred-stuck.png (6.7 KB ) - added by dwatteau 5 months ago.
Characters being stuck in the cutscene
SAVEGAME._H_ (7.0 KB ) - added by dwatteau 5 months ago.
V2 DOS savegame, French version ONLY

Download all attachments as: .zip

Change History (24)

by dwatteau, 5 months ago

Attachment: maniac-v2-fr.s18 added

Wait a few seconds, and the hanging cutscene should start

by dwatteau, 5 months ago

Attachment: maniac-v2-fr.s19 added

The cutscene before it hangs

by dwatteau, 5 months ago

Attachment: maniac-v2-fr.s20 added

The cutscene being stuck

comment:1 by athrxx, 5 months ago

Thanks for the report. I have managed to load the French savegame (first one) into my English MMv2.

The sequence plays fine...Tested multiple times.

Which platform are you on?
Is the issue reproducable every time?
And do you think that it is a regression?

When I try loading the third save it errors out:
(31:155:0x65): object 11545 is out of bounds (0,779)!

Now, I have also tried loading both savegames (first and third) into my German MMv2. And that works...even for the third one. But still no sign of any bug...

Can you tell if it is a regression? Or did that French version just never work?

comment:2 by athrxx, 5 months ago

Could you please add a screen shot of the "stuck" situation?

by dwatteau, 5 months ago

Characters being stuck in the cutscene

comment:3 by dwatteau, 5 months ago

@athrxx: Thanks, I've added a screenshot.

The platform is macOS. I'm using the Amiga render mode in order to avoid the sunburn effect, but going back to the default renderer doesn't fix the issue.

[maniac-v2-fr]
filtering=false
extra=V2
engineid=scumm
render_mode=amiga
platform=pc
vsync=true
aspect_ratio=false
guioptions=sndNoSpeech sndNoMIDI lang_French
fullscreen=false
description=Maniac Mansion (V2/DOS/French)
path=/path/to/MANIAC_V2_FR
gameid=maniac
language=fr

I haven't done a full play of Maniac Mansion V2 for a long time, so I can't say if it's a recent regression :( Other cutscenes were OK, as far as I can say.

I do have the bug every time I load my savegame, here. But as it happens, I was using a recent build so I can't load my savegame in an older ScummVM, and there are so many timers going on in Maniac Mansion, I'm not sure I could easily reproduce it from scratch again.

Here's what script 155 (room 1) does in this version:

...
[0064] (14) print(23,"Bas les pattes!");
[0074] (3B) waitForActor(13);
[0076] (1E) walkActorTo(13,21,50);
[007A] (3B) waitForActor(23);
[007C] (1E) walkActorTo(9,30,50);
[0080] (3B) waitForActor(9);
[0082] (11) animateActor(9,248);
[0085] (14) print(9,"TENTACULE MAUVE!!\x03Arr]te de tourmenter mes cobayes.\x03Am\\ne-la, la machine est pr]te.\x03Ha ha ha."); # <== gets stuck right after this
[00DA] (80) breakHere();
[00DB] (44) unless (VAR_CHARCOUNT > 90) goto 00DA;
[00E1] (1E) walkActorTo(9,60,50);
[00E5] (AE) waitForMessage();
[00E6] (11) animateActor(23,250);
[00E9] (14) print(23,"AAAAAAAA!!!!");
...

I don't know if the VAR_CHARCOUNT > 90 condition is where it gets stuck in this version?

comment:4 by dwatteau, 5 months ago

scumm_vars[7] in the debugger tells me that VAR_CHARCOUNT is strictly equal to 90 when the cutscene gets stuck.

Script 155 has the same unless (VAR_CHARCOUNT > 90) check in the English version, though…

comment:5 by dwatteau, 5 months ago

Yeah, if you run script 155 run in the V2 English version, the cutscene is OK. But it hangs with the French version, for some very strange reason.

I'll try reproducing this with an old ScummVM release.

comment:6 by dwatteau, 5 months ago

The cutscene of the French version hangs with ScummVM 1.4.0 (2011, Windows) too, so it's not a recent regression. Maybe an original script bug… but I don't really know what VAR_CHARCOUNT represents in SCUMM.

I still have the original EXEs from my DOTT CDs, so I'll see if it hangs in DOSBox too.

comment:7 by athrxx, 5 months ago

Thanks for all the extra info.

If this were an original bug, that would mean that noone ever got through the French version (without pressing Esc). So I suspect it is something with our code...

comment:8 by athrxx, 5 months ago

In English there is always a \xff before the \x03, right?

comment:9 by athrxx, 5 months ago

I can reproduce the issue by hacking in that French string. I think it's the weird control codes without the \xff. The English version and the German version use \xff\x03.

Oh well, I guess I'll check how the original interpreter deals with the \x03.

comment:10 by dwatteau, 5 months ago

It looks like it is an original bug; you can see the French version hang here too on Atari without ScummVM:

https://www.youtube.com/watch?v=MwKuK8RI5X0&t=5194s

I personally use the Esc key a lot when some scenes are a bit too slow for me, so I guess that this time patience rewarded me with an original bug :)

As for the English script:

...
[0061] (14) print(23,"Don't touch me!");
[0071] (3B) waitForActor(13);
[0073] (1E) walkActorTo(13,21,50);
[0077] (3B) waitForActor(23);
[0079] (1E) walkActorTo(9,30,50);
[007D] (3B) waitForActor(9);
[007F] (11) animateActor(9,248);
[0082] (14) print(9,"PURPLE TENTACLE!!\x03Stop playing with the lab experiments.\x03Bring her, the machine is ready.\x03Heh, heh, heh.");
[00E0] (80) breakHere();
[00E1] (44) unless (VAR_CHARCOUNT > 90) goto 00E0;
[00E7] (1E) walkActorTo(9,60,50);
[00EB] (AE) waitForMessage();
[00EC] (11) animateActor(23,250);
[00EF] (14) print(23,"EEEEEEEEEK!!!!");
...

The \xff "prefix" appeared in V3, if my memory serves me right.

comment:11 by athrxx, 5 months ago

Okay, I see. The script actually does have the \xff prefix for English and German. So apparently that script displayer of yours just suppresses that.

But it doesn't help with that sentence, anyway. I have hacked it in and it will still freeze.

I'll check why it does that...

comment:12 by athrxx, 5 months ago

It does freeze at the < 90 check :-(

comment:13 by dwatteau, 5 months ago

Hm I'm just using ScummVM's descumm -2 and scummvm --dump-scripts. Looking in a hex editor, I can't see any FF byte before 03.

Anyway, I wonder if this isn't related to the length of the string? As it happens, the French translation is shorter than the original English line (which is quite unusual in French), so in case VAR_CHARCOUNT is about the number of chars in a string (I don't know), then the 90 threshold is maybe too high for the shorter French sentence? Padding with @@@@@ may help.

comment:14 by athrxx, 5 months ago

You're right. I didn't look closely, before, but we do insert the 0xFF ourselves in script_v2.cpp, lines 379 - 384. And I hacked in the French string after that, so I didn't notice/care.

Yes, it is definitely var 7 (VAR_CHARCOUNT). I also don't know yet, if the original handles that different than we do. We do increase it for each character we process (string.cpp, line 872). But if the original gets a different result just by 1 less, then the check would pass...

comment:15 by dwatteau, 5 months ago

Since it hangs with the original Atari ST interpreter in the video above too, I think ScummVM probably behaves like the original, and that the translation team just forgot to adjust some (all?) unless (VAR_CHARCOUNT ...) checks, especially when the translated string was shorter than the English one.

I could make a PR which pads this particular string a bit when it's too short?

comment:16 by athrxx, 5 months ago

What we don't see from that video is whether it somehow times out or whether the guy has to press Esc.

But you can just add a workaround. Translate the "Ha ha ha" back to "Heh, heh, heh."...
Just kidding, just add a space at the end or whatever works...

Maybe hack it into ScummEngine_v2::decodeParseString()...

comment:17 by dwatteau, 5 months ago

What we don't see from that video is whether it somehow times out or whether the guy has to press Esc.

Ah yes, indeed. I'll try reproducing this in DOSBox, but it's a bit long to get there, and I can't get the debug shortcut to do anything with my French version.

Maybe hack it into ScummEngine_v2::decodeParseString()...

Thanks! I've put up a PR here:
https://github.com/scummvm/scummvm/pull/3887

by dwatteau, 5 months ago

Attachment: SAVEGAME._H_ added

V2 DOS savegame, French version ONLY

comment:18 by dwatteau, 5 months ago

For reference, I confirm that the French version (and precisely this one) has the same bug when using DOSBox. If you load the savegame above (slot H) and wait a bit, the cutscene will start and hang once Dr Fred is done talking.

I see no timeout: it indefinitely hangs, so ScummVM looks correct when it does the same by default.

(Note: earlier I said that GOG had the French version, but I was wrong, unfortunately they don't. The old DOTT CDs do have the French version of Maniac Mansion though, as long as you rename MANIAC.OVL to MANIAC.EXE, and put your savegames inside a DOTT.CD\ directory.)

comment:19 by bluegr, 5 months ago

Owner: set to dwatteau
Resolution: fixed
Status: newclosed

The PR has been merged, so this can be closed now. Thanks dwatteau for your work!

Note: See TracTickets for help on using tickets.