Opened 7 years ago
Closed 8 months ago
#7073 closed defect (fixed)
KQ6-CD: Savegame that cannot be resumed
|Reported by:||SF/fiesh8192||Owned by:||sluicebox|
|Cc:||Game:||King's Quest 6|
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.
Change History (14)
by , 7 years ago
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Yes, that's precisely what happened to me.
comment:3 by , 7 years ago
|Component:||→ Engine: SCI|
|Game:||→ King's Quest 6|
comment:4 by , 7 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 , 7 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 , 7 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 , 7 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 , 7 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 , 7 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 , 3 years ago
Should be solved by https://github.com/scummvm/scummvm/pull/2146 (needs creating a new savegame, as the original doesn't contain
comment:11 by , 3 years ago
|Status:||new → closed|
Fixed in PR 2146, closing
comment:12 by , 18 months ago
|Status:||closed → new|
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 , 8 months ago
|Status:||new → closed|
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.
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?