Opened 22 years ago
Closed 22 years ago
#589 closed defect (fixed)
INDY3: Indy can walk over the shelves
Reported by: | SF/yokitori | Owned by: | eriktorbjorn |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | Indiana Jones 3 |
Description
well when you do a "walk to the books" then in some cases indy just walk as if there was no shelf there and his sprites go over the shelf...
Ticket imported from: #643001. Ticket imported from: bugs/589.
Attachments (2)
Change History (20)
comment:1 by , 22 years ago
comment:2 by , 22 years ago
Summary: | indy3 can walk over the biblitek shelves → INDY3: Indy can walk over the shelves |
---|
comment:3 by , 22 years ago
scummvm version : 0.2.82 built from 23 November bug : in the bibliothek (Venise) when performing the action "walk to the books" several times ersion of the Game Indy 3 256, floppy, english platform : Win32
by , 22 years ago
comment:4 by , 22 years ago
there is two states connected with the bug the first is when the bug occured, and the second is just before : indy just keep trying to walk to the shelf and then when you click over his head you should be able to get the byg...
by , 22 years ago
comment:7 by , 22 years ago
It's easier to just click anywhere on the shelf between the books. You can walk him right up the screen. I recall it happens in a few other rooms too, but I can't recall exactly which ones.
comment:9 by , 22 years ago
This appears to be because adjustXYToBeInBox() does (almost) nothing if it's a GF_OLD256 game (i.e. Indy3 or Zak256) and the room has only one walkbox. The function specifically checks for this case, which makes absolutely no sense to me. If I remove the line
if (!(_vm->_features & GF_OLD256) || box)
I can no longer reproduce this bug. But apparently this isn't the correct fix, because this is what the CVS log says for when the line was changed to its current form:
"readded the check I removed yesterday, but in a changed form. Indy3 now works correctly again, and MonkeyVGA still is fixed. Somebody care to check loomcd?"
(See scummvm-old, revision 1.103 of actor.cpp)
Fingolfin, could you elaborate on that?
comment:10 by , 22 years ago
Segra, if you told us *where* in Zak256 it occurs and doing what, that would be much more helpufl.
Erik (or should I say Torbjrn?), I am not so sure why that check is in. I originally removed it, but IIRC it caused some regression. Probably best if we uncomment it, then see what happens (i.e. if/where it causes regressions).
comment:11 by , 22 years ago
I commented out the line Erik suggested. Let's see which regressions that causes :-)
comment:12 by , 22 years ago
Sorry about that, I did make a post of this in the Testing for 0.3.0 thread, guess no-one saw it ;) this is my post...
-airport doors open early, then close before you go out them -After getting a crystal, the room goes black (Good) but after going into the next room (such as cave) the colour goes bad until the next room. and when you go back into rooms which should be black, there colour is returned. -Room34, room with map of ancient earth, you can walk anywhere if u click above the lion -Room152, if you press the buttons in the wrong order, you fall and the game crashs
Error(15:202:0xDC36): Script 202 stopped with active cutscene/override in exit!
comment:13 by , 22 years ago
Forgot to mention, this was a CVS from a couple of weeks back. Don't have an exact date... sorry
comment:14 by , 22 years ago
Segra, I appreciate your good will, but this is not so helpful...
* first off, of course we don't notice it on the forum - that's for discussion, and the developers (that includes me) often don't get to reading them at all. That's why we have a bug reporter
* report each bug seperatly
* do NOT report one bug as a comment on another bug. That makes it impossible for us to track the bug
* always try to verify the bug with the latest available version of ScummVM, and when you make the bug report, include the version of ScummVM
In particular: there is already a bug report for the airport doors. The color bug should be fixed. The other bugs I don't know about, but again, a seperate bug report with more detailed information (and ideally a save game) will allow us to work on fixing the bug, but if we don't have that it's not likely anything will be done about them.
Thanks for your efforts!
comment:15 by , 22 years ago
> Let's see which regressions that causes :-)
I've found one already: The little trains in the intro no longer move across the LucasFilm logotype as they should. Tells you something about the quality of my regression testing, huh? :-)
But I don't think reverting the patch is the right way to deal with this one. True, the walkbox in this case is clearly not meant to be taken seriously, but that still doesn't mean we should ignore walkboxes in all rooms that happen to have only one.
My first thought was to remove adjustActorPos() from putActor(), but at the very least that would cause a masking bug when Largo dangles Guybrush over the side of the bridge in MI2. That alone is rason enough for me not to like this solution, so here's another thought:
Both train actors are given class 22 (ignore boxes) by the script, but there's a hack putClass() that transforms this into class 21 (always clip) for this particular case. Removing the hack makes the trains move correctly but introduces a masking bug, so how about changing it to something like this instead:
// FIXME: In the Indy3 intro, it isn't enough that the little trains // have class 22 (ignore boxes), they also need class 21 (always // clip) to avoid masking errors. if (_gameId == GID_INDY3_256 && cls == 22 && _currentRoom == 76) putClass(obj, 21, set);
I like this solution much better because at the very least it doesn't introduce any *new* hacks.
comment:16 by , 22 years ago
I've submitted my suggested patch to the patch tracker. It works for me, but I haven't gotten far enough into Indy3 - I'm still at the library - to see if the experimental fix has caused any other regressions.
comment:17 by , 22 years ago
Has anyone noticed any regressions apart from the Indy 3 intro (which should be fixed - or at least hacked around - now), or can this bug be closed?
comment:18 by , 22 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
To process your bug report appropriately, we need you to provide the following additional information:
* ScummVM version (scummvm -v) * Bug details, including instructions on reproducing it * Language of game (English, German, etc) * Version of game (Talkie, Floppy...) * Platform and Compiler (Win32, Linux, MacOS, etc) * Attach a save game if possible * If this bug only occurred recently, please note the last version without the bug, and the first version including the bug. That way we can fix it quicker by looking at the changes made.
This should only take you a little time but will make it much easier for us to process your bug report in a way that satisfies both you and us.
Thank you for your support!