The saveType property is intended to identify the type of save stored in the autosave slot. Setting the saveType property based on slot type identifies any type of save stored in the autosave slot as an autosave. It's therefore inappropriate for identifying the actual type of save in the slot
Reverting the method prevents an autosave from overwriting a regular save without warning (fixes [#13841](https://bugs.scummvm.org/ticket/13841)).
Restructure isAutosave() function:
- Prioritize name test
- Access saveType test only if name test fails
Performs both tests when required, resolving false positives unique to each test, and ensures that only saves which fail both tests appear in autosave warning dialogs.
Properly fixes [https://bugs.scummvm.org/ticket/12363#12363], refer [https://bugs.scummvm.org/ticket/13842#13842]
The length of the German translation for Autosave is 23 characters. Save names in Groovie are limited to 15 characters, and it's probably not the only engine with a similar limit. This meant you would get a warning on every autosave, even though you just told it to overwrite. Mminimum of 14 characters for confidence that the name is a match and not a false positive.
Some engines (like kyra) return a SaveStateDescriptor with slot assigned,
even when the slot is free. The indication for an empty save is empty
description on these cases.
The autosave refactoring that was done in
7adad5aaf5 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 7adad5aaf5.
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.
- The changes previously were creating a temporary object whose lifetime was limited to that line.
- Additionally, use Strings instead of const char* in MessageDialogs.
After the initial changes just to scummvm/gui for u32, this commit includes the whole project
- Widget creations now always have u32 descriptions, labels, or tooltips
- Message dialogs make use of default arguments instead of providing the same argument explicitly
- encode String::format properly before passing on as argument where necessary
- Modify hugo utils (yesNoBox and notify box) to use u32
- Also provide fake constructors for the above which redirect to the u32 constructor
- Convert all keymap descriptions to u32 across all engines
- showConfirmationDialog in mohawk now uses u32
- showScummVMDialog also uses u32
- Scumm engine has dialogs now which use u32
- General fixes and wrapping convertToU32String for setLabels and related functions
- Add a fake constructor to MesssageDialog which redirects to the u32 constructor
This commit also includes some additional major changes.
- Return U32String from TransMan getTranslation()
- Change tooltips to be U32Strings
- Remove temporary code of convertToU32String
- U32 Support various dialogs (Browser, FileBrowser, Messages, Chooser, etc)
- U32 for music plugins
- U32 for OSD messages
- Add some helper functions to ustr.cpp
- Change default tooltips from nullptr & 0 -> ""
- Some runtime exceptions may occur when changing languages due to incorrect String::Format
This will make setting the playtime for the engine easier since
the current savestate stores it as a string.
This value gets set at the same time that the string playtime gets set.
Custom deleters of ScopedPtr are not currently fully conforming to
C++11's support for custom deleters in std::unique_ptr for the
sake of simplicity of implementation. Unlike in the standard
library, plain functions and lvalue references are not supported,
nor may custom deleters be passed to the constructor at runtime.
This can be improved in the future, if necessary, by doing what
standard library implementations usually do and creating a Pair
class that uses the Empty Base Optimization idiom to avoid extra
storage overhead of the deleter instance when it is not needed, as
in typical standard library implementations, plus some additional
type traits to support the necessary metaprogramming for the
different type overloads.
Now SaveStateDescriptor no longer subclasses HashMap. Instead all possible
saved meta data is included directly into SaveStateDescriptor.
This is slightly less flexible, but we never needed that flexibility so far.
On the other hand it should reduce the memory usage. At least on my system
(Linux/amd64) the old SaveStateDescriptor had a size of 928 and the new
SaveStateDescriptor has a size of 200.
