[Scummvm-tracker] [ScummVM :: Bugs] #11440: MOHAWK: RIVEN: Autosave no longer tests against game state at time of exit call. (was: MOHAWK: RIVEN: Autosave doesn’t test against game state at time of exit call.)

[ScummVM :: Bugs]

#11440: MOHAWK: RIVEN: Autosave no longer tests against game state at time of exit
call.
---------------------+----------------------------
  Reporter:  macca8  |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  normal  |  Component:  Engine: Mohawk
Resolution:          |   Keywords:
      Game:  Riven   |
---------------------+----------------------------
Changes (by macca8):

 * summary:
     MOHAWK: RIVEN: Autosave doesn’t test against game state at time of
     exit call.
     =>
     MOHAWK: RIVEN: Autosave no longer tests against game state at time of
     exit call.


Old description:

> This is a change from previous behaviour, caused by one of the changes in
> commit 40cb2f8 in resolving #11399, which affects the handling of
> autosaves when exiting during a cutscene.
>
> Current Daily Build: 2.2.0git4606-g900b86ff7f (21 April 2020)
> Game Version: English, 5-CD (contains v1.02 patch files)
> Platform: Intel Mac (OS X 10.6.8, 10.11.6)
>
> For the record, when exiting during a cutscene, the game state
> transitions from non-interactive (when the player makes the exit call) to
> interactive (after skipping to the next available fully-interactive
> frame), before exiting.
>
> Confirmation of this can be observed by the disabled Save/Load buttons in
> the GMM, and the brief display of the next fully-interactive frame before
> the game exits. Cutscenes containing an embedded interactive element
> (Gehn visits) differ slightly in that they briefly pause the current
> frame, instead of displaying the next available frame, but still complete
> the transition to interactive before exit.
>
> Understanding this exit behaviour makes predicting autosave-on-exit
> performance reliable, regardless of game state… if non-interactive, no
> save is performed, and if interactive, a save is performed (except where
> autosaving is disabled by default, such as the Start Menu).
>
> The role of autosaving is to track the player’s progress. That progress
> stops when the player elects to exit the game, so autosaving should test
> against the prevailing game state when that call is made.
>
> There’s also an expectation that if manual saving is disabled, then
> autosaving is also disabled.
>
> Current autosave-on-exit behaviour confirms that the game completes its
> transition to an interactive state before it’s called. This behaviour
> should be corrected, since it skips gameplay not experienced by the
> player prior to the exit call.
>
> Player’s expectations aside, for those dependent on autosaving, this
> unexpected overwrite can make some cutscenes inaccessible upon restart
> (for example, if interacting with Gehn).
>
> Fortunately, this issue can be resolved by moving the
> ''saveAutosaveIfEnabled()'' method to where it can be called while the
> game is still in a non-interactive state.
>
> We already know that, prior to the fix applied in #11399, Quit/RTL calls
> from keyboard & GMM (via Ctrl+F5) were handled correctly by
> ''saveAutosaveIfEnabled()'' when called from within the
> ''processInput()'' method, inside ''doFrame()''.
>
> Now positioned outside the ''doFrame()'' method,
> ''saveAutosaveIfEnabled()'' is not called until after the game has
> transitioned to an interactive state, before exiting. As a result,
> ''canSaveAutosaveCurrently()'' returns true, instead of the expected
> false, prompting the unwanted autosave.
>
> Would repositioning ''saveAutosaveIfEnabled()'' back inside the
> ''doFrame()'' method, but placing it immediately after ''processInput()''
> and contained within an ''if hasGameEnded()'' statement - completing the
> autosave call before ''doFrame()'' continues, as was the case previously
> - possibly fix this issue?

New description:

 This is a change from previously correct autosave-on-exit behaviour
 (before rebinding F5 to open the GMM was implemented), subsequently caused
 by one of the changes in commit 40cb2f8 in resolving #11399, which now
 adversely affects the handling of autosaves when exiting during a
 cutscene.

 Current Daily Build: 2.2.0git4606-g900b86ff7f (21 April 2020)
 Game Version: English, 5-CD (contains v1.02 patch files)
 Platform: Intel Mac (OS X 10.6.8, 10.11.6)

 For the record, when exiting during a cutscene, the game state transitions
 from non-interactive (when the player makes the exit call) to interactive
 (after skipping to the next available fully-interactive frame), before
 exiting.

 Confirmation of this can be observed by the disabled Save/Load buttons in
 the GMM, and the brief display of the next fully-interactive frame before
 the game exits. Cutscenes containing an embedded interactive element (Gehn
 visits) differ slightly in that they briefly pause the current frame,
 instead of displaying the next available frame, but still complete the
 transition to interactive before exit.

 Understanding this exit behaviour makes predicting autosave-on-exit
 performance reliable, regardless of game state… if non-interactive, no
 save is performed, and if interactive, a save is performed (except where
 autosaving is disabled by default, such as the Start Menu).

 The role of autosaving is to track the player’s progress. That progress
 stops when the player elects to exit the game, so autosaving should test
 against the prevailing game state when that call is made.

 There’s also an expectation that if manual saving is disabled, then
 autosaving is also disabled.

 Current autosave-on-exit behaviour confirms that the game completes its
 transition to an interactive state before it’s called. This behaviour
 should be corrected, since it skips gameplay not experienced by the player
 prior to the exit call.

 Player’s expectations aside, for those dependent on autosaving, this
 unexpected overwrite can make some cutscenes inaccessible upon restart
 (for example, if interacting with Gehn).

 Fortunately, this issue can be resolved by moving the
 ''saveAutosaveIfEnabled()'' method to where it can be called while the
 game is still in a non-interactive state.

 We already know that, prior to the fix applied in #11399, Quit/RTL calls
 from keyboard & GMM (via Ctrl+F5) were handled correctly by
 ''saveAutosaveIfEnabled()'' when called from within the ''processInput()''
 method, inside ''doFrame()''.

 Now positioned outside the ''doFrame()'' method,
 ''saveAutosaveIfEnabled()'' is not called until after the game has
 transitioned to an interactive state, before exiting. As a result,
 ''canSaveAutosaveCurrently()'' returns true, instead of the expected
 false, prompting the unwanted autosave.

 Would repositioning ''saveAutosaveIfEnabled()'' back inside the
 ''doFrame()'' method, but placing it immediately after ''processInput()''
 and contained within an ''if hasGameEnded()'' statement - completing the
 autosave call before ''doFrame()'' continues, as was the case previously -
 possibly fix this issue?

--
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/11440#comment:2>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM