Opened 9 years ago

Closed 2 years ago

#7073 closed defect (fixed)

KQ6-CD: Savegame that cannot be resumed

Reported by: SF/fiesh8192 Owned by: sluicebox
Priority: normal Component: Engine: SCI
Version: Keywords:
Cc: Game: King's Quest 6

Description

The attached savegame, taken right after Night Mare lands, does not allow resuming the game any more at all. (1.7.0)

Ticket imported from: bugs/7073.

Attachments (1)

kq6-cd.021 (42.4 KB ) - added by SF/fiesh8192 9 years ago.

Download all attachments as: .zip

Change History (14)

by SF/fiesh8192, 9 years ago

Attachment: kq6-cd.021 added

comment:1 by wjp, 9 years ago

I think I can reproduce this with master and the attached savegame. If I load it, things don't freeze, but the game never returns control to the user. (Or at least not within a few minutes.)

Did you get the same symptoms?

comment:2 by SF/fiesh8192, 9 years ago

Yes, that's precisely what happened to me.

comment:3 by m-kiewitz, 9 years ago

Component: Engine: SCI
Game: King's Quest 6

comment:4 by m-kiewitz, 9 years ago

Happens with ScummVM 1.7 as well. I wonder if this is actually a script bug and happens when saving at a specific point.

comment:5 by m-kiewitz, 9 years ago

It seems to happen when you arrive at the realm of the dead and then save after the first dialog "Night Mare deposits Alexander on a strange, cold world", but before the second dialog "And some of the inhabitants don't look too friendly".

When you restore from that save, the second dialog never happens and that's effectively what's indirectly causing the "freezing".

Looks to me like a script bug. Will check if it happens in the original interpreter (although that may get time consuming in case I don't find a proper saved game).

comment:6 by m-kiewitz, 9 years ago

Do you need that saved game to get fixed? Or do you have one right before it? I guess I could maybe fix it, but I won't bother in case it's not important to you.

comment:7 by m-kiewitz, 9 years ago

Seems to work in the original interpreter, although it may still be a script bug that simply does not trigger in the original interpreter.

comment:8 by m-kiewitz, 9 years ago

This actually seems to be a music related issue.

Music resource number 155 is playing. But when you save + restore after the first dialog, the music isn't playing anymore. This music track normally triggers the 2nd dialog box which doesn't because of the music not playing.

script involved -> script 600, method horseToon::changeState state 5 triggers a little timer and state 6 afterwards triggers the 2nd dialog box

comment:9 by SF/fiesh8192, 9 years ago

Thanks for the offer, I don't need the savegame fixed. I just reported it so it can be fixed in ScummVM!

comment:10 by ZvikaZ, 5 years ago

Should be solved by https://github.com/scummvm/scummvm/pull/2146 (needs creating a new savegame, as the original doesn't contain stopAfterFading)

comment:11 by bluegr, 5 years ago

Owner: set to ZvikaZ
Resolution: fixed
Status: newclosed

Fixed in PR 2146, closing

comment:12 by sluicebox, 3 years ago

Resolution: fixed
Status: closednew

This hasn't been fixed. I don't believe that PR 2146 had any relation to this.

Confirmed in CD and floppy with latest code and new save files.

comment:13 by sluicebox, 2 years ago

Owner: changed from ZvikaZ to sluicebox
Resolution: fixed
Status: newclosed

Fixed in: https://github.com/scummvm/scummvm/commit/6e5b1e31f0f9672cb979a7fa12d4bed35a4f6bf1

This bug was due to not including the MusicEntry::fadeCompleted flag in save files.

horseToon fades out sound 155 over 1.16 seconds and waits on the fade to complete in handsOff mode. Saving during this fade means going to the icon bar, bringing up the control panel, and then clicking save. That takes more than 1.16 seconds and so the fade would complete while the game's UI was displayed and the game was paused. At this point, ScummVM's fade timer has set MusicEntry::fadeCompleted to tell SoundCommand::processUpdateCues() to signal the Sound object. Cues aren't processed until the UI is closed and the game resumes. By not saving fadeCompleted, it was reset to false upon loading, and processUpdateCues() never learned that the fade had already completed before the save. The script was then stuck waiting to be cued.

Note: See TracTickets for help on using tickets.