Opened 8 years ago

Last modified 11 months ago

#5624 new defect

ZAKTOWNS: Opening hostel door (Mars) corrupts cutscene index

Reported by: SF/juhaerk Owned by: Kirben
Priority: normal Component: Engine: SCUMM
Keywords: script Cc: raziel_nosgoth@…
Game: Zak McKracken

Description

If either Leslie or Melissa closes hoster door on Mars from the outside, and then opens it again, vm.cutSceneStackPointer underflows from 0 to 255. Later on in the game, yellow crystal cannot be used due to assertion error on vm.cutSceneStackPointer value (it should be between 0 and 4).

I'm using the FM-TOWNS version of Zak McKracken. ScummVM is built from a source snapshot from date 2011-03-29, on OpenBSD.

Attached is a savegame that triggers the bug. Another attachment is a patch that turns the bug into an immediate crash.

Ticket imported from: #3267665. Ticket imported from: bugs/5624.

Attachments (2)

zak-fm.s23 (13.9 KB) - added by SF/juhaerk 8 years ago.
Zak savegame
patch-engines_scumm_script_cpp (386 bytes) - added by SF/juhaerk 8 years ago.
A patch to trigger an immediate crash when opening hostel door

Download all attachments as: .zip

Change History (14)

Changed 8 years ago by SF/juhaerk

Attachment: zak-fm.s23 added

Zak savegame

Changed 8 years ago by SF/juhaerk

A patch to trigger an immediate crash when opening hostel door

comment:1 Changed 8 years ago by bluegr

That's odd

This is an old bug, specifically 1668393:
https://sourceforge.net/tracker/?func=detail&aid=1668393&group_id=37116&atid=418820

That's a script bug, and theoretically it should already be fixed with a workaround

comment:2 Changed 8 years ago by bluegr

Assigning this to kirben, since he originally fixed this one

comment:3 Changed 8 years ago by bluegr

Keywords: script added
Owner: set to Kirben

comment:4 Changed 8 years ago by fingolfin

Checking for cutSceneStackPointer underflows (as in your patch) is a good idea, I just committed a similar change for that.

comment:5 Changed 8 years ago by fingolfin

I looked at the script room-27-205 in question, and also at tracker item #1668393, and also at Kirben's fix from SVN rev 42590 (git commit 1d40f784) is quite nailing it.

Then I took the relevant script, and compared it to the equivalent script roomobj-27-450 from Zak v2. Consider this from the "old" script:

[0026] (47) clearState08(472);
[0029] (0F) if (!getState08(463)) {
[002E] (0F) if (!getState08(465)) {
[0033] (60) cursorCommand(15, 2);
[0036] (1A) Var[47] = 3;
...
[0052] (07) setState08(465);
...
[0061] (1C) startSound(25);
[0063] (07) setState08(463);
[0066] (07) setState08(449);
[0069] (2E) delay(60);
[006D] (60) cursorCommand(247, 1);
[0070] (18) } else {
[0073] (18) goto 0061;
[0076] (**) }

with this from the new (FM-TOWNS) script:

[0010] (07) setState(472,0);
[0014] (0F) if (getState(463) == 0) {
[001A] (1D) if (classOfIs(465,[0])) {
[0023] (40) cutscene([2]);
...
[0057] (5D) setClass(465,[1]);
...
[006C] (1C) startSound(23);
[006E] (07) setState(463,1);
[0072] (07) setState(449,1);
[0076] (2E) delay(60);
[007A] (C0) endCutscene();
[007B] (18) } else {
[007E] (18) goto 006C;
[0081] (**) }

First off, it becomes clear where the crash originates: the "if() {}" block contains a begin/end cutscene pair (resp. the equivalent cursorCommand in SCUMM v2). The else block jumps into the middle of the "if" block, and so the endCutscene is hit without beginCutscene being triggered.

Now, if you look closely, it seems that they have translated some setState08(N) calls into setState(N, 1) ; but at least the one for N=465, they converted into a setClass(N,[1]) call. And "!getState08(465)" became classOfIs(465,[0])

Kirben correctly guessed that the first "classOfIs" was a mistranslation. Correct; but so are several of the later setClass calls.

So, I made the attached patch which adds a workaround to the setClass opcode.

The only problem is that this does not solve the issue at hand, because setClass is never called -- it turns out that in the given save state, the state of object 465 (the inner door) has already been set to 1! Maybe this means the savestate is inconsistent (possibly due to the incomplete older workaround), or maybe something else is going on that I am missing... This needs to be investigated some more!

comment:6 Changed 8 years ago by fingolfin

I actually just pushed my setClass workaround, instead of attaching here (Kirben, or anybody else, please review).

Since 465 seems to be the inside door (according to Kirben's workaround comment), I wonder if 463 is the outside door?

A simple workaround to the crash here would be to ignore the endCutscene call in room-27-205 if no cutscene is active. However, I'd prefer to only do this if we can confirm that the setClass changes really fix the underlying issue.

comment:7 Changed 8 years ago by bluegr

Summary: Opening hostel door on Mars corrupts cutscene indexZAKTOWNS: Opening hostel door (Mars) corrupts cutscene index

comment:8 Changed 8 years ago by bluegr

Updated description

comment:9 Changed 6 years ago by SF/dronkit

Sorry guys that I don't understand most of what you say here, but you talk like a workaround has been added to scummvm 2 years ago.

But I'm having the exact same bug on versions 1.6.0 (jul 9 2013 11:25:59) win32, 1.7.0git1551-ge63b722 (Aug 22 2013 04:28:55) win64, both under windows 7 x64, and in 1.6.0-raring.1_amd64 (under Ubuntu Raring).

Or hasn't the workaround been added? Can I workaround this error by hand? thanks!

comment:10 Changed 6 years ago by raziel-

ScummVM 1.7.0git (Aug 23 2013 07:45:42)
Features compiled in: Vorbis FLAC MP3 RGB zLib MPEG2 Theora AAC FreeType2

This error can still be triggered with todays git build and the attached savegame.

comment:11 Changed 6 years ago by SF/dronkit

OK guys, I managed to win the game (cheating) by using the console to enter the hostel and retrieve the fuse. Then I knew it wasn't necessary. Whatever.
The thing is I found out some stuff that might help you debug the script or whatever:

in room 185 (landing site), object 452 is the door to the hostel (the outside of it)
in room 181 (hostel airlock) and/or room 180 (hostel), object 463 is the airlock exit door ("door to mars"), ie, object 452's inner part. Object 472 in room 180/181 is the door from airlock to hostel. Another object referred to in the script is one of the lights. So the script piece fingolfin shows must have to do with the inner door automatically closing when you open the outer door or something like that.

I see that in my save game that triggers the bug, the door looks closed from outside, also looks closed from inside when I cheat-enter the arlock. But the state of object 463 is 0 and the state of object 452 is 1. In theory the states should be the same cause they are the outer and inner counterparts of the same door (?).

To find out what object is what I play the game, go to debug console with CTRL+D and use "objects" for a list and "object (number) name" to find out what it is. Also "object (number) state" to see it state and "object (number) state (number)" to change it

comment:12 Changed 11 months ago by raziel-

Cc: raziel_nosgoth@… added
Note: See TracTickets for help on using tickets.