Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[edge33]

Hi, I managed to rebuild my complete 0.186 romset, from merged to non-merged using clramamepro, still, everytime I scan the romset i get errors of missing roms on those "evil" nown sets such as funkyfiga, lucky8a and royalcrdfr. I read on some topics that these errors are due to some clashes on the "merge" attribute, or some naming clash.
However this roms are working for me.... is there anyway to fix these scan errors?

[Roman]

I will check them....but why the heck unmerged sets??? ;-)

[edge33]

I will check them....but why the heck unmerged sets??? ;-)

I am trying to build my personal romset to be used in a home-made arcade cab. I want to exclude non-working games, casino, card, slots, and all the games that have no meaning in a home cabinet i.e lightgun games. To exclude these games, I am using MameShrink. This program allows you to select games you want to remove, based on some filters like category, number of players an so on... I thought having a merged set, didn't allow me to remove the sets I don't want, according to the fact that roms for different sets are all together in the parent set. Am I right? Or maybe I may proceed to use the program on the merged set?


Why would you advise against a non-merged set? space or what else?

[Roman]

due to bios and device relations you will never really have standalone sets...and yes...non merged are purely a waste of space....most of the files are doubled...ok in times of multi-terabyte hds not really a problem...but still....unusual storing method for mame collectors.


but I will double check the problem of course when I find a little time

[Roman]

yeah it seems to be a wrong behaviour...the rom merge entries in the dat are a bit tricky for these sets...but actually merge attributes shouldn't be checked in non-merged mode....guess there is one place where cmpro maps it wrong...will do further investigation

[edge33]

yeah it seems to be a wrong behaviour...the rom merge entries in the dat are a bit tricky for these sets...but actually merge attributes shouldn't be checked in non-merged mode....guess there is one place where cmpro maps it wrong...will do further investigation

thank you, I am following the issue

[Roman]

oh yeah...what a bad one.....the cache file didn't hold the correct value for the flag which is responsible for the naming control.....so when you received the data for the first time it would act correctly, as soon as you quit/restart cmpro and load the cached information it would act weird....
guess it was hidden for so long time because noone actually uses not-merged sets (;-) ...only in combination with the merge tag usage)...

So here is a new build

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20170910.rar

handle with care....the missing set flag was pretty obvious, though I'd like to do more testing to see possible sideeffects

...and yes...you may now run into a lot of "wrong named" roms messages since up to today it always used the "merge" information for naming in your unmerged case...which is wrong (well, in terms of auditing....merge information points to identical byte data...so not really an issue...just a different name).

[edge33]

oh yeah...what a bad one.....the cache file didn't hold the correct value for the flag which is responsible for the naming control.....so when you received the data for the first time it would act correctly, as soon as you quit/restart cmpro and load the cached information it would act weird....
guess it was hidden for so long time because noone actually uses not-merged sets (;-) ...only in combination with the merge tag usage)...

So here is a new build

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20170910.rar

handle with care....the missing set flag was pretty obvious, though I'd like to do more testing to see possible sideeffects

...and yes...you may now run into a lot of "wrong named" roms messages since up to today it always used the "merge" information for naming in your unmerged case...which is wrong (well, in terms of auditing....merge information points to identical byte data...so not really an issue...just a different name).

thank you so much