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>
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.
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.
This eliminates nasty limitation of caping number of flags to 31.
Current code has limitation of 255 flags, though.
Only SCUMM engine is converted, rest do not even compile.
Detection of fan talkie MI is broken as it has to be implemented
differently.
ADGF_UNSTABLE is always warned about.
ADGF_TESTING is only warned about when running
configure with --enable-relase.
Both warnings are subject to the enable_wip_game_warning
config option.
This includes a renaming of ADObsoleteGameID to Engine::ObsoleteGameID,
and AdvancedDetector::findGameID now is Engines::findGameID.
Doxygen comments were added or improved
The eventual goal here is to make it easier (well, *possible*) for
subclasses to modify the detector behavior, e.g. to implement
custom fallback detection.
One immediate goal could be to move the filebased fallback detector
into a subclass.
It doesn't seem very useful to keep this around for future uses,
either, at least I couldn't think of a convincing argument.
If we really need something like this one day again, it is trivial
enough to add it back.
