201
clrmame Discussion / Re: clrmamepro 4.046 released
« on: 15 August 2022, 16:55 »
ok..gimme a second....the fix-missing (which is causing the trouble) seems to have a problem when creating the new subs...
- 26 April 2024, 12:17
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
202
clrmame Discussion / Re: clrmamepro 4.046 released
« on: 15 August 2022, 16:07 »
It does not want to move chd files.
It simply does not find them since you store them not correctly (for the hash collision mode). And then "fix missing" thinks it needs to do its work, detects the missing one and tries to add them. And since chds belong to a rompath, it tries to put them where it finds they fit best and that's most likely the place where your roms are stored (separating chds from their sets is..erm...well...your taste).
So...fix-missing is the problem for you....missing check detects a missing chd, fix missing finds it somewhere and adds it (it never moved files).
So turn it fix missing off...of course this fixes your storage pattern. This can then be done either manually or you can use the standalone rebuilder on your chd folder to rebuild the files in full merge mode to a new folder....(if this is on the same hd, this can take a while...)
It simply does not find them since you store them not correctly (for the hash collision mode). And then "fix missing" thinks it needs to do its work, detects the missing one and tries to add them. And since chds belong to a rompath, it tries to put them where it finds they fit best and that's most likely the place where your roms are stored (separating chds from their sets is..erm...well...your taste).
So...fix-missing is the problem for you....missing check detects a missing chd, fix missing finds it somewhere and adds it (it never moved files).
So turn it fix missing off...of course this fixes your storage pattern. This can then be done either manually or you can use the standalone rebuilder on your chd folder to rebuild the files in full merge mode to a new folder....(if this is on the same hd, this can take a while...)
203
clrmame Discussion / Re: clrmamepro 4.046 released
« on: 15 August 2022, 15:26 »
There is nothing wrong.
You're using not using the normal full merge mode but the "hash collision mode" one, i.e. all clone files are in subfolders of the parent.
In the past this was only done for roms (so you got subfolders in your zipfiles) while disks were simply forgotten. This has changed now and disks follow the same pattern.
So to answer your first post "this build separate Mame CHDs ( full merge mode) in subfolders" -> yes, it's intended.
Regarding your second post "cmpro wanna move mame chds to roms folder" -> no, it tried to fix a missing one and fix missing tries to add it to a suitable place. A suitable place is a rompath since chds are stored in rompaths. The problem arises since your current storage pattern for disks does not match the "hash collision mode". So you may need to manually adjust the paths a bit or turn off fix-missing or maybe changing the order of the rompaths (the one with chds at first) may help.
So in your example, the correct storing pattern would be: your_rompath\aa3010\aa3020\riscos311_apps.chd
You're using not using the normal full merge mode but the "hash collision mode" one, i.e. all clone files are in subfolders of the parent.
In the past this was only done for roms (so you got subfolders in your zipfiles) while disks were simply forgotten. This has changed now and disks follow the same pattern.
So to answer your first post "this build separate Mame CHDs ( full merge mode) in subfolders" -> yes, it's intended.
Regarding your second post "cmpro wanna move mame chds to roms folder" -> no, it tried to fix a missing one and fix missing tries to add it to a suitable place. A suitable place is a rompath since chds are stored in rompaths. The problem arises since your current storage pattern for disks does not match the "hash collision mode". So you may need to manually adjust the paths a bit or turn off fix-missing or maybe changing the order of the rompaths (the one with chds at first) may help.
So in your example, the correct storing pattern would be: your_rompath\aa3010\aa3020\riscos311_apps.chd
204
clrmame Discussion / Re: clrmamepro 4.046 released
« on: 15 August 2022, 04:50 »
Yes but that's intended for an enabled Settings->Full Merge Mode -> Hash Collision Name
205
clrmame Discussion / clrmamepro 4.046 released
« on: 14 August 2022, 16:48 »
4.046
fixed: support for other sample extensions is broken
fixed: more compatibility for standalone rebuilder tool in handling disk names in full merged mode (hash collision mode)
fixed: more compatibility for standalone rebuilder tool in handling of devices with romof attributes in full merged mode
misc: updated 7zip sdk/dll tp 2201
fixed: support for other sample extensions is broken
fixed: more compatibility for standalone rebuilder tool in handling disk names in full merged mode (hash collision mode)
fixed: more compatibility for standalone rebuilder tool in handling of devices with romof attributes in full merged mode
misc: updated 7zip sdk/dll tp 2201
206
clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 12 August 2022, 06:31 »
hmm...interesting...however I don't think it was your setup....must be some old weird random bug somewhere.....hard to say as long as I can't repeat it myself.....I still got your cmp files so I will do some more testing I guess.....but good to see it's back working for you
207
clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 09 August 2022, 16:21 »
Thanks for the files...unfortunately I cannot repeat your problem at all yet, I will however do some more tests.
Just for a test, untick the addpath or try to setup a new profile from scratch.
Since you only have 1 rompath, you can also disable the use of system default paths (System->unbind all)
Just for a test, untick the addpath or try to setup a new profile from scratch.
Since you only have 1 rompath, you can also disable the use of system default paths (System->unbind all)
208
clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 09 August 2022, 08:38 »
can you send me:
cmpro.ini and the .cmp file from cmpro's settings folder which belongs to your profile. I assume you've imported the data directly from a MAME binary (if not, also add the used datfile). And I assume that you're not importing softwarelists
cmpro.ini and the .cmp file from cmpro's settings folder which belongs to your profile. I assume you've imported the data directly from a MAME binary (if not, also add the used datfile). And I assume that you're not importing softwarelists
209
clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 07 August 2022, 11:05 »
arb (the parent) itself does not have any roms on its own.
It only consists of device_refs. The clone (arbv2) has exactly 1 rom "sargon_4.0".
So all you need is a zip file, named arb.zip which holds that one rom (name="sargon_4.0" size="65536" crc="c519c9e8" sha1="d7597d50c0f4f9aa6d990c8d3b485e39cb44ff06").
If you still get a message about a misplaced set, you may want to check if you got an arbv2 or arb folder in one of your rompaths or your equally named zipfiles somewhere. You can also try to clean the profiler cache and reget the data from an official mame binary. And then do a new full scan.
What makes me wonder is that you always mention an uppercase ARB, while in MAME it's definetly lowercase...or maybe you just use uppercase yourself here...
It only consists of device_refs. The clone (arbv2) has exactly 1 rom "sargon_4.0".
So all you need is a zip file, named arb.zip which holds that one rom (name="sargon_4.0" size="65536" crc="c519c9e8" sha1="d7597d50c0f4f9aa6d990c8d3b485e39cb44ff06").
If you still get a message about a misplaced set, you may want to check if you got an arbv2 or arb folder in one of your rompaths or your equally named zipfiles somewhere. You can also try to clean the profiler cache and reget the data from an official mame binary. And then do a new full scan.
What makes me wonder is that you always mention an uppercase ARB, while in MAME it's definetly lowercase...or maybe you just use uppercase yourself here...
210
clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 03 August 2022, 11:00 »
I can check it next weekend.
211
clrmame Discussion / Re: Rebuilder 0.01 released
« on: 22 July 2022, 15:08 »
A bios assignment is done by tracking romof attributes.
So normally you got 2020bbh romof 2020bb and 2020bb romof neogeo. So you know that 2020bbh is connected to the neogeo bios set.
Now you removed 2020bb and you keep only 2020bbh....and if you look at the following roms in that set, how do you decide if this belongs to the removed parent 2020bb or to the missing link to the bios?
<rom name="sfix.sfix" merge="sfix.sfix" size="131072" crc="c2ea0cfd" sha1="fd4a618cdcdbf849374f0a50dd8efe9dbab706c3" region="fixedbios" offset="0"/>
<rom name="000-lo.lo" merge="000-lo.lo" size="131072" crc="5a86cff2" sha1="5992277debadeb64d1c1c64b0a92d9293eaf7e4a" region="spritegen:zoomy" offset="0"/>
<rom name="sm1.sm1" merge="sm1.sm1" size="131072" crc="94416d67" sha1="42f9d7ddd6c0931fd64226a60dc73602b2819dcf" region="audiobios" offset="0"/>
Well, you'd say: I can simply lookup the sha1 in all roms and see that it belongs to the neogeo set......but I'd like to prevent such "guessing"
So the story is: If you have a bad cloneOf assignement: what to do? In Rebuilder 0.01 your problem is that the parser warns you and the definition stays untouched, i.e. all "merge" attributes stay as they are you so in the end you don't get your 2020bb files.
"Fixing" this bad cloneOf would mean to clear it and clean the merge attributes...cleaning them all would also clean the ones belonging to the bios....so you would end up with a set which got all bios roms included....you don't want that since you got neogeo bios in the dat listed....cleaning the merge attributes for the ones which don't have a bios attribute would work fine...but the upper 3 don't have one...and so they are included....
or I don't care at all since it's a corruption in the dat, so garbage in -> garbage out.....
So normally you got 2020bbh romof 2020bb and 2020bb romof neogeo. So you know that 2020bbh is connected to the neogeo bios set.
Now you removed 2020bb and you keep only 2020bbh....and if you look at the following roms in that set, how do you decide if this belongs to the removed parent 2020bb or to the missing link to the bios?
<rom name="sfix.sfix" merge="sfix.sfix" size="131072" crc="c2ea0cfd" sha1="fd4a618cdcdbf849374f0a50dd8efe9dbab706c3" region="fixedbios" offset="0"/>
<rom name="000-lo.lo" merge="000-lo.lo" size="131072" crc="5a86cff2" sha1="5992277debadeb64d1c1c64b0a92d9293eaf7e4a" region="spritegen:zoomy" offset="0"/>
<rom name="sm1.sm1" merge="sm1.sm1" size="131072" crc="94416d67" sha1="42f9d7ddd6c0931fd64226a60dc73602b2819dcf" region="audiobios" offset="0"/>
Well, you'd say: I can simply lookup the sha1 in all roms and see that it belongs to the neogeo set......but I'd like to prevent such "guessing"
So the story is: If you have a bad cloneOf assignement: what to do? In Rebuilder 0.01 your problem is that the parser warns you and the definition stays untouched, i.e. all "merge" attributes stay as they are you so in the end you don't get your 2020bb files.
"Fixing" this bad cloneOf would mean to clear it and clean the merge attributes...cleaning them all would also clean the ones belonging to the bios....so you would end up with a set which got all bios roms included....you don't want that since you got neogeo bios in the dat listed....cleaning the merge attributes for the ones which don't have a bios attribute would work fine...but the upper 3 don't have one...and so they are included....
or I don't care at all since it's a corruption in the dat, so garbage in -> garbage out.....
212
clrmame Discussion / Re: Rebuilder 0.01 released
« on: 22 July 2022, 13:43 »
Well ok while it is easy to "fix" the bad "cloneof" attribute information from 2020bbh by clearing it and clearing the obsolete "merge" attribute information from its roms (since it's not a clone anymore), it however brings up some issue:
What about the merge information which is connected to bios roms. Since you've included neogeo in your dat, they should somehow stay. Removing the merge for them, too, would include them in your rebuilt 2020bbh set.
However since 2020bbh's "romof" information is also bad you can't track the bios machine (since it is lost by removing the parent which had the romof="neogeo").
Then you would say: ok...only remove the merge information from the roms which don't have a "bios" attribute...fine...most will be ok then but that would still include sfix.sfix, 000-lo.lo and sm1.sm1 in the set since they for whatever reason don't have a bios attribute.
Need to find a sutiable way for this...don't really like the way to check the single roms against possible available bios roms....but most likely that would be the only way to fix a bad romof attribute and reconstruct a bios assignment.
Anyhow....this is only for dats which do have bad structures.....pretty special to start with :-) ...will look at it again after summer holidays.
What about the merge information which is connected to bios roms. Since you've included neogeo in your dat, they should somehow stay. Removing the merge for them, too, would include them in your rebuilt 2020bbh set.
However since 2020bbh's "romof" information is also bad you can't track the bios machine (since it is lost by removing the parent which had the romof="neogeo").
Then you would say: ok...only remove the merge information from the roms which don't have a "bios" attribute...fine...most will be ok then but that would still include sfix.sfix, 000-lo.lo and sm1.sm1 in the set since they for whatever reason don't have a bios attribute.
Need to find a sutiable way for this...don't really like the way to check the single roms against possible available bios roms....but most likely that would be the only way to fix a bad romof attribute and reconstruct a bios assignment.
Anyhow....this is only for dats which do have bad structures.....pretty special to start with :-) ...will look at it again after summer holidays.
213
clrmame Discussion / Re: Rebuilder 0.01 released
« on: 21 July 2022, 10:43 »
Ah.... wait....Now I think I see what you mean.....you miss the parent roms...well..of course you do because your dat does not include the parent.
So...ok....I think if a "ridheroh has bad cloneof reference: ridhero -> no parent assigned" message appears, the single roms inside it should get their merge attribute removed since there is no more relationship....I will see what I can do....
So...ok....I think if a "ridheroh has bad cloneof reference: ridhero -> no parent assigned" message appears, the single roms inside it should get their merge attribute removed since there is no more relationship....I will see what I can do....
214
clrmame Discussion / Re: Rebuilder 0.01 released
« on: 21 July 2022, 09:52 »
what is a "main set" ? Give a concrete example what you are missing in which set.
215
clrmame Discussion / Re: Question on filtering sets
« on: 21 July 2022, 06:16 »
erm....I don't really understand what you actually want to achieve in the end.
Question 1: is there really a need to limit sets. I always ask this because users tend to answer "I don't like 1000 sets shown as missing". Well, there is a scanner context menu option to simply "hide fully missing sets". Limiting sets is possible but usually not needed at all.
Question 2: if you simply want to limit your sets to "what I currently got", the "avail sets" button in set information is a helper. However it simply scans your rompaths for valid setnames and enables them (...and parent/clones/bios if the checkboxes are ticked). However, this would mean that your sets already have a correct name...after updating your sets, you may go back to that button and hit it again...(sounds easier than your textfile workarounds).....So back to #1 ....usually it's better to keep all sets enabled anyhow....and hide totally missing ones if they really annoy you...but on the other hand....you want to collect them all, don't you?....if not, you can simply modify the datfile to only list what you want.
Question 1: is there really a need to limit sets. I always ask this because users tend to answer "I don't like 1000 sets shown as missing". Well, there is a scanner context menu option to simply "hide fully missing sets". Limiting sets is possible but usually not needed at all.
Question 2: if you simply want to limit your sets to "what I currently got", the "avail sets" button in set information is a helper. However it simply scans your rompaths for valid setnames and enables them (...and parent/clones/bios if the checkboxes are ticked). However, this would mean that your sets already have a correct name...after updating your sets, you may go back to that button and hit it again...(sounds easier than your textfile workarounds).....So back to #1 ....usually it's better to keep all sets enabled anyhow....and hide totally missing ones if they really annoy you...but on the other hand....you want to collect them all, don't you?....if not, you can simply modify the datfile to only list what you want.
216
clrmame Discussion / Re: Rebuilder 0.01 released
« on: 21 July 2022, 06:10 »
"The rebuilder can't put the pieces of main roms into the clones. But the clrmamepro doesn't have that problem."
erm.....I don't get that...can you give a more detailed information here? An example? What "main roms" do you miss?
Look at your created datfile. It does not include the parent sets for e.g. 2020bb, burningf, ridheroh since you did not include it in your datfile generation
and you may loose the connection to the neogeo bios for such sets, too since the parent links to the bios via romof usually
So...please gimme some more details but I bet you find the problem inside your dat.
erm.....I don't get that...can you give a more detailed information here? An example? What "main roms" do you miss?
Look at your created datfile. It does not include the parent sets for e.g. 2020bb, burningf, ridheroh since you did not include it in your datfile generation
and you may loose the connection to the neogeo bios for such sets, too since the parent links to the bios via romof usually
So...please gimme some more details but I bet you find the problem inside your dat.
217
clrmame Discussion / Re: Rebuilder 0.01 released
« on: 17 July 2022, 06:47 »
Well...the 25 years in between were fille with clrmamepro and other stuff...CLI...well...for a start since I wanted to concentrate on the core. Next steps are most likely a scanner and after that a simplified UI. But not as a replacement more like an addon.
218
clrmame Discussion / Rebuilder 0.01 released
« on: 13 July 2022, 20:35 »
Rebuilder 0.01 released
Yes...something new, something fast, something I've enjoyed coding. Rebuilder is a small commandline tool which has some advantages over the rebuilder in clrmamepro. Faster, Standalone merge mode, CHD rebuild to name a few.
Read more: https://mamedev.emulab.it/clrmamepro/binaries/readme.html
Download: https://mamedev.emulab.it/clrmamepro/#downloads
Some examples:
Load a MAME 245 listxml dat, use e:\mame\roms as source, f:\sorted as destination folder, scan the source recursively and create sort the output by manufacturer and year. Rebuild in zipped split merged mode (default):
rebuilder.exe -x e:\temp\245.xml -i e:\mame\roms -o f:\sorted -r -p #MANUFACTURER#/#YEAR#
Generate standalone sets in f:\standalone, based on 245 data with roms from e:\mame\roms but limit it to machines named 194*
rebuilder.exe -x e:\temp\245.xml -i e:\mame\roms -o f:\standalone -r -m standalone -f 194*.
Trust crc32/size hash for an even faster processing...(-s none)
rebuilder -x e:\temp\245.xml -i e:\mame\roms -o f:\test1 -r -s none
Do a really slow but full sha1 input/output check and with recompressing
rebuilder -x e:\temp\245.xml -i e:\mame\roms -o f:\test2 -r -s both -c rezip
Generate a full merged output but decompressed
rebuilder -x e:\temp\245.xml -i e:\mame\roms -o f:\full -r -m full -c none
Load a softwarelist collection dat (mame.exe -listsoftware) and rebuild my unsorted stuff for all software lists at once:
rebuilder -x e:\temp\245_soft.xml -i e:\unsortedstuff -o f:\softwarelists -r
Split my sets by device, mechanical, bios folders
rebuilder -x e:\temp\245.xml -i e:\mame\roms -o f:\clean -r -p #BIOSSPLIT#
Rebuild from a to b and remove rebuilt source files
rebuilder -x e:\temp\245.xml -i e:\a -o f:\b -r -d
Yes...something new, something fast, something I've enjoyed coding. Rebuilder is a small commandline tool which has some advantages over the rebuilder in clrmamepro. Faster, Standalone merge mode, CHD rebuild to name a few.
Read more: https://mamedev.emulab.it/clrmamepro/binaries/readme.html
Download: https://mamedev.emulab.it/clrmamepro/#downloads
Some examples:
Load a MAME 245 listxml dat, use e:\mame\roms as source, f:\sorted as destination folder, scan the source recursively and create sort the output by manufacturer and year. Rebuild in zipped split merged mode (default):
rebuilder.exe -x e:\temp\245.xml -i e:\mame\roms -o f:\sorted -r -p #MANUFACTURER#/#YEAR#
Generate standalone sets in f:\standalone, based on 245 data with roms from e:\mame\roms but limit it to machines named 194*
rebuilder.exe -x e:\temp\245.xml -i e:\mame\roms -o f:\standalone -r -m standalone -f 194*.
Trust crc32/size hash for an even faster processing...(-s none)
rebuilder -x e:\temp\245.xml -i e:\mame\roms -o f:\test1 -r -s none
Do a really slow but full sha1 input/output check and with recompressing
rebuilder -x e:\temp\245.xml -i e:\mame\roms -o f:\test2 -r -s both -c rezip
Generate a full merged output but decompressed
rebuilder -x e:\temp\245.xml -i e:\mame\roms -o f:\full -r -m full -c none
Load a softwarelist collection dat (mame.exe -listsoftware) and rebuild my unsorted stuff for all software lists at once:
rebuilder -x e:\temp\245_soft.xml -i e:\unsortedstuff -o f:\softwarelists -r
Split my sets by device, mechanical, bios folders
rebuilder -x e:\temp\245.xml -i e:\mame\roms -o f:\clean -r -p #BIOSSPLIT#
Rebuild from a to b and remove rebuilt source files
rebuilder -x e:\temp\245.xml -i e:\a -o f:\b -r -d
219
clrmame Discussion / Re: Old .SAM files Support
« on: 13 July 2022, 18:32 »
nah...it was a problem in reading in the datfile and getting rid of existing extensions for sample files to make them dynamic....these days samples don't have extensions anymore....Thanks for reporting.