Opened 9 months ago

Closed 7 months ago

Last modified 7 months ago

#10635 closed defect (fixed)

MOHAWK: Riven: End game Autosave may set incorrect save/load status when loaded.

Reported by: macca8 Owned by: macca8
Priority: low Component: Engine: Mohawk
Keywords: Cc:
Game: Riven

Description

An autosave is performed when the game ends if the autosave-period expires at any time during an end game sequence (end game cutscene or credits).

As with other cutscenes encountered within the game, the autosave is delayed until the full sequence completes (i.e. after the credits end), as is confirmed by the Autosave’s thumbnail image of the final credits.

Just to be clear, this is NOT an autosave-on-exit event. If the Autosave option is set to ’Never’ (period=0), this autosave is never invoked.

What follows is my interpretation of what’s going on, so it may not be technically accurate (I’d appreciate some clarification from bgK here regardless of the outcome).

Unlike other cutscenes, because the game quits immediately the sequence ends, an updated interactive game state is never created.

As a result, the save event defaults to a previous game state where saving is possible, which in this case is expected to be the scene where the user launches the ending (or, if the ending is launched from within a cutscene, the scene that launches that cutscene).

For the record, this type of save behaviour isn’t new. I experienced it (back in January 2015) when a broken cutscene hung the game indefinitely, preventing the transition from the cutscene. On that occasion, I was able to save via the GMM for a similar result.

Up to this point, everything appears as normal predictable behaviour with no adverse effect on the user.

However, if the user chooses to load the Autosave (as unlikely as that may be), then anomalies appear with some endings.

Endings triggered by breaking the portal with the telescope (4) load the expected pre-cutscene state and perform as expected.

However, for some reason, all other endings don’t load the expected pre-cutscene state (see attached images) as part of the save. For each of these endings, the relevant cutscene is launched immediately with the save/load status enabled.

This includes endings triggered by:

  • entering the open trapbook from your inventory (5),
  • refusing for the third time to enter the trapbook (1).

For those Autosave endings which load with save/load enabled in error, both autosave-on-exit (Quit or RTL) & ordinary saving are now available during cutscenes & credits. The resulting saved game matches those described previously, except that the thumbnail image reflects the screen at the time of the save.

The problem action is trying to load another saved game from in-game. The Load menu can be accessed, but attempting to load another save will cause the game to quit unexpectedly.

Nothing appears in the ScummVM log, and system crash reports are inconsistent, and can refer to any of ‘Abort trap’, ‘segmentation fault’ or ‘bus error’.

I’ve attached some user-created saved games for each type of ending to enable suitable autosaves to be created.

For each saved game:

  • use the default autosave-period (5 minutes),
  • load the saved game & wait 2 minutes (ensures the period expires during the ending),
  • use the appropriate method to trigger the ending,
  • allow the game to quit automatically.

I apologise that this report is long winded, but I thought it best to be thorough given the apparent inconsistencies between endings.

Current Daily Build: 2.1.0git2845-gf999772(20 July 2018)
Game Version: English, 5-CD (contains v1.02 patch files)
Platform: Intel Mac (OS X 10.6.8, 10.11.6)

Attachments (5)

Trapbook ending.png (66.6 KB) - added by macca8 9 months ago.
Expected Autosave start position - Trapbook endings
Refusal ending.png (249.4 KB) - added by macca8 9 months ago.
Expected Autosave start position - Refusal ending
riven-021.rvn (25.0 KB) - added by macca8 9 months ago.
Telescope - click button to lower telescope.
riven-022.rvn (12.4 KB) - added by macca8 9 months ago.
Trapbook - enter open trapbook.
riven-023.rvn (21.3 KB) - added by macca8 9 months ago.
Refusal - click button to signal Gehn, refuse to enter trapbook.

Download all attachments as: .zip

Change History (11)

Changed 9 months ago by macca8

Attachment: Trapbook ending.png added

Expected Autosave start position - Trapbook endings

Changed 9 months ago by macca8

Attachment: Refusal ending.png added

Expected Autosave start position - Refusal ending

Changed 9 months ago by macca8

Attachment: riven-021.rvn added

Telescope - click button to lower telescope.

Changed 9 months ago by macca8

Attachment: riven-022.rvn added

Trapbook - enter open trapbook.

Changed 9 months ago by macca8

Attachment: riven-023.rvn added

Refusal - click button to signal Gehn, refuse to enter trapbook.

comment:1 Changed 9 months ago by macca8

A recent change (probably part of the 25th Anniversary changes) now disables autosaving when the inventory screen is displayed. This affects both time-based autosaves & autosave-on-exit.

The behaviour described in this report predates that change, and hasn’t been affected by the change. It may, of course, impact any solution relative to the trapbook endings.

comment:2 Changed 9 months ago by dafioram

Owner: set to dafioram
Resolution: fixed
Status: newclosed

Thanks for your report. This is fixed in commit 3299402a.

comment:3 Changed 7 months ago by macca8

For the record, the change I mentioned in comment 1 has been reverted to its previous behaviour by bgK with commit 22ded2c on 10 September 2018. Autosaving is now enabled when any of the inventory books are displayed.

Last edited 7 months ago by macca8 (previous) (diff)

comment:4 Changed 7 months ago by dafioram

Resolution: fixed
Status: closednew

comment:5 Changed 7 months ago by dafioram

Owner: dafioram deleted

comment:6 Changed 7 months ago by macca8

Owner: set to macca8
Resolution: fixed
Status: newclosed

Don't know why you changed the status back to 'new'. The bug as described is fixed.

My recent comment simply clarifies the current status with the inventory screen, which has nothing to do with the end game bug resolved here. There's nothing to fix here since bgK has already resolved the inventory screen issue.

Last edited 7 months ago by macca8 (previous) (diff)
Note: See TracTickets for help on using tickets.