I have an example of a type of set (parent/clone) in which CLRMAME might not be acting as intended. The combination I'm looking at are the sets SCI and SCIJ. There is a certain file which share CRC/MD5 - but have different filenames.

In SCI, there is a file named: c09-14.42, which is needed also by SCIJ, but with a different filename: c09-10.42.
Unless I have a mis-checked or an unchecked setting - CLRMAME is putting a copy of this file into the SCIJ.zip rather than letting me use the parent SCI.zip which contains the correct rom (though, again, it's named differently). This is using Split Set format, not a Merged Set.

Normal behaviour. Different names for identical roms are pretty common. clrmamepro's default mode is 'different names within a parent/clone relationship = different roms', so you got the file in the parent and in the clone set.

You can enable profiler->options->parse rom merge tags to enable the lazy mode which will eliminate your second rom.


Roman Scherzer

> Normal behaviour. Different names for identical roms are pretty common.
> clrmamepro's default mode is 'different names within a parent/clone relationship
> = different roms', so you got the file in the parent and in the clone set.
>
> You can enable profiler->options->parse rom merge tags to enable the lazy mode
> which will eliminate your second rom.
>
>
> Roman Scherzer
>

Sure enough, checking this option fixed this and many other unneeded duplicate roms (a total of 330 sets on my end). Thank you.

well...it's a matter of taste here. Most people (incl. myself ;)) like the stricter rule to keep differently named files within a parent/clone relationship even if they are byte-identical. The specified 'merge' tags in the datfile were also too often too wrong in the past, so this 'parse merge tags' option is disabled by default. Anyway...in times of terabyte hds the little amount of gained diskspace is nearly not countable...


Roman Scherzer