[Scummvm-devel] MD5 errors -- "unsupported" game versions
max at quendi.de
Mon Nov 14 09:10:01 CET 2005
Am 14.11.2005 um 17:39 schrieb Eugene Sandulenko:
> The real solution here would be one of these:
> o Detect FM-TOWNS games (which are most frequent target here)
> o Offer user a set of games to choose from
> o Watch those translations and update MD5s accordingly, possibly
> keeping MD5s for every variant they release.
> First one is difficult to implement I'd say.
Yeah, it's non-trivial, and I think there exists no perfect solution
for this problem. However, we *could* add a heuristic which should
work in most cases. In fact I already sketched some ideas for this in
Engine_SCUMM_detectGames. The main problem is that I only have access
to the FM-TOWNS versions of Zak and Indy3, and to the FM-TOWNS demos.
If I could get hold of the index file of the FM-TOWNS versions of
FOA, Monkey, Monkey2 (i.e. the *.000 files) I might be able to figure
out a heuristic to distinguish those from the PC versions, too (or
not -- no idea). Same goes for the Mac/Amiga versions, I guess.
The third approach is problematic. It would be quite a lot of work
for us to keep track of those fan made patches. I think it would be
better if we restrict our MD5 database to official game versions only
whenever possible, and try to cover fan made translations by trying
to auto-detect the games anyway, or if that fails, by pointing users
So I guess combining 1 and 2 is the way to go....
One further idea: We could offer a way for 3rd party translators to
"tag" their work. One way would be to ask patches to add a special
byte sequence to the end of the modified 00.LFL/*.000 files, which
marks the file as modified and contains hints for ScummVM indicating
the target / platform, or the original MD5. Or alternatively,
detecing a special "game_id.txt" file in the game directory and
reading target / platform / target_md5 from there... This approach
only works if those translators make their patches with ScummVM in
More information about the Scummvm-devel