Changes between Version 2 and Version 3 of Ticket #11399, comment 8


Ignore:
Timestamp:
04/18/20 02:42:12 (4 years ago)
Author:
macca8

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #11399, comment 8

    v2 v3  
    44The autosaves created are perfectly fine, with the minor issues all resolved by the fixes applied in this report and #11417.
    55
    6 With regard to the pending issue with the autosave created when exiting during a cutscene, I was wondering if repositioning the ''saveAutosaveIfEnabled()'' call might fix the issue?
     6With regard to the pending issue of an autosave now being created when exiting during a cutscene, I was wondering if repositioning the ''saveAutosaveIfEnabled()'' call might fix the issue?
    77
    88We already know that, prior to the change, Quit/RTL calls from keyboard & GMM (via Ctrl+F5) were being handled correctly by the autosave call positioned within the ''processInput()'' method.
    99
    10 With its current positioning, the autosave method is called much later than previously. Is it possible that the extra code that runs inside ''doFrame()'', before the autosave is called, may be changing the status of ''canSaveAutosaveCurrently()'' from false to true?
     10With 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?
    1111
    12 Would repositioning ''saveAutosaveIfEnabled()'' from its current position to immediately after ''processInput()'' in the ''doFrame()'' method - placing it closer to its previous position, where it was working properly - and avoiding all the extra code in ''doFrame()'', possibly fix the problem?
     12Would 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?
    1313
    1414It may be completely irrelevant, but I thought it worth asking the question.