- Update AMEC's getFileProps (changes related to MacResMan)
- This commit also includes a change from other engines.
- Fallback detection here depends upon many Engine resources.
- As such, it might not be suitable to add all of them to executable.
- Thus, shift fallback detection to the dynamic part.
- The static part gets the relevant Engine plugin & then tries to call it.
- This way, fallback detection for Wintermute will depend on the engine plugin.
- Normal detection will still work fine.
- Add fallbackDetectExtern, meant to be overriden by child classes, if fallbackdetection heavily depends on Engine code.
- Add getFileProperties helper.
- End function names with "extern" to distinguish from normal.
- We have a default createInstance method overridden from MetaEngine from before in AME.
- So, just leave that as-is, and call the child class's function from there.
- Lastly, in AMEC - the generic createInstance is called, so we redirect it to call the one in the MetaEngine.
- Then, games can be run normally.
Common::MacResMan is now able to open files from a specified
Common::Archive. This is a bit hacky as dynamic_cast is used to break
the Archive encapsulation to retreive the underlying FSNode. It should
however be more correct than the previous code that assumed files were
at the root of the currently running game's path.
AdvancedDetector constructs a Common::Archive from its FileMap based
filesystem cache and uses it to detect the mac resource fork files.
This cuts the time it takes to run the detection code with all the
engines enabled as dynamic plugins on the 3DS to 30 s from 280 s.
Checking whether a file exists is costly on the 3DS. Remembering which
files do not exist instead of repeatedly checking for them reduces the
time it takes to detect games from ~1 minute to ~10 seconds in some
cases.
The engine ID identifies which engine should be used to launch the target.
Also remove the 'single ID' system. Different games from engines that used
that system now have different game IDs.
Also-By: Matthew Hoops <clone2727@gmail.com>
Hidden files are now only ignored in the GUI file browser when the user
has not checked 'show hidden files'.
Myst III has the hidden flag set for one of the directories containing
datafiles on the CD-ROM. When users copy the files to their hard drives
the hidden flag is kept. Detection worked previously because hidden
files were explicitly requested in the AD code. The engine would fail
to open the datafiles because SearchMan.addSubDirectoryMatching
ignored hidden directories.
This is a regression from 90b78c544657bf0fc41d6b86276a0873060345b5
This commit restores the previous behaviour and avoids a null
pointer dereference induced crash.
This fixes the root cause of bug Trac #10515.
Thanks to the great help of @criezy, here's my implementation of an GUI
dialog that appears when an unknown game is detected.
Features:
- Allows copying the data collected by game detector to the clipboard
- Allows opening the bug tracker and pre-filling the form fiels
This closes https://bugs.scummvm.org/ticket/10435.
When a user tries to add a game expecting it to be a particular
game for a particular engine, but a detector from another engine
happens to match some files that exist in the game directory and
reports on those files instead, this can cause a lot of confusion
because the detector doesn't say what engine or game it thought it
matched.
This patch adds the name of the matching engine as well as any
matching game IDs (if applicable) to the detector's logged output.
It also provides more specific guidance about where to send the
detection information (to the bug tracker), and properly wraps the
first part of the report to 80 columns.
Refs Trac#10272.
If an early file in the game's signature list has a hash/size
mismatch, it is still necessary to continue to check the rest of
the candidate files for existence, since the non-existence of
candidate files is supposed to disqualify a game description as
matching a game to an unknown variant.
By quitting the file check early, the detector had been allowing
descriptions to randomly match if there happened to be an early
file in the detection list with the right name but wrong hash/size,
even if some of the other signature files did not exist at all.
This allows an engine to match files that exist multiple times
in the same game directory with the same basename.
For example, different releases of Torin's Passage in SCI engine
come with zero or more GERMAN, FRENCH, ENGLISH, etc. directories,
all containing files with the same basenames but with different
contents per language. Because the allFiles map used only the
basename of a file as a key, it could not match more than one of
these localization directories, which made it impossible to select
from all the possible languages.
Refs Trac#9772.
