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

[macca8]

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)

[macca8]

Expected Autosave start position - Trapbook endings

[macca8]

Expected Autosave start position - Refusal ending

[macca8]

Telescope - click button to lower telescope.

[macca8]

Trapbook - enter open trapbook.

[macca8]

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

[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.

[dafioram]

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

[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.

[macca8]

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.