Opened 15 years ago

Closed 15 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
Keywords: Cc:
Game: The Dig

Description

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 15 years ago.
save game
dig.s12 (27.3 KB ) - added by eriktorbjorn 15 years ago.
Newer save game

Download all attachments as: .zip

Change History (14)

by SF/bhebing, 15 years ago

Attachment: dig.s10 added

save game

comment:1 by Kirben, 15 years ago

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

comment:2 by Kirben, 15 years ago

Can use ESC to continue game in meantime.

comment:3 by eriktorbjorn, 15 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, 15 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, 15 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-, 15 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, 15 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, 15 years ago

Attachment: dig.s12 added

Newer save game

comment:8 by eriktorbjorn, 15 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, 15 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-, 15 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, 15 years ago

Owner: set to eriktorbjorn
Resolution: outdated
Status: newclosed

comment:12 by eriktorbjorn, 15 years ago

I'm closing it then.

Note: See TracTickets for help on using tickets.