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 |
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)
Change History (14)
by , 20 years ago
comment:1 by , 20 years ago
| Summary: | No more input possible after activating crystal → DIG: No more input possible after activating crystal |
|---|
comment:3 by , 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 , 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 , 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 , 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 , 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.
comment:8 by , 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 , 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 , 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 , 19 years ago
| Owner: | set to |
|---|---|
| Resolution: | → outdated |
| Status: | new → closed |
save game