[Scummvm-tracker] [ScummVM] #10635: MOHAWK: Riven: End game Autosave may set incorrect save/load status when loaded.

macca8 trac at scummvm.org
Sat Jul 21 08:11:26 CEST 2018


#10635: MOHAWK: Riven: End game Autosave may set incorrect save/load status when
loaded.
-------------------+----------------------------
Reporter:  macca8  |      Owner:  (none)
    Type:  defect  |     Status:  new
Priority:  low     |  Component:  Engine: Mohawk
Keywords:          |       Game:  Riven
-------------------+----------------------------
 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)

--
Ticket URL: <https://bugs.scummvm.org/ticket/10635>
ScummVM <https://bugs.scummvm.org>
ScummVM


More information about the Scummvm-tracker mailing list