#2465 closed defect (fixed)
SCUMM: MD5 based game target system broken
| Reported by: | fingolfin | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | high | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
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 MD5.
Far worse is the latest problem I just encountered. Consider this config entry:
[tentacle] description=Day Of The Tentacle (English) gameid=tentacle path=/path/to/my/data/
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 name.
Ticket imported from: #1405794. Ticket imported from: bugs/2465.
Change History (11)
comment:1 by , 18 years ago
comment:2 by , 18 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 , 18 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 , 18 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 first.
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 names.
I think. I could very well be wrong.
comment:5 by , 18 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.
Regards Joachim
comment:6 by , 18 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 that.
comment:8 by , 18 years ago
| Owner: | set to |
|---|
comment:9 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:10 by , 18 years ago
The new detection code finally is in SVN, and fixes the issue reported here, and more.
comment:11 by , 5 years ago
| Component: | --Unset-- → Engine: SCUMM |
|---|
Err, Maniac Mansion is definitely not in the same directory as DOTT, not even in the extracted Mac version.....