Opened 17 years ago

Closed 16 years ago

Last modified 16 years ago

#564 closed defect (fixed)

INDY3: Henry causes the game to restart

Reported by: SF/andrej4000 Owned by: eriktorbjorn
Priority: normal Component: Engine: SCUMM
Keywords: script Cc:
Game: Indiana Jones 3

Description

If you give something to Henry, while he isn't free, this
causes the game to restart...

And you said restart isn't implemented... :p

However this seems to be a script bug, because room
76 is loaded (the intro with train)

Ticket imported from: #636578. Ticket imported from: bugs/564.

Attachments (1)

indy3.s01 (31.9 KB) - added by SF/andrej4000 17 years ago.
Just geve something to Henry…

Download all attachments as: .zip

Change History (19)

Changed 17 years ago by SF/andrej4000

Attachment: indy3.s01 added

Just geve something to Henry...

comment:1 Changed 17 years ago by SF/ender

This bug is just really ODD. :)

Can anyone see if this happens in the original? (you may need to
try a few objects a few times until he accepts one)

comment:2 Changed 17 years ago by SF/ender

If nobody is willing to verify this bugs existence in the original, I'm
probably just going to close it...

comment:3 Changed 17 years ago by SF/andrej4000

It doesn't happen with the original interpreter. Henry just
refuses the items.

Perhaps a wrong script is loaded in ScummVM?

comment:4 Changed 17 years ago by fingolfin

Or maybe we simply have a bug/hole in our interpreter code...

comment:5 Changed 17 years ago by fingolfin

Loading that savegame, I got:

WARNING: Unknown o5_resourceRoutines: 44!
Fatal signal: Bus Error (SDL Parachute Deployed)

So I reverted the check in o5_resourceRoutines to be for
Zak256 instead of all OLD256 games. Now I only got the bus
error upon loading :-) Then I inserted some warnings() into
script_v1.cpp (at the place it crashed and some more), now
it gives

WARNING: Invalide actor 0 in o5_getActorElevation!

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0002ce18 in Actor::startWalkActor(int, int, int)
(this=0x0, destX=0, destY=0, dir=270) at scumm/actor.cpp:1157

As you can see, this=0. What is happening here is that for
some reasons, actor 0 is accessed over and over, but this is
invalid. Not sure what that means, many possibilities:
* the save game is corrupt (it's not unusal for such bugs
(access to addr 0) not to cause errors on Windows/Linux
immediatly; on OS X, by default reads/writes to address 0
trigger EXC_BAD_ACCESS, which IMHO is a good thing)

* we have another gap in our interpreter (?) not so likely,
but you never can be sure

* maybe actor 0 has a special meaning in Indy3, e.g. "the
current actor" or so

* maybe the number 0 comes from some variable (as in
readVar()/writeVar()) that wasn't set properly?

comment:6 Changed 17 years ago by SF/andrej4000

Perhaps it' ssomehow related to the train bug in tzhe
beginning of the game?
There instead if Indy the train or the legs of young Indy are
shown. I think I remember, that this was related to Actor 0,
too.

comment:7 Changed 17 years ago by eriktorbjorn

I think I see what's causing this bug. This is a fragment
from a descummed script-2.dmp:

[00ED] (84) if (Var[0] <= Local[7]) {
[00F4] (8B) Var[0] = getVerbEntryPoint(Local[1],3)
[00FB] (A8) if (Var[0]) {
[0100] (C9) faceActor(Local[2],Local[3])
[0105] (C9) faceActor(Local[3],Local[2])
[010A] (9A) Var[7] = Local[1];
[010F] (B7) startObject(Local[1],3,[Local[2]])
[0117] (0A) startScriptAA(15,[])
[011A] (18) goto 0341;
[0120] (9D) } else if ClassOfIs(Local[2],[133]) {
[0129] (8A)
startScriptAA(Var[52],[Local[1],Local[3],Local[2]])
[0136] (18) } else {
[0139] (42) chainScript(3,[Local[0]])
[013F] (**) }
[013F] (**) }

I'm fairly sure that it's the "startScriptAA(Var[52], ..."
opcode that starts script 1, i.e. restarts the game.
Variable 52, a.k.a. VAR_CURSORSTATE, is modified quite
frequentlty by o5_cursorCommand(). Of course, this makes
absolutely no sense at all in this context. If I remove that
line from o5_cursorCommand() things seem to work properly.

Of course, variable 52 may still be clobbered in a savegame,
but I assume playing the game for a bit restores it to a
more appropriate value again.

Does this mean Indy 3 doesn't have any "cursor state
variable", or does it mean that it should use some other
variable than 52? Is it restricted to Indy 3, or does it
affect all GF_OLD256 games?

comment:8 Changed 16 years ago by fingolfin

Owner: set to SF/ender

comment:9 Changed 16 years ago by fingolfin

No idea, eriktobjorn... Maybe Endy knows more, or can look this up in an IDA DB for Indy3 ?

comment:10 Changed 16 years ago by fingolfin

Maybe VAR_CURSORSTATE shouldn't be 52 at all for Indy3. Zak256, for example, also had weird problems caused by variable mismatches.

comment:11 Changed 16 years ago by aquadran

Status: newclosed

comment:12 Changed 16 years ago by aquadran

variable cursor state is only set by o5_cursorCommand and
never used in the code

comment:13 Changed 16 years ago by fingolfin

Status: closednew

comment:14 Changed 16 years ago by fingolfin

That's no reason to close this item, though, the bug is still there after all. Also note, cursorCommand sets the variable so that *script*s can use it.

comment:15 Changed 16 years ago by fingolfin

Owner: changed from SF/ender to eriktorbjorn

comment:16 Changed 16 years ago by fingolfin

This bug should be fixed by erik's patch. Can somebody verify (the
save game crahes ScummVM for me)?

Re-assigning this to erik since he fixed it (hopefully ;-)

comment:17 Changed 16 years ago by eriktorbjorn

I played through the game earlier today (to verify that
another bug had been fixed, actually) and I wasn't able to
reproduce it any more. Which makes sense since we no longer
set that "cursor state" variable for Indy3. (Actually that
change was eventually made to fix a showstopping bug in EGA
Loom, but never look a gift horse in the mouth. :-)

comment:18 Changed 16 years ago by eriktorbjorn

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.