Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#10263 closed defect (fixed)

SCI: RAMA: Crash restoring bomb save

Reported by: dafioram Owned by: csnover
Priority: normal Component: Engine: SCI
Keywords: sci32 Cc:
Game: RAMA

Description

Game: RAMA 1.0 DOS/English
Tester OS: Win7-64
ScummVM: 1.10.0git-5097-gd75dab4

There are two issues when at the final bomb.

  1. No autosave is made prior to the bomb going off (when the player puts in a wrong code 3 times).

So if the player clicks retry after the bomb going off the game will load up whatever was the last autosave. If that was the biot in the room then its not a big deal, but if not it could be a ways back. My last autowave was in the octolair when I tried to swim in the toxic water.

  1. If the player saves at the bomb (while facing it) then tries to load that save again it will crash.

Saving at other nodes seems to be fine.

Uninitialized read for parameter 1 from method NukeTimer::getSubscriberObj (room 8115, script 201, localCall ffffffff)!
lookupSelector: Attempt to send to non-object or invalid script. Address 0000:0000, method NukeTimer::serialize (room 8115, script 201, localCall ffffffff)!

BT:

0: script 0 - Rama::play()
     obj@0001:035c pc=0001:2c13 sp=ST:0000 fp=ST:0000 argp:ST:0001
 1: script 0 - Rama::init()
     by 0 obj@0001:035c pc=0001:20e5 sp=ST:000a fp=ST:0005 argp:ST:0004
 2: script 0 - Rama::newRoom(0000:03f7)
     by 1 obj@0001:035c pc=0001:23dc sp=ST:0016 fp=ST:000d argp:ST:000b
 3: script 64999 - Event::new(0000:0003)
     by 2 obj@0004:0ce4 pc=0004:16fa sp=ST:001a fp=ST:0019 argp:ST:0017
 4:[3]  kGetEvent(0000:0003, 000f:000f)
     by 3 obj@0000:0000 pc:none argp:ST:001a
 5: script 0 - Rama::restore()
     by 4 obj@0001:035c pc=0001:2a8e sp=ST:0021 fp=ST:001f argp:ST:001e
 6: script 85 - SaveManager::restore()
     by 5 obj@001a:0018 pc=001a:0ac5 sp=ST:0026 fp=ST:0023 argp:ST:0022
 7: script 0 - Rama::serialize(0000:0001)
     by 6 obj@0001:035c pc=0001:2ff4 sp=ST:002c fp=ST:0029 argp:ST:0027
 8: script 201 - newYorkRegion::serialize(0000:0001)
     by 7 obj@0023:06b0 pc=0023:23f7 sp=ST:0031 fp=ST:002f argp:ST:002d
 9: script 201 - NukeTimer::serialize(0000:0001)
     by 8 obj@0023:00d0 pc=0023:19b4 sp=ST:003b fp=ST:0034 argp:ST:0032

Attachments (2)

rama.001 (17.9 KB ) - added by dafioram 2 years ago.
A good save at the bomb. In order to produce a bad save click on the bomb and then save.
rama.002 (19.5 KB ) - added by dafioram 2 years ago.
A save that will crash. I am facing the bomb.

Download all attachments as: .zip

Change History (9)

by dafioram, 2 years ago

Attachment: rama.001 added

A good save at the bomb. In order to produce a bad save click on the bomb and then save.

by dafioram, 2 years ago

Attachment: rama.002 added

A save that will crash. I am facing the bomb.

comment:1 by m-kiewitz, 2 years ago

Did the original interpreter auto save at that place?

comment:2 by dafioram, 2 years ago

I don't know what the original interpreter did at that point.

comment:3 by m-kiewitz, 2 years ago

It would be very helpful, if you could check that.

comment:4 by dafioram, 2 years ago

In the original am autosave is not made before the bomb blows up. I guess they were assuming the biot there would kill you (which does give you an autosave).

The original doesn't have the crash.

comment:5 by dafioram, 2 years ago

To make this issue more focused, this can just be about the crash and we can worry about whether or not an autosave before the bomb is worth it later.

comment:6 by csnover, 2 years ago

Owner: set to csnover
Resolution: fixed
Status: newclosed
Summary: SCI: RAMA: Bomb saves have issuesSCI: RAMA: Crash restoring bomb save

Thanks for your report! A patch for this issue has been added in commit bb02d730b4b21cd38045c3be76ad39ea61c65803 and will be available in daily builds 1.10.0git-5186 and later.

With regards to there not being an auto-save, it’s hard to say whether that was an accidental or intentional omission. There is definitely no case of an autoSave call in the room script for the bomb room or anything that looks like an accidentally wrong call to something else that was supposed to be an autoSave call, and since it is the endgame sequence, it is entirely plausible that they wanted mistakes to be costly. So I’m not super-inclined to try to change that behaviour, but maybe others feel differently.

comment:7 by csnover, 2 years ago

Oh, also: this was an issue with the restore code, not the save code, so those save games are completely valid.

Note: See TracTickets for help on using tickets.