#1249 closed defect (invalid)
INDY3: Lake still flooded after removing plug in catacombs
| Reported by: | SF/cloney | Owned by: | eriktorbjorn |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | script | |
| Cc: | Game: | Indiana Jones 3 |
Description
I'm using ScummVM 0.5.3cvs (Sep 26 2003 10:12:25) on Win32, with the PC floppy version of Indy and the Last Crusade (english).
In the catacombs, I've attached the hook to the plug and used the whip to pull the plug out; however, the room on the floor above that this is supposed to drain remains full, with the plug sitting in the bottom.
This problem wasn't present in one of the previous post-0.5.1 CVS builds, as I played as far as Castle Brunwald.
Attached is a save game in the carving room, next to the underside of the plug. To reproduce the bug, just stick the hook in the plug, whip it, then go to the lake room.
Cloney
Ticket imported from: #813136. Ticket imported from: bugs/1249.
Attachments (1)
Change History (12)
by , 21 years ago
comment:1 by , 21 years ago
| Summary: | Lake still flooded after removing plug in catacombs → INDY3: Lake still flooded after removing plug in catacombs |
|---|
comment:2 by , 21 years ago
I can reproduce this. After that, when I go back to the plug room and then again back to the lake room, the water is gone as supposed to be.
comment:3 by , 21 years ago
I can't reproduce this with today's CVS snapshot.
(I noticed there's a commit message from Fingolfin saying "fix for bug #813136", so I don't know why it's still open. Unless, of course, he mistyped...)
comment:4 by , 21 years ago
Actually, it turns out I *can* reproduce the problem, but only if I walk back to the water-filled room as fast as I can.
If I wait for a while, leave the water-filled room and then re-enter, the water has drained, but I guess it never happens while you're watching.
comment:5 by , 21 years ago
Hm, odd. Does this mean some script runs "too late/too slow" ?!? But that would seem extremly unlike... Guess we'll have to figure out which script is handling the plug removal, and which the "draining", and then we can try to figure out what's going on... maybe I can get to that later today, but I am sure erik can artfully handle this as well if he has the time/interest :-)
comment:6 by , 21 years ago
This is one of the scripts that are executed when you pull the plug:
Script-51:
[0000] (1A) Var[118] = 1; [0005] (2E) delay(900) [0009] (08) unless (VAR_ROOM != 61) goto 0005; [0010] (1A) Var[118] = 2; [0015] (A0) stopObjectCode()
From experimenting with the debugger, I know that:
Room 61 is the room with the plug. When Var[118] = 1 the water is draining When Var[118] = 2 the water has drained completely.
The value of Var[118] is probably tested only when you enter the room, but I haven't verified that.
So the water won't drain until at least 900 units of time (however long that may be) have passed, and you have left room 61. If you reach the other room before the time has passed, the water won't have drained yet.
Looks like the behaviour is intentional to me.
comment:7 by , 21 years ago
I did some testing that seems to confirm my theory. I'm still not sure how long delay(900) is meant to last - maybe it depends on what you are doing at the time - but we're talking about 10-20 seconds at least. I can easily reach the other room before running out of time, and then it is indeed still flooded.
So while I think it's a pretty dumb script, I still think it's a feature. If whoever wrote it hadn't meant for something like this to happen, he wouldn't have used delay() at all. He could just have decided to drain the other room immediately and turn off the animation of the flowing water as soon as the player leaves the first room.
Does that mean we can close this bug report now, or does anyone feel differently?
comment:8 by , 21 years ago
| Status: | new → closed |
|---|
comment:9 by , 21 years ago
| Resolution: | → invalid |
|---|
comment:10 by , 21 years ago
| Owner: | set to |
|---|
comment:11 by , 21 years ago
Yeah I didn't look properly, the unit is 15ms, so 900*15ms = 13500ms = 13.5 seconds.
"It's not a bug, it's a feature!"
Save just before bug