EMULAB Forum
clrmamepro [English] => clrmame Discussion => Topic started by: Roman on 13 August 2009, 22:57
-
Done
- list control for the result
- sorting support by column
- copy to clipboard (|-separated, no header, all columns)
- save to disk (|-separated, no header, all columns)
- export as mamediff format (oldname, newname + filenames as header)
To Do
- improve fuzzy / best guess test
- option to forbid parent renames (since some dats only work on parents)
- auto patching a 3rd (or maybe more) dat(s) on game or rom level
- save positions, sorting, more messages blabla...
Hey s_bastian, I guess you want to test this....
...check later posts for updated urls...
*edit* yes..I', aware of the "thrild2" issue when comparing 133 vs 132.
|thrild2a|?|
*|thrild2|thrild2a|matched by single unique rom hash
*|?|thrild2|
so what happened here....
a) there's a missing * in the first line
b) why does the 3rd line show thrild2 as a new file (in the 2nd it's an old)
The reason for both is the "not allow double renames" and the best guess rename finder.
thrild2a is normally a best guess rename to thrild2a but we already have a higher prio rename by single unique rom hash. That's why it gets the ?.
The missing * is simply a bug which doesn't set the indicator in this case....
The 3rd line is simply also a bug based on this higher prio rename just the other way around..
I will look into this over the weekend....anyway...Rename Wizard is WIP :)
-
gave it a fast run and it is working great. I will give it a more deep testing, trying a "backward run" from 133u2 thruoughout some dats I have here, let's see if something odd happens ;)
-
small bug in the mamediff.out generation: newlines are not properly defined, they should be \r\n
-
I was working with OLD dats, 100u2 to 100u3
|nss_smw|?|
*|?|nss|
*|nss|nss_smw|matched by fuzzy best guess
nss is be the BIOS for nss_smw
In this case, only a ROM in the BIOS set was changed, game ROMs were unchanged. I believe in cases like this rename should consider also if changed roms are "merge" or not...
nss_smw in 100u2: rom ( name spc700.rom merge spc700.rom size 64 crc 38000b6b sha1 9f3af3d51c229e67daa68041492afa27287aad31 region cpu2 offs ffc0 )
rom ( name nss-c.dat merge nss-c.dat size 32768 crc a8e202b3 sha1 b7afcfe4f5cf15df53452dc04be81929ced1efb2 region cpu3 offs 0 )
rom ( name nss-ic14.02 merge nss-ic14.02 size 32768 crc e06cb58f sha1 62f507e91a2797919a78d627af53f029c7d81477 region cpu3 offs 0 )
rom ( name mw.ic1 size 262144 crc cfa601e7 sha1 5c9a9a9fccd4b4fcbbda06dfdee41e92dc4e9097 region user3 flags baddump offs 0 )
rom ( name mw.ic3 size 32768 crc f2c5466e sha1 e116f01342fcf359498ed8750741c139093b1fb2 region user4 offs 0 )
nss_smw in 100u3: rom ( name spc700.rom merge spc700.rom size 64 crc 44bb3a40 sha1 97e352553e94242ae823547cd853eecda55c20f0 region cpu2 offs ffc0 )
rom ( name nss-c.dat merge nss-c.dat size 32768 crc a8e202b3 sha1 b7afcfe4f5cf15df53452dc04be81929ced1efb2 region cpu3 offs 0 )
rom ( name nss-ic14.02 merge nss-ic14.02 size 32768 crc e06cb58f sha1 62f507e91a2797919a78d627af53f029c7d81477 region cpu3 offs 0 )
rom ( name mw.ic1 size 262144 crc cfa601e7 sha1 5c9a9a9fccd4b4fcbbda06dfdee41e92dc4e9097 region user3 flags baddump offs 0 )
rom ( name mw.ic3 size 32768 crc f2c5466e sha1 e116f01342fcf359498ed8750741c139093b1fb2 region user4 offs 0 )
-
yeah..as I said..I'm not yet fully happy with the fuzzy name/best guess check...I will try to tweak it a bit more....
-
ok..new version up...
- linefeeds in files should be fine now
- assertion in 6th check fixed
- correct handling of newly added sets (the thrild2 issue mentioned before)
- correct showing the * in all cases (the other thrild2 issue mentioned before)
http://mamedev.emulab.it/clrmamepro/binaries/cmpro32_update_20090814.rar
http://mamedev.emulab.it/clrmamepro/binaries/cmpro64_update_20090814.rar
now looking into tweaking the best guess check....
-
- linefeeds in files should be fine now
Checked. They are OK in the game list, the are not in the first row, see where bnzabrsj is placed:
F:\Nuova cartella\100u4.dat F:\Nuova cartella\101.dat bnzabrsj
magic102
sspiritj sspiritj
Further to this, alwqays in the 100u4 to 101 passage:
*|?|magic102|
*|magic10_2|magic102|matched by unique set hashmagic102 has a double entry, one as unique set and the otehr as NEW SET.
Odd, isn't it?
-
ok..will check the 1st row....and yes, the 2nd issue looks weird....*sigh*...if I'd only find some time....but assume that these two get fixed rather quickly....
-
this same problem happens again in 101u3 to 101u4, twice
*|?|glass10a|
*|glassa|glass10a|matched by unique set hash
*|?|glass10|
*|glass|glass10|matched by unique set hashlooking at the dats to understandwhat there might be leading to this...
-
Trying to understand if the problem was somewhere else over the dats, I created two small dats with only glass/glassa and glass10/glass10a sets. The problem remains, also if there is nothing strange I can see in the dats... I attach them here as a reference, so you can check it out easier
-
More rumblings on the glass thing:
What happened on 101u3 to 101u4 was:
A new PARENT set called GLASS has been introduced
The old glass (parent) became glass10 (clone) maintaining the same romset but with some roms now flagged as MERGE
Glassa was renamed as glass10a, same roms and same merges as before
So there is more than one problem:
- why was not glass reported as new set in 101u4?
- why is the wizard giving a double report for these set, also for the "reduced" dats that are actually missing the new glass set??
-
ok...fixed everything for next wip....stay tuned
-
ok...new toy...
- fixed header line linefeed
- fixed added files
- removed fuzzy/best guess (it was not robust enough.....)
- renamed methods a bit and added new strings for the 2 new options and new/removed sets
- 2 new options, allow double new names and allow parent rename
to do:
- saving/loading of options
- don't reparse when dats haven't changed
- apply changes on selectable 3rd dat
...now back to real life...
http://mamedev.emulab.it/clrmamepro/binaries/cmpro32_update_20090819.rar
http://mamedev.emulab.it/clrmamepro/binaries/cmpro64_update_20090819.rar
-
very good, the glass matter is fixed.
OK, let's go back hunting for bugs! :D ;)
(PS: don0t bother following all my rumblings, your Real Life coimes first!! :)
-
This is just trivia, so don't bother fixing them unless you REALLY have the time to do it (and I know pretty well how pregnant wives consider their husband's spare time, so feel free to ignore me!! :P
bug 1: dats from 099u4 to 099u5:
*|tfrceacb|?|double rename
*|tfrceacj|?|double rename
*|tgm2|?|double rename
*|tgm2p|?|removed setThey are reported correctly, but why "double rename instead of removed set?
bug 2:
When ordering by Old Name / New Name, "?" are put between numbers and letters, instead of being first or last of the group. It would IMHO better to put them at the beginning or at the end of the list
|9ballsht|9ballsht|matched by unique set hash
*|?|sercharj|new set
*|?|murogem|new set
*|?|funkyfig|new set
*|?|ampokr2c|new set
|a51mxr3k|a51mxr3k|matched by unique set hash
-
Regarding 1) hmm...could be a mistake when adding the reason/method strings...
Regarding 2) well..the strcmp function (which is used during sorting) sorts by ascii code and there ? is between numbers and characters
-
I imagined something like that, again, that is trivia...
this is instead a more serious thing:
dats from 099u6 to 099u7 (at least, this is where I notice it....)
old mshvsf is renamed into mshvsfu, and a new mshvsf is added. This is all I get from the wiz:
*|mshvsf|mshvsfu|matched by unique set hash
the new mshvsf is not reported anywhere, not even changhing the scan method... :(
-
This is more complex.
mshvsf is renamed to mshvsfu ...ok ...correct fine...
"new sets" are listed if they are a) not appear in the old list (which your new mshvsf does) and b) if they are not in the 'old->new name' list.
So actually I can't determine that a new mshvsf was added unless I do a "new -> old" rename check....(which wasn't the original purpose of the rename wizard)....
Hmm....I will think about it...
-
good to know it is not a bug but a "known feature".
No problem, I'll sort that out "my way" ;)
-
I'm extremely happy about this new development of clrmame.
Now crlmame is no more "only" a rommanager, but it's also a "datmanager"; something I was asking more then 3 years ago.
In addition to this "compare" function, it would be great to have also an "addition" function and a "subtraction" function.
Where addition is: take datfile A and datfile B -> generate datfile C which include all roms from both datfile, whit only one instance for duplicate roms.
Subtraction is: take datfile A and datfile B -> generate datfile C which only includes roms from A not duplicated in B
Am I dreaming? ;)
-
AFAIK DatWorkshop is already doing this....
http://www.emulab.it/simone/?page_id=7
-
http://mamedev.emulab.it/clrmamepro/binaries/cmpro32_update_20090820.rar
http://mamedev.emulab.it/clrmamepro/binaries/cmpro64_update_20090820.rar
today's features:
- fixed the double rename issue
- replaced ? with ""
- changed progress window slightly
- fixed some index stuff
- added check of "replaced sets" (aka the mentioned mshvsf thingie...)...well..what it does is: check new dat names against old ones...if there is a match and that old name is not in the list of renames (where kept names are included), show the set as "replaced".
Go and test a bit :)
-
AFAIK DatWorkshop is already doing this....
http://www.emulab.it/simone/?page_id=7
OH, yes! I'm using it, and it's good. But everything in one single tool would be marvelous!
-
mmm sounds like people wanting to play everything with only MAME..... :P :P :P
Anyway:
*|glass|glass10|matched by unique set hash
*|glassa|glass10a|matched by unique set hash
*||glass|replaced set
:D :D :D /me is happy :)
Now, let's go back hunting for more bugs, but I believe they will be very hard to find now.... :)
-
wow..more than a day and no reports yet ... :)
-
busy at work, that's the reason! :P
(only half true, I made some more, also making some redundancy checks with some of my scripts, and still nothing strange appeared :)
This is the tool I needed to rollback all the catlist, thanks man! :)
-
8)
http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=199520&page=0&view=expanded&sb=5&o=&fpart=1&vc=1
made a little advertising there, too
-
well....some more coding on it...however no wip exe this time...
- moved rename wizard to profiler
- windowpos/columnswidth and options are saved now
- "diff" buttons checks if a re-parsing of dats is needed
- added 3rd dat mode which allows you to load a dat and apply the found changes on it. This can be in set or/and in rom mode.
Rom Mode: Each rom in each set is checked for an old name match (without taking extensions into account) and the name is updated to the new one (replaced sets and new sets don't play a role here).
Set Mode: Each set name is checked for a match and the name is being updated (again, replaced sets and new sets don't play a role here).
Modified dat is saved to *_new.dat/.xml.
So you can e.g. load a MAME 133 dat and a MAME 133u3 dat and apply the renames on the flyer datfile.
Parsing + diff the 2 dats only has to be once....after that you can exchange the dats to mod.
Open things:
- optionally don't ignore extensions in "apply on rom" mode
- "apply on set" mode is not that easy as you might think....currently it only updates the name. I plan to include description, year, manufacturer, sourcefile and cloneof/romof.....but still, this isn't the full set defintion, so the modified dat has to be handled with care....
Anyway...I started this thing because I didn't want to rename the artwork dats manually.....and something which is a bit more accurate than mamediff....looks like it becomes reality soon....
-
Here I am again, did you miss me??? :P
from 103u2 to 103u3:
*|sf2049se||double rename
*|sf2049te||double rename
*||sf2049se|replaced set
*||sf2049te|replaced set
These should be two "matched by unique set hash", set is composed by 1 rom + 1 chd and nothing changes from one version to the other, unless I overloocked something in the dats...
-
The sets do differ...the u2 ones all had a bad dump listed (which influences the set hash).
However there was a little mistake in handling bad dumps which is now fixed.
|sf2049|sf2049|matched by description
|sf2049se|sf2049se|matched by description
|sf2049te|sf2049te|matched by description
-
Open question...
...does it make sense to apply (besides setname) description/year/cloneof/romof/manufacturer from the new dat to the 3rd dat....
hmmm....
-
The sets do differ...the u2 ones all had a bad dump listed (which influences the set hash).
However there was a little mistake in handling bad dumps which is now fixed.
Missed the "bad dump" thing, anyway, good it is settled :)
Now waiting for next beta... :D
...does it make sense to apply (besides setname) description/year/cloneof/romof/manufacturer from the new dat to the 3rd dat....
Mmmm I would make an option, OR check if these informations are already present in the 3rd dat and apply only if they are already there. EG, a dat made with dir2dat, like most of the snap ones are, have no such informations and they are not mandatory because in snap collection there is no actual dependency. So these informations will be redundant. In case of ROM/SAMPLE dats some of these infos ARE actually useful, so it should be important to report there too.
-
yeah..maybe another option to rename the other tags....that should be possible.
...and I don't think there will be another beta, I more think of a release this week since my new home's internet will be hopefully active next week and my old one will be shutdown.....I expect a much worse scenario with no access for some days :)
Time to moooove.....
-
Hope you will not have the problem I had with the last move... it took my ISP 2 weekd to try to arrange the move, he continued to re-activate the line on the old number. I solved changing ISP..... :P