Opened 20 years ago
Closed 20 years ago
#1965 closed defect (fixed)
MONKEY: French CD version incorrectly identified as monkey1
| Reported by: | SF/jellby | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 1 |
Description
I have a Monkey Island CD which includes versions in several languages. When I add the French version with the GUI, it is identified as "monkey1, alt version", even though the files are named MONKEY.000 and MONKEY.001. If I try to start it, it complains with:
WARNING: md5_file couldn't open 'monkey1.000'! Unknown MD5 (1000000068cf980888ebffbf71a82d40)! Please report the details (language, platform, etc.) of this game to the ScummVM team
...but changing the gameid to "monkey" works fine.
ScummVM 0.8.0CVS (Mar 19 2005 22:12:02) Features compiled in: Vorbis FLAC MP3 ALSA zLib MPEG2
Ticket imported from: #1167146. Ticket imported from: bugs/1965.
Change History (5)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
| Summary: | French CD version incorrectly identified as monkey1 → MONKEY: French CD version incorrectly identified as monkey1 |
|---|
comment:3 by , 20 years ago
A warning in the md5tool would be a good idea in any case.
For the future, we want to get completly rid of the monkey/monkey1 distinction anyway, which will solve this problem automatically.
comment:4 by , 20 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:5 by , 20 years ago
I added monkey / monkey1 to the substResFileNameTable, it should work fine either way now. At least it does in my tests.
This one is very similar to 1009344, except that it's the other way around. We have the same md5 for 2 different targets. In the case of BR1009344, bsearch was returning the md5 for the 'monkey' target, it seems like on jellby system, bsearch now returns the md5 for 'monkey1'. Don't know what is the best solution (there are no guaranties about the returned value of bsearch in case of 'equal' elements, right ?)... Maybe add another workaround (the other way around) like you did, fingolfin, for the previous bug report ? Or turn the bsearch call into a simple, less efficient, linear loop in which we check the target is the expected one ?
Besides, if we add another workaround, what about modifying the md5table tool to emit a warning if there are duplicates md5s (it would prevent future bugs/problems like this) ?