#564 closed defect (fixed)
INDY3: Henry causes the game to restart
| Reported by: | SF/andrej4000 | Owned by: | eriktorbjorn |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | 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)
Change History (19)
by , 21 years ago
comment:1 by , 21 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 , 21 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 , 21 years ago
It doesn't happen with the original interpreter. Henry just refuses the items.
Perhaps a wrong script is loaded in ScummVM?
comment:5 by , 21 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 , 21 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 , 21 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 , 21 years ago
| Owner: | set to |
|---|
comment:9 by , 21 years ago
No idea, eriktobjorn... Maybe Endy knows more, or can look this up in an IDA DB for Indy3 ?
comment:10 by , 21 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 , 21 years ago
| Status: | new → closed |
|---|
comment:12 by , 21 years ago
variable cursor state is only set by o5_cursorCommand and never used in the code
comment:13 by , 21 years ago
| Status: | closed → new |
|---|
comment:14 by , 21 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 , 21 years ago
| Owner: | changed from to |
|---|
comment:16 by , 21 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 , 21 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 , 21 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Just geve something to Henry...