Opened 4 months ago

Last modified 2 months ago

#14556 new defect

SCI: Crash in Island of Dr. Brain robot maze puzzle

Reported by: eriktorbjorn Owned by:
Priority: normal Component: Engine: SCI
Version: Keywords:
Cc: Game: Island of Dr. Brain

Description (last modified by eriktorbjorn)

This happened while trying to solve the robot maze puzzle in The Island of Dr. Brain. I was using the Android version, 2.7.0.5. I have no tried to reproduce it yet.

From what I remember of what I did, I sent the robot through the maze to pick up the first secret crate. I was using the good chip. I accidentally dropped the crate one step before the exit, so I amended the program and sent the robot through the maze again. (Apparently I didn't have to do that, because the crate was gone and the object was still lying near the exit, but I didn't know that.)

While waiting for the robot to finish, not really paying attention to where it was, the game suddenly crashed to the debug console:


Judging by the SCI backtrace, it ran into some sort of infinite recursion, and that's why it ran out of stack?


Attachments (3)

brain-crash1.jpg (56.9 KB ) - added by eriktorbjorn 4 months ago.
brain-crash2.jpg (91.3 KB ) - added by eriktorbjorn 4 months ago.
brain2-savegames.zip (86.6 KB ) - added by eriktorbjorn 3 months ago.

Download all attachments as: .zip

Change History (16)

by eriktorbjorn, 4 months ago

Attachment: brain-crash1.jpg added

by eriktorbjorn, 4 months ago

Attachment: brain-crash2.jpg added

comment:1 by eriktorbjorn, 4 months ago

Description: modified (diff)

comment:2 by m-kiewitz, 4 months ago

Yes, you ran out of stack.
Something calls itself over and over, wouldn't be the first time.
Endless ::cue'ing.

You should probably be able to reproduce this w/ the original interpreter and doing so would be helpful. I'm not sure what the original interpreter does in this situation. Either locks up or exits to DOS.

I assume it's a script bug.

comment:3 by eriktorbjorn, 4 months ago

You should probably be able to reproduce this w/ the original interpreter and doing so would be helpful.

That may take a while. The puzzle appears late in the game, and puzzles are randomized. I'll try to find some time to attempt it, but it probably won't be this week.

comment:4 by m-kiewitz, 4 months ago

I should be able to create a script for you to jump to that puzzle room.
or maybe I even got saved games somewhere...

comment:5 by eriktorbjorn, 4 months ago

That sounds like it would be very useful indeed!

comment:6 by m-kiewitz, 3 months ago

to patch the game:
extract 140.hep by entering "diskdump heap 140" inside debugger console

edit that file with a hex-editor
look for the sequence:
000005e0: 00 00 ff ff 0a 00 00 00-00 00 00 00 8c 00 ff ff ................
000005f0: 00 00 00 00 a0 00 00 00-82 00 00 00 00 00 00 00 ................

The SECOND a0 00 is the room number to the north. You have to figure out the destination room number and change that value accordingly.

Now I'm not sure which file name convention the original Sierra interpreter needs. It may be 140.hep

You should be able to use that too for the other bugs.
You can figure out the current room number by entering the command "room", but sometimes that info may be wrong, I'm not sure. I can't load all my old saved games, because of some new assert()s.

Last edited 3 months ago by m-kiewitz (previous) (diff)

comment:7 by m-kiewitz, 3 months ago

140 is the very first room after the copy protection btw.
Of course some puzzles may need items in your inventory. if they do, that would be a problem.

comment:8 by m-kiewitz, 3 months ago

You will have to restart the game every time you make a change like that.
Saved games will still jump to the original room.
This means you will have to solve the very first puzzle multiple times.

If this is not acceptable/bothersome, I can create a different patch, which should then work every time even when you load a saved game.

comment:9 by eriktorbjorn, 3 months ago

Thanks, but I decided after reading your description that it was probably less error-prone to just play through the game up to that point on Novice level. (I think you can change difficulty at any time?)

I haven't yet tried to reproduce the bug, though.

by eriktorbjorn, 3 months ago

Attachment: brain2-savegames.zip added

comment:10 by eriktorbjorn, 3 months ago

I haven't yet been able to reproduce this in DOSBox. Sometimes I really dislike randomized puzzles...

comment:11 by m-kiewitz, 3 months ago

Maybe it's just one special RNG case.
Or maybe it's recursive according to how often you tried?!
Did you try to solve the puzzle 10+ times when it crashed?

comment:12 by eriktorbjorn, 3 months ago

I don't remember, but I don't think I was trying to do more than just get through the puzzle. And if I was playing it on the highest difficulty (I think I was), I was probably still on either the first or second chip.

comment:13 by deckarep, 2 months ago

Hello hopefully this is just some added help:

For my copy of the game:

Running The Island of Dr. Brain (DOS/English)
resource.000: b3acd9b9dd7fe53c4ee133ac9a1acfab
resource.map: 2388efef8430b041b0f3b00b9050e4a2

I was able to verify the room with this puzzle is room 300 and script: 320 or programmer.sc which has this robot puzzle game.

The room loads that script at some point and in there is the robot:cue method which has a condition clause that can call cue on itself again. The riddle though is how the game gets into such a state where this becomes a stack overflow...

Hopefully this saves someone some time or trouble in the continued investigation.

Note: See TracTickets for help on using tickets.