Opened 18 years ago

Closed 18 years ago

Last modified 18 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 18 years ago.
Just geve something to Henry…

Download all attachments as: .zip

Change History (19)

by SF/andrej4000, 18 years ago

Attachment: indy3.s01 added

Just geve something to Henry...

comment:1 by SF/ender, 18 years ago

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 by SF/ender, 18 years ago

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

comment:3 by SF/andrej4000, 18 years ago

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

Perhaps a wrong script is loaded in ScummVM?

comment:4 by fingolfin, 18 years ago

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

comment:5 by fingolfin, 18 years ago

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 by SF/andrej4000, 18 years ago

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 by eriktorbjorn, 18 years ago

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 by fingolfin, 18 years ago

Owner: set to SF/ender

comment:9 by fingolfin, 18 years ago

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

comment:10 by fingolfin, 18 years ago

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

comment:11 by aquadran, 18 years ago

Status: newclosed

comment:12 by aquadran, 18 years ago

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

comment:13 by fingolfin, 18 years ago

Status: closednew

comment:14 by fingolfin, 18 years ago

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 by fingolfin, 18 years ago

Owner: changed from SF/ender to eriktorbjorn

comment:16 by fingolfin, 18 years ago

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 by eriktorbjorn, 18 years ago

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 by eriktorbjorn, 18 years ago

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