10 | | With its current positioning, the autosave method is called much later than previously. Is it possible that this later code inside ''doFrame()'', that now runs before the autosave is called, may be changing the status of ''canSaveAutosaveCurrently()'' from false to true? |
11 | | |
12 | | Would repositioning ''saveAutosaveIfEnabled()'' from its current position to inside an ''if hasGameEnded()'' statement placed immediately after ''processInput()'' in the ''doFrame()'' method - completing the autosave call before ''doFrame()'' continues, as was the case previously - possibly fix the problem? |
13 | | |
14 | | For the record, when exiting during a cutscene, the game state transitions from non-interactive (when the player makes the exit call) to interactive (enabling the exit to complete), before exiting. |
15 | | Confirmation of this can be observed by the disabled Save/Load buttons in the GMM, and the brief flash of the next fully-interactive frame before the game exits. |
16 | | |
17 | | 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). |
18 | | |
19 | | The role of autosaving is to track the player’s progress. Progress stops when the player elects to exit the game, so autosaving should test against the prevailing game state when that call is made. |
20 | | |
21 | | Current autosave behaviour confirms that this game state transition completes before exiting ''doFrame()''. This behaviour is therefore officially a bug, and should be corrected, since it skips gameplay not experienced by the player prior to exit. |
| 10 | I’m closing this ticket in favour of #11440, to put this issue into its proper perspective. |