3.84b

misc: merge tag validate test is only performed when 'parse merge tag' option is used and when the dat actually has merge tags
misc: merge tag validate test works on parents (with possible merge tag pointing to biosfiles) and clones (with possible merge tag pointint to biosfiles and parent romfiles)
fixed: merge tag validate test doesn't work correctly
fixed: 'No to all' does not work on 'wrong named resource roms'



Roman Scherzer

> 3.84b
>

Something doesn't seem right. ClrMamePro 3.84a and MAME .104u3 reported I had a completely accurate and merged ROM set. All I did was update to ClrMamePro 3.84b and all of a sudden ClrMamePro 3.84b thinks some clones are parent games that I don't have. For example, herodk and herodku are clones of hero. I have hero and herodk and herodku are merged into hero.zip. ClrMamePro is set to "Merged Sets" and reports herodk and herodku are missing sets which is incorrect.

This is also happening with hunchbak. All of hunchbak's clones are also not recognized as clones which includes hunchbkd, hunchbkg, and hunchbks.

Also happening with huncholy. All of huncholy's clones are also not recognized as clones which includes hncholms and herbiedk.

Might be more...that's just what I can report now.

> 3.84b
>

sbdk which is a clone of superbik is also reported as a missing set even though it is merged into superbik.

I should have explained it better before. Basically all of these clones are reported as "missing sets" even though they do exist and are merged into their parent. ClrMamePro is set to use "Merged Sets".

Could be caused by several stuff....

1)
These are sets with merging-between-systems. They always existed but I might have changed the default answer for it when adding the new yes/no/yestoall windows. You were always able to set the value which you prefer when you kept 'datfile errors' -> show all. You can also set 'Pro_ForbidSystemMerging' to on/off in cmpro.ini to select the default value.

2) if you enabled the usage of merge tags (parse merge tags) it could be a normal behaviour. I told the people before...merge tags in MAME are unreliable 8)

Although nothing of that actually changed from 384a to 384b. I guess it's 1) and you haven't cleaned the cache from 384 to 384a, so the data wasn't newly received, so it still used the old setting for that.

What you currently can do: Add the upper mentioned ini line to cmpro.ini (set it to "off" I guess), clean the cache and reget the data from a mame executable.



Roman Scherzer

just looked at a clean install

merging between systems (in case of hunchbak it's standard with cvs) is NOT ALLOWED.

Looks like I really switched the defaults, since in 383c it the default value was ALLOWED....

Guess I will change that back as soon as I'm back home and release an update.



Roman Scherzer

ok...I now know what happened ;)

The default value for "Forbid merging between systems" was always set to "on", meaning merging between the hunchback sets was illegal and cmpro removed the parent/clone relationships.

But: in versions before 3.84a, cmpro skipped that check (and so the parent/clone relationship cleansing) if you haven't selected 'datfile errors->show all'.

So in fact it was broken before and works correctly now ;)
I will add an option to the profiler options to allow/forbid merging between systems anyway to make it more clearer.


Roman Scherzer