[Scummvm-devel] singleid/gameid etc

A. Milburn fuzzie at users.sourceforge.net
Wed Feb 29 14:52:10 CET 2012


Hi,

I must admit to some surprise that _singleid, which I thought was clearly a
temporary workaround in the Advanced Detector, is apparently not thought to be
temporary or a workaround, but rather a feature without problems.

A short summary of _singleid, as I understand it, is that it is used by the
Advanced Detector to replace the gameid with an 'engineid' (unique to one
engine) before storing the game settings to file, thus removing the
potential for dangerous conflicts between internal engine gameids. However,
it obviously also removes the gameid information from the config file.

(Note that after the detection has *already run*, such as when games are
starting up, or when game-specific options, this is NOT a problem, since the
game descriptor for the individual game is available to the code, including
the real gameid. So it should not be a technical problem for such cases.)

However, surely a more sensible approach here would be to simply have an
engineid stored in the configuration file, alongside an engine-specific
gameid.

This could be set by all our engines (so making non-AD or non-singleid work
consistently with the singleid engines), could be easily migrated to (since
we would simply have to store the new engineid/gameid after detection when
no engineid was present), avoids problems with multiple games in a single
directory and limits confusion.

(Note that there is a workaround available for the 'multiple games' case,
namely kADFlagUseExtraAsHint which uses the 'extra' field to distinguish
between ambigious matches during detection, but it is not particularly
elegant and leads to the use to need things like ADGF_USEEXTRAASTITLE
in some cases too, which seems rather spectacularly overcomplicated.)

This would simplify the situation for plugin caching, for example (since we
would have a single 'engineid' to find a plugin for). And it would avoid
any confusion in the future.

Thoughts?

- fuzzie




More information about the Scummvm-devel mailing list