Opened 20 years ago

Closed 19 years ago

#1799 closed defect (outdated)

DIG: No more input possible after activating crystal

Reported by: SF/bhebing Owned by: eriktorbjorn
Priority: normal Component: Engine: SCUMM
Version: Keywords:
Cc: Game: The Dig


Scummvm: ScummVM 0.7.0CVS (Oct 3 2004 11:37:05) Features compiled in: Vorbis FLAC MP3 ALSA zLib MPEG2

The cross-hair input mark disappears when I return to the room right after activating the lifeless crystal.

I can still save games but I can no longer provide input to Boston.

Ticket imported from: #1039340. Ticket imported from: bugs/1799.

Attachments (2)

dig.s10 (32.3 KB ) - added by SF/bhebing 20 years ago.
save game
dig.s12 (27.3 KB ) - added by eriktorbjorn 20 years ago.
Newer save game

Download all attachments as: .zip

Change History (14)

by SF/bhebing, 20 years ago

Attachment: dig.s10 added

save game

comment:1 by Kirben, 20 years ago

Summary: No more input possible after activating crystalDIG: No more input possible after activating crystal

comment:2 by Kirben, 20 years ago

Can use ESC to continue game in meantime.

comment:3 by eriktorbjorn, 20 years ago

It looks to me as if room-26-2004 is waiting for script-32 to finish, which in turn is stuck on o6_wait(), case 226 (SO_WAIT_FOR_ANIMATION).

From what I remember, that particular opcode has been a source of trouble before. Supposedly it waits for an animation to finish, but the way it's implemented it actually waits for the actor to no longer having to be redrawn. Which, in my opinion, isn't *quite* the same though, even if the original interpreter presumably did it that way as well.

comment:4 by eriktorbjorn, 20 years ago

I tried the same savegame with 0.6.1b, and the same thing happened there. So if it's a regression, it's not a recent one.

comment:5 by eriktorbjorn, 20 years ago

It looks like it's Actor::animateCostume() that keeps setting the needRedraw flag. In other words, akos_increaseAnims() returns true. I don't know enough about this code to do any further debugging. Not now, anyway.

(Didn't we have a bug like this once that could be repeated with the old savegame, but which didn't happen at all when playing from the beginning with a newer version of ScummVM? Or did I just dream that?)

comment:6 by sev-, 20 years ago

Yes, we had that for FT INSANE and even for FOTAQ. That was because early bug in ScummVM lead to internal state inconsistency. Later, when it was fixed, there was no way to fix previously saved bad states.

comment:7 by eriktorbjorn, 20 years ago

I'll see if I can play up to that spot with a recent CVS snapshot, then. I don't remember how far you have to play to get to this particular scene, but I have a savegame from just a few days ago that I could continue with.

by eriktorbjorn, 20 years ago

Attachment: dig.s12 added

Newer save game

comment:8 by eriktorbjorn, 20 years ago

I've attached a savegame made by playing the game from the beginning with a more recent version of ScummVM. With this one, the bug does not happen.

comment:9 by eriktorbjorn, 19 years ago

So what is the consensus on this one? Can it be closed as out of date, even though older savegames may still be broken?

comment:10 by sev-, 19 years ago

In my opinion this is definitelay a wrong engine state bug which was in the past. It may be possible to fix it like those recent BASS bugs, but either it really worth it? It is fixed now, and maybe window when this bug did appear was so small that this is only savegame in the world with such wrong engine state.

comment:11 by eriktorbjorn, 19 years ago

Owner: set to eriktorbjorn
Resolution: outdated
Status: newclosed

comment:12 by eriktorbjorn, 19 years ago

I'm closing it then.

Note: See TracTickets for help on using tickets.