Made the autosave section more of a list.
Added tucker, myst, riven, zvision, and composer to the list.
Noted when riven and myst will autosave in their notes.
With the addition of autosaving support, deleting saves
(via the gui) to slot 0 was disabled, but for saves that
have been previousl created by the user it make sense
that they should be allowed to delete a save in slot 0.
Fixes Trac#10536.
The previous logic was enabling autosaving if the metadata
file was not present, but saves from the original
don't have metadata. Now it checks if the non-metadata
file can be loaded to determine if the slot is empty.
The game will autosave to slot 0 using the save
period given in the scummvm config file.
Or when the user quits.
Autosaves are only allowed when an autosave is
in slot 0, there is no save in slot 0, or there
is a save, but it is corrupt.
This will not override any saves the player
has previously put in save slot 0. If there
is a save in slot 0 that is not an autosave
then there will be no autosaving.
The game will autosave to slot 0 using the save
period given in the scummvm config file
or when the user exits using the GMM.
Autosaves are only allowed when an autosave is
in slot 0 or there is no save in slot 0.
This will not override any saves the player
has previously put in save slot 0. If there
is a save in slot 0 that is not an autosave
then there will be no autosaving.
Our decoder currently only supports the standard FLC format which
does not rely on the stored packet count (which is part of the FLI
format and limited to 255 packets per line).
Instead, the image width should be used as criterion when decoding
a frame which allows for more than 255 packets per line.
See also https://www.compuphase.com/flic.htm
v5+ scripts can request saving/loading of savegames, this type of
savegame is internally called a "temporary" savegame
(_saveStateTemporary == true) which is invisible to the user (I'm not
sure whether this is by design or not).
Currently the savegame handling in scummLoop_handleSaveLoad() doesn't
distinguish between such temporary savegames and normal autosaves and
unconditionally resets _lastSaveTime (even after loading).
This has the unwanted side effect of potentially delaying the creation
of normal autosaves which are supposed to be created in accordance with
the autosave period setting in the GUI.
This commit makes sure that _lastSaveTime only gets updated if and only
if saving a (non-temporary) autosave.