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

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.

61

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...

62

clrmame Discussion / Re: Cmpro "misplaced a romset" !?

« on: 03 August 2022, 11:00 »

I can check it next weekend.

63

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.....

64

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.

65

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....

66

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.

67

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.

68

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.

69

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.

70

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

71

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.

72

clrmame Discussion / Re: Old .SAM files Support

« on: 13 July 2022, 09:25 »

use this:

https://mamedev.emulab.it/clrmamepro/binaries/cmpro20220713.7z

73

clrmame Discussion / Re: Old .SAM files Support

« on: 12 July 2022, 19:54 »

Hmm...I've just tested this by renaming some of the current .wav samples in .sam and scanned and got no errors....sooo....since the only samples information which is checked is the name, different extensions seem to work as I though of....

What errors do you get? Maybe the problem is in the dats....

74

clrmame Discussion / Re: Old .SAM files Support

« on: 12 July 2022, 11:30 »

Still supported in cmpro? Actually yes since cmpro's samples check should check .wav, .flac, .ape and .sam....
Still supported in MAME....I highly doubt that....guess that was dropped >15 years ago

75

clrmame Discussion / Re: [Clrmamepro] Enable all rompaths for an external drive?

« on: 07 July 2022, 13:30 »

If they are not enabled during the test, they get disabled and that status is saved.
So yes, in that case you need to reenable them manually. There is no automatic "retry". The disabled status is saved in the profile.

My advice was more for the future use: If you enabled it successfully, ensure for the next time that before loading the profile, the drive is ready.

76

clrmame Discussion / Re: [Clrmamepro] Enable all rompaths for an external drive?

« on: 07 July 2022, 07:27 »

If I remember correctly cmpro tests on profile load if the paths (rom paths, sample paths, etc...) are available, if not they get disabled.
So actually you only have to make sure that your external drive is there before you load a profile.

77

clrmame Discussion / Re: WWW Open

« on: 06 July 2022, 09:49 »

I think variables were used in other places (set selection, export, setinformation, etc) but not in urls.ini.....but actually I can't rememeber and have to look that up.

78

clrmame Discussion / Re: WWW Open

« on: 06 July 2022, 08:22 »

A download link somewhere might not directly lead to the binary you may want to download....most likely the 2k you've downloaded are simply html code...

for example:
https://github.com/mamedev/mame/blob/master/src/tools/chdman.cpp

is not the chdman.cpp file itself but a html page...

so....if you open your 2k file in a texteditor I bet it's just html code......

79

clrmame Discussion / Re: WWW Open

« on: 06 July 2022, 08:09 »

If I remember correclty, www open doesn't allow variables at all...you can only specify a pre and post url string in your urls.ini file. https is of course supported.

So if you add e.g. the following to urls.ini before you start cmpro:

Google; https://www.google.com/search?q=; .zip

You can use WWW Open -> Set Url to "Google" and then www open shows you options to open for example "pacman" at the given url:
https://www.google.com/search?q=pacman.zip

80

clrmame Discussion / Re: Quick questions

« on: 02 July 2022, 05:38 »

1. if you set cmpro.ini Misc_DisplayLIErrors = 0 ,then you shouldn't get ANY messages during reading datfiles....not really what you want but maybe a workaround

2. you may try to set cmpro.ini Adv_WindowToFront = off, but I think this was only for bringing the window to top when scan/rebuild is finished