Changed the extended saves code so time is stored in milliseconds
instead of seconds. This fixes an issue where loading a save would
pass a playtime value of 1/1000 of the real playtime to the engine,
resulting in total playtime effectively being zeroed every time a
save is loaded.
Existing savefile compatibility is ignored since the value stored
inside old saves would be wrong for any savefile that has been
saved over more than once.
Addresses a vulnerability where the autosave slot may present as a regular empty slot when autosaving is disabled.
By default, an empty autosave slot will always:
- be identified by a dummy autosave.
- display the current autosave state.
- remain clear until an autosave creates the autosave file.
Also reinstated desc.setAutosave(header.isAutosave) call in querySaveMetaInfos().
These changes are simply a reversion of the relevant changes made in #3261, including any subsequent changes since then.
The autosave refactoring that was done in
7adad5aaf5831dc5adcee140f38aacc4a5db2518 used g_engine for identifying the
autosave slot. This worked for in-game save/load, but doesn't fit when
called from the launcher.
Fix by passing MetaEngine to SaveStateDescriptor ctor and using it for this
query.
Amends 7adad5aaf5831dc5adcee140f38aacc4a5db2518.
Some engines call setAutosave and some don't. isAutosave is used to
determine if a saved game is an autosave, but in fact, on most cases it
just falls back to comparing the name to "Autosave".
This is wrong for several reasons:
* Older versions of ScummVM used Autosave 0.
* The name "Autosave" is translated, so if you change the language, it
won't be detected.
Instead of relying on the name, use the well-known getAutosaveSlot() from
Engine/MetaEngine.
Fixes#12735.
At some point when splitting the MetaEngine to a detection
plugin and a static meta engine, the former was called
MetaEngine while the latter was called MetaEngineConnect.
Thus was then later change to MetaEngineDetection and
MetaEngine. But some references were left to the former
names in comments and documentation.
- Rename the one in ME to avoid ambiguity.
- ME is named *static & MEC is named *dynamic.
- This change means that engines can build 2 types of option widgets.
- The "Engine" tab is created statically regardless if an engine plugin is present or not.
- The in-game options are built using the MEC.
- With this commit, engines/dialogs is no longer dependant on MetaEngine, and instead used MEC all over.
- These include various functions and functionalities related to save/load.
- These are shifted, because the MEC class will house things that can be dynamic in nature.
- The MetaEngine class is fully & only dependent on ScummVM code, so it can always be built into executable.
This also fixes a problem with the Griffin engine, which
although it was using the new type saves, was using a
target.s?? format, so wasn't listing files in the GMM
save dialog
This fixes two issues. First of all, when I was fleshing
out the Quux example engine with save support, I realised
that the default savegame pattern for engines is target.***,
whereas for the meta engine it was target.s**. This was
causing newly created saves not to appear in the savegame list.
The second is a minor convenience nicety.. if an engine is
supporting the new extended format, it means they do have saves,
so it's better to default to 100 slots by default without
requiring the engine to explicity declare it.
By implementing MetaEngine::buildEngineOptionsWidget, engines can
instantiate a container widget that will be shown in the Engine tab of
the edit game dialog. The default implementation retains the existing
behavior and shows the extra GUI options.
If the autosave slot doesn't yet have any file in it, when the
GMM save dialog is open, the autosave slot will show a default
'Autosave' entry which is write-only, to prevent users
accidentally making a savegame in that slot
