When Mame gives misleading information that two romsets should have different files with the same name within a parent/clone relationship the profiler gives the following warning:
Cloneset: 'x' uses equal names for different ROMs and so it can't be merged to its parentset: 'y'
Parent/clone relationship will be removed.

In all the cases I have checked then one of two files is a 'nodump', so there isn't a practical clash until the nodump version has been dumped.
To prevent the removal of parent/clone relationships I have removed all nodump roms from Mame's listxml output before loading it into the profiler.

Do you see any problematic side effects to this workaround?
Would you implement an option in clrmamepro to completely ignore nodump roms?

Thanks

> Would you implement an option in clrmamepro to completely ignore nodump roms?

By default nodumps are set to be 'unneeded' (obsolete). If you use a datfile, there is a datfile header tag specifying the nodump handling. It's either: required, obsolete or ignore.

Iirc the clashes are being detected on good dumps only.

If there's a clash between a nodump and a good one (e.g. clone got a good dump while the parent doesn't...yes...such things happen), then another check jumps in and prevents people from overwriting the good one. It then takes the good dump's hash/size information and makes the nodump a gooddump.



Roman Scherzer

I realize I was over simplifying when assuming that all the clashes were related to nodumps.
Verifying a 0.88 isn't exactly up to date

> Iirc the clashes are being detected on good dumps only.

Did my trick again and I am not convinced here
For 0.126 I get 40 clashes, but after my trick I only get 30!
So it seems to me that the following 10 are getting a clash on a nodump.

Cloneset: 'boobhack' uses equal names for different ROMs and so it can't be merged to its parentset: 'horekid'
Cloneset: 'catmousa' uses equal names for different ROMs and so it can't be merged to its parentset: 'catnmous'
Cloneset: 'hydrap2'  uses equal names for different ROMs and so it can't be merged to its parentset: 'hydra'
Cloneset: 'omega'    uses equal names for different ROMs and so it can't be merged to its parentset: 'theend'
Cloneset: 'saiyugb1' uses equal names for different ROMs and so it can't be merged to its parentset: 'chinagat'
Cloneset: 'saiyugb2' uses equal names for different ROMs and so it can't be merged to its parentset: 'chinagat'
Cloneset: 'tenkai2b' uses equal names for different ROMs and so it can't be merged to its parentset: 'tenkai'
Cloneset: 'tenkaid'  uses equal names for different ROMs and so it can't be merged to its parentset: 'tenkai'
Cloneset: 'tenkaie'  uses equal names for different ROMs and so it can't be merged to its parentset: 'tenkai'
Cloneset: 'tmekprot' uses equal names for different ROMs and so it can't be merged to its parentset: 'tmek'

With omega/theend you have a simple example of a good rom in parent and a nodump with the same name in clone.
For boobhack/horekid it's actually the case that boobhack is said to use 2 files with the same name, one is good and the other is nodump!

well...did some more source review and I can add some lines to filter the nodump clashes. However I've already spotted an issue when fully merging the not-removed-parent/clone relationship sets, so I most likely enable the nodump-overwrite-with-good-checksum for all nodumps (independently from the given nodump mode). So after this adjustment you will get prompts for nodump overwrites but no more for parent/clone clashs (at least not for the nodump sets). It's the cleaner solution imo.

so in detail this means the following:

If a nodump is found during the parser cleanup phase, cmpro checks:
- does a good dump for this exists within the current parent/clone relationship
- if yes, mark the nodump as gooddump, take size, crc32/sha1/md5 values from the found good one

This functionality is in since years, however with one of the last nodump updates it was partly disabled.

Optionally a prompt may appear asking the user if he actually agrees to this replacement.

If the nodump gets fixed, you won't see a 'can't merge x to y due to equal names/different hash' prompt for the set in question. If the user doesn't agree to the nodump fix, it will appear.



Roman Scherzer

This seems like a very good solution to me.
Thanks for your dedication in developing and improving clrmamepro.