Opened 14 years ago

Closed 14 years ago

Last modified 13 months ago

#2465 closed defect (fixed)

SCUMM: MD5 based game target system broken

Reported by: fingolfin Owned by: fingolfin
Priority: high Component: Engine: SCUMM
Keywords: Cc:


Some time ago, lots of targets in the SCUMM engine were removed, in
favor of a more MD5 based "automatic" detection of games.

This is broken in various ways as I described in the past; in particular, we
do not properly support games anymore, for which we do not know the

Far worse is the latest problem I just encountered. Consider this config

description=Day Of The Tentacle (English)

Now, when running
./scummvm tentacle

of course -- Maniac Mansion starts! Why? Because it's shipped along with
DOTT in the same directory. Apparently, the new code totaly ignores the
fact that a specific gameid was given. Bad! In fact it should still start
DOTT even if no explicit gameid was given, because that is the target

Ticket imported from: #1405794. Ticket imported from: bugs/2465.

Change History (11)

comment:1 by SF/joachimeberhard, 14 years ago

Err, Maniac Mansion is definitely not in the same
directory as DOTT, not even in the extracted Mac

comment:2 by sev-, 14 years ago

Exactly. Usually it sits in maniac/ subdirectory. I don't
think it's a good idea to put 2 games into same directory
anyway. I'd personally close this bugreport. Yes, there are
possible fixes as you described several times, but IMHO not
for this particular case.

comment:3 by fingolfin, 14 years ago

This is from an extracted Mac version of DOTT, and there are
no subdirectories in it!

Furthermore, this is still a bug. If a user points scummvm
at a directory and says "tentacle", then it should try to
run tentacle, or give up, but *not* run maniac or whatever
else it thinks it finds.

The alternative (which I don't like) is to completely remove
game ids. Fully rely on MD5 detection for everything. I.e.
let the user point ScummVM at a directory and it uses magic
to "do what I want" in that directory....

Frankly, to me, since we dropped targets in favor of
MD5-based detection, I have not yet experienced a single
benefit form it as a user, but instead several times now it
has caused me very annoying problems... not what I call
progress :-/. A reduced list of targets is nice from the
"tidieness" point of view, but IMO it shouldn't be bought by
breaking things that used to work just fine.

comment:4 by eriktorbjorn, 14 years ago

I'm not sure MD5 sums is the main problem here. It looks to
me as if if's the way Engine_SCUMM_create() looks for data
files. Even though we already have the ScummGameSettings
element for the selected target (i.e. we already *know*
exactly what kind of game we're trying to start), it will
try all of the following:

1) 00.LFL
2) 000.LFL
3) <name>.la0
4) <name>.he0
5) <name>.000
6) <name>.sm0
7) 00.MAN

in that order. That's why it finds the Maniac Mansion files

It's possible that we could simply re-order the tests to
look for the name-specific files first. But then we'd still
start Maniac Mansion if the DotT files are missing. Or we
could add a field to the ScummGameSettings struct to
indicate which methods we should use to create the data file

I think. I could very well be wrong.

comment:5 by SF/joachimeberhard, 14 years ago

There is a game detection related bug with the Jungle Mac
version, as the oldest HE Games show the Windows part of
the CD on the Mac part also.
That means, that when I copy everything in the Mac fork of
the CD to a folder on my harddisk, it contains the Windows
and the Mac version of the game.

Coosing and starting the Windows version in the mac folder
using the launcher results in the following error:

ERROR: (0:1:0x63): The Jungle: not a Windows library

All md5s match the Windows version, which works fine in a
seperate folder.


comment:6 by fingolfin, 14 years ago

erik, indeed, the MD5 is not directly at fault here -- and that's not what I
wanted to say -- but rather, the "new" system (which happens to be based on
MD5, but that's soley a way to describe it) is broken... the old system was
complicated by the fact that it tried to handle situations like this (which is
why it took me as long as it did to implement it originally -- and why I never
removed the 'duplicate' targets, even though I suggested that myself: Because
I didn't see a way of doing that w/o breaking things like this...). The new one
simply doesn't even consider this particular case... and just waving it away
with "you shouldn't do it" is IMO a bad excuse :-/.

Maybe if had some more design specs such problems wouldn't occur. I.e. if I
had written down why I did some things the way I did them, etc., then the
people working on the "new" system possibly would have conidered them,
too. Well, and if they had tried to write one, this may have surfaced, too :-).

But anyway, it's not my intention to blame anybody for anything here (neither
myself, nor sev, nor anybody else), it's just that I am annoyed by brokeness
that's been around for many months now. If nobody else does it, I'll like go
around and rewrite the detector myself at some point, but I wanted to avoid

comment:7 by fingolfin, 14 years ago

See also: <>

comment:8 by fingolfin, 14 years ago

Owner: set to fingolfin

comment:9 by fingolfin, 14 years ago

Resolution: fixed
Status: newclosed

comment:10 by fingolfin, 14 years ago

The new detection code finally is in SVN, and fixes the issue reported here, and

comment:11 by digitall, 13 months ago

Component: --Unset--Engine: SCUMM
Note: See TracTickets for help on using tickets.