03265: Games with wrong CRCs don't load at all using MAME's minimal UI

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03265	Interface	Minor	Always	Jun 15, 2009, 20:50	Jul 20, 2017, 03:49

Tester	Heihachi_73	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	No change required	OS	Windows XP/Vista/7 32-bit
Status [?]	Closed			Driver
Version	0.132	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	03265: Games with wrong CRCs don't load at all using MAME's minimal UI
Description	Any game which fails loading by CRC, also fails when attempting to run from MAME's internal menu. The 'bad' games still run from the command line as normal. Came across this initially when testing out a new aristmk4.c game by simply swapping the ROMs instead of going through downloading the source, adding it and recompiling. Game booted perfectly and went into its error mode (as with eforest), but didn't even attempt to load at all through the interface. This is most likely related to Bug 03264, as the 'missing ROM' message comes up in the same manner, even though ROMs are physically there (file names match).
Steps To Reproduce	Hack a game, run it perfectly in MAME from cmd, then watch it fail when you try to load it in MAME's menu instead, even though it's still running right behind the menu!
Additional Information	Tekken 2 screenshot as proof (using pre-122u2 wave ROM which fails audit).
Github Commit

Flags
Regression Version
Affected Sets / Systems

Attached Files	t2fail.png (81,461 bytes) Jun 15, 2009, 20:50

No.04513 Haze Senior Tester Jun 15, 2009, 22:11	I'm pretty sure this is by design. It's meant to be a simple frontend, if anything is wrong / missing it won't work.
No.04514 Tafoid Administrator Jun 15, 2009, 22:24	I agree. Nevertheless, I'll leave it for Aaron to give an official + or - on this.
No.13994 cuavas Administrator Jul 20, 2017, 03:49	Yeah, I think this can be closed as being by design. There are a couple of of aspects to consider. Firstly, on the design side, allowing the system to run with bad ROM images is liable to cause bad behaviour leading to false bug reports. Thus, running with bad ROM images is considered an "advanced" operation, requiring the user to use the command line. This makes running with bad ROMs less of a "casual" operation. Secondly, the internal UI relies on the audit class to check the status of a ROM. There isn't a huge amount of detain provided back in the result. The internal UI code just checks whether the result is "good" or "best available" and launches the system if it is. Changing the audit class API to distinguish between "missing files", "files present but bad checksum", "files present but wrong size", etc. would complicate all uses of it.