Opened 17 years ago

Closed 17 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


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 17 years ago.
indy3.s02 (30.6 KB ) - added by SF/yokitori 17 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 by fingolfin, 17 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, 17 years ago

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

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

Attachment: indy3.s03 added

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

and there the second

by SF/yokitori, 17 years ago

Attachment: indy3.s02 added

comment:6 by SF/yokitori, 17 years ago

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

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

it also occurs in zak256

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

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

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

Segra, I appreciate your good will, but this is not so

* 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, 17 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
// 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, 17 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, 17 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, 17 years ago

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