Games consisting of multiple files

[vadosnaprimer]

#2336 is related to this, but I think the actual problem is a bit bigger. See also #245.

PlayStation

Some PSX games come as one .cue and several .bin files. We never seem to record which files they consist of, and there's no way currently to report their individual hashes to the user. .cue file stores filenames, but still no hashes. And if we want to check those files against some DB like redump, we need individual hashes as well.

• Cost for hash calculation on the hawk side used to be too high, but recently it got greatly reduced, at least for some (most?) cases by #3348.

Saturn

Saturn games also come on at least 2 files (cue/bin), and even if we DiscoHawk games that have more, the result is still at least 3 files. While the converted output may not be present in DBs, as long as it's trivial to manually reconvert, it's also to easy to manually check hashes. But we just don't store per-file hashes in movies! To check if your file matches you have to run it through the movie code to see if hawk thinks it matches.

Arcade

Arcade games come in .zip packages, even though MAME can also work with .7z and even with unpacked folders, as long as it's named properly. And by properly, I mean MAME deduces which hardware to emulate from how your ROM package is named, and it uses package names to determine the game version too.

• Double Dragon 3 - The Rosetta Stone (US)'s ROM package name is ddragon3, and its (Japan) version is named ddragon3j, but it only contains version-specific files, and to run that version you need both ddragon3 and ddragon3j near each other (or ddragon3j folder inside the base package).
• Internally, MAME does calculate both CRC32 and SHA1 hashes for every single file that the ROM package consists of, but doesn't check every game against every other game, so it does require you to tell it which game/version you want it to run.
• The fact that MAME ROM packages don't have a unique file extension, makes it impossible for hawk to neatly deduce the system to run such a game on. When I met this problem for the first time, I was advised to add an entry to Advanced Loader, tho @adelikat disagreed that it's a good enough solution for the core to be released.
• • When discussing this with @CasualPokePlayer we came to conclusion that we'll have to ask users to rename ROM .zips into something like .mame, so we could use the traditional core loader. But that doesn't resolve individual file hashing, and hashing the whole package will not cut it because MAME's versioning of ROM packages is a complete unreliable mess.

DOS

Then there's a question of DOS games, which can come as disk images (often multiple as well), or as folders containing a bunch of tiles, and you can't deduce the system from looking at them.

Complications

Finally, in some cases it's desired to run completely unrelated images together, making the core think it's all the same meta-game.

• PSX Monster Rancher explicitly asks you for arbitrary disks to insert, and it will use them as RNG to generate monsters.
• Some games glitch in funny ways if you insert wrong disks at specific times. It may be banned by TASVideos movie rules, but some people out there will still be doing this, and even on TASVideos there's now a class that allows it.
• Some systems can run several games at once via some kind of a link interface, and each such game needs to be matched against the DB separately, and reported to the user separately.

Sugestion

• Use multidisk bundler for hashing all the individual files, report their hashes to the user in some way (in movie header, in xml itself, maybe include xml into movies).
• • This may involve creating separate GameInfo entries for some compound games, but then how to resolve multiple files belonging to the same game? Add a dictionary of filename/hash to GameInfo class?
• Use multidisk bundler to tell hawk which system it is regardless of file extension, if we have to. Sounds like a neat solution for Arcade. Also allows to not reassign preference through the Choose a Platform dialog every time it's a different system.
• Use multidisk bundler to import and hash an entire folder (or an archive), if a core can work with folders. Ideally implement drag'n'drop. Obviously it'd be the core port's job to intercept core's file editing and store edits separately as SaveRAM.
• Maybe use multidisk bundler to store extra info to send to the core, like which MAME game it is, without having to name the xml file after it. Not critical.