Opened 18 years ago

Closed 18 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
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)

indy3.s03 (30.6 KB ) - added by SF/yokitori 18 years ago.
indy3.s02 (30.6 KB ) - added by SF/yokitori 18 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 by fingolfin, 18 years ago

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!

comment:2 by fingolfin, 18 years ago

Summary: indy3 can walk over the biblitek shelvesINDY3: Indy can walk over the shelves

comment:3 by SF/yokitori, 18 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 SF/yokitori, 18 years ago

Attachment: indy3.s03 added

comment:4 by SF/yokitori, 18 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...

comment:5 by SF/yokitori, 18 years ago

and there the second

by SF/yokitori, 18 years ago

Attachment: indy3.s02 added

comment:6 by SF/yokitori, 18 years ago

the bug stils there in the CVS from 25 november....

comment:7 by SF/muffingd, 18 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:8 by SF/segra, 18 years ago

it also occurs in zak256

comment:9 by eriktorbjorn, 18 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 fingolfin, 18 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 fingolfin, 18 years ago

I commented out the line Erik suggested. Let's see which regressions that causes :-)

comment:12 by SF/segra, 18 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 SF/segra, 18 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 fingolfin, 18 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 eriktorbjorn, 18 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 eriktorbjorn, 18 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 eriktorbjorn, 18 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 fingolfin, 18 years ago

Owner: set to eriktorbjorn
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.