EMULAB Forum
clrmamepro [English] => clrmame Discussion => Topic started by: hap on 05 August 2014, 18:39
-
This is the message that pops up when Clrmame finds a rom inside a clone that has the same name as one in the parent but a different hash:
"Issue: Can't merge set due to equal names for different ROM hashes
Press yes to remove parent/clone relationship or no to force split-merge mode."
Instead of that, how about this? "Press yes to rename this file to origname(__setname).xx or no to force split-merge mode.".
Since Clrmame is the most-used rom manager, currently MAME goes all the way around this issue and forces to have names of roms like that itself. IMO it'd be cleaner if this was done inside Clrmame instead, for people that want a completely merged romset.
-
hmm...but then you do alter a rom name.....and I already hear people complaining about that (even if MAME itself does not care since it loads by hash value)...I thought removing the parent/clone relationship is the less evil thing here to do...
....besides of this I guess 99% of MAME users use split sets....
well.....maybe we can keep that up for discussion.....
-
hmm...on a second thought....since cmpro supports set subfolders (and I think MAME load routine should be able to handle that, too)....I may think about changing it from "origname" to "setname\origname"...
-
Ah indeed, that's a better idea, didn't think of it.
Even if you take away nameclashes, it is a much cleaner way for a fully merged romset rather than throwing it all under 1 folder.
-
yeah....I will run some tests....
-
I brought this issue up previously:
Honestly I don't like the sub-folder idea..
I'd be happy with
Some_rom.ext
to
Some_rom.ext_alt
Seeing MAME doesn't care about file-names at all.
EDIT: Oh maybe I wasnt thinking deep enough..
Do you mean ??
Parent.zip
\parent\rom.1
\parent\rom.2
\clone_1\rom.1
\clone_2\rom.1
-
Oh, and there's this:
(http://ndsxdelta.no-ip.org/part_merge.png)
By default, is unticked, so many people end up making a Merged - say t7z ROM set:
1. Which takes longer to process (make)
2. Ends up with archives which are larger & with more (internal) files than needed.
-
I brought this issue up previously:
Honestly I don't like the sub-folder idea..
I'd be happy with
Some_rom.ext
to
Some_rom.ext_alt
Seeing MAME doesn't care about file-names at all.
EDIT: Oh maybe I wasnt thinking deep enough..
Do you mean ??
Parent.zip
\parent\rom.1
\parent\rom.2
\clone_1\rom.1
\clone_2\rom.1
close but not it....only if you got a hash collision you'd get a subfolder for that one file...
so
parent.zip is
rom.1, rom.2, rom.3, clone_x\rom.3, clonerom.1
(where rom.1 to rom.3 are parent roms, rom.3 in clone_x is different from its parent nad clonerom.1 is a real clone file)
-
Hi Oxy, about this option "Rom Parse merge tag" tick or untick ?
My cmpro this option is unticked, when it's on cmpro wanna rename mass roms !!!
Which is right, btw my Mame sets it's t7z/merged
Tnx:)
Little screen from my cmpro:
-
@Roman ::) Thanks, I understand your intention now :)
@Oddi, yes CMP 'says' it wants to rename those files:
BUT, I think you will find that name already exists in the archive with matching CRC
So, CMP will not Rename them, it will delete them ..
Parse ROM 'merge' tags
Makes archives with less internal files, and a smaller total size archive..
You could try a few (copied from your current set) watch what CMP does to them ;)
-
well...regarding rom merge tags...
they were pretty wrong and several times broken in the past within MAME's listxml output. Cmpro finds wrong merge tags and I think by now it should be pretty stable within MAME.
it's all about your interpretation how a clean set should look like....should it contain all database listed items, correctly named...then you should turn it off...
If you care more about as-compact-as-possible sets, turn it on....then you may loose the information about rom names withing clones...since MAME tries to name the roms after the actual ICs on the board, you may have hash identical roms with different names within parent/clone relationships...
..it's just a matter of taste...maybe I turn the option on by default for the next release....
-
ok...took a MAME .149 database (since someone (hehehe) fixed such hash clashes lately in MAME), turned rom merge parsing on and looked at the bombjack sets which had a hash clash back then....
So instead of having the parent clone relationship removed, you end up with something looking like the attached picture....(yes...a subfolder...in your archive)
-
cool =)
-
user would still see a prompt during data read in though.....will see if this is really needed
-
"will see if this is really needed"
How about now? =p
http://git.redump.net/mame/commit/src?id=9380cbaf71c71ac06f72cf8367f76aabd9751abf (http://git.redump.net/mame/commit/src?id=9380cbaf71c71ac06f72cf8367f76aabd9751abf)
-
hahaha....damn you... ;-)
-
Hello guys , whastup with the last Mame svn code ? Strange job, i build and scan with the last cmp forum build and the last svn mame dat. CMP wanna remove and rename mass roms, when i click on, cmp create different sets names with same roms inside.
tnx:)
-
Hi Oddi,
@Reply #6
Do you still have "Parse ROM 'merge' tags" ticked ?
BTW, I always keep it ticked, my reasons explained above ^^
-
No, untick atm, must tick for future ?
[PS] When is ticked , cmp report many warnings - "same roms name with different hashesh" rename or remove and bla bla ..
chaos
Where is the truth ? :))))
Found the truth ! , Roman and mamedevs want to make my life hard. :P :P :P
-
No, untick atm, must tick for future ?
Ask yourself :)
Do you want a merged ROM set, which:
1. Takes less time to process, cause it has less total files (Yes still passes perfect audit in EMU)
2. Makes a smaller 'total sized' set.
Maybe you should Re-read my & Roman's earlier replies .
Ok then, about the 'other' changes
See Hap's reply earlier, not sure how much he has done, but clearly he has taken to doing 'some' ROM renaming ;)
-
Oddi....
hap renamed a dozens files in MAME ;-) and the current official cmpro asks you if you want to remove parent/clone relationship or force split-merge mode...
my own build does something else already.....which was described earlier in this thread...
Guess a new cmpro comes mid/late next week....
-
What about a BETA for testing Roman ? ::)
-
when I resolved your rebuilder thingie....
maybe...not much time this week....will see....
-
http://mamedev.emulab.it/clrmamepro/binaries/cmp20140814.rar (http://mamedev.emulab.it/clrmamepro/binaries/cmp20140814.rar)
...use on own risk ;-)
-
Hi Roman, cmp20140814.rar <-- clean cache, option "Parse Rom merge tag" enable, cmp crashed :(
That is that fast first test
CMP crash of 1942 set , me watch new subfolder inside archives ( 18w.7z ) , now try play with qmc2 games from subfolder for test.
-
yep it crashes....will look at it later (maybe next week)....and I removed the package....
I know what it is (index error...most likely based on the change of name and resort....)...but I need some more time next week to find the (most likely simple) root issue...
so...delete the build and use the official cmpro ;-)
-
Roman, see that from Haze blog:
http://mamedev.emulab.it/haze/2014/08/11/ume-0-154ex1/#comment-36345 (http://mamedev.emulab.it/haze/2014/08/11/ume-0-154ex1/#comment-36345)
-
too much reading...for me here at work...
let the mamedevs work on the naming...and avoiding name/hash conflicts...
generally the cmpro part is to somehow preserve the naming and the parent/clone relationship...and I guess the idea of having subfolders is ok...
but again, it's up to devs to avoid such things in a first way (while still keeping their naming convention)....
-
well...in the meantime I found the (pretty obvious sorting) bug which caused the index issue with the test build.....and fixed it..
However I'm not really happy with the solution...
ok...it would rename hash/name collisions to "setname\filename" ...but it currently it does it to resolve the problem only...which means that it will only rename file with the found collision in one set...not the other....
Example:
Parent: A, B, C
Clone 1: D, E, F
Clone 2: D, G, H (where this D != D from the previous clone)
and this ends with:
Parent: A, B, C
Clone1: Clone1/D, E, F
Clone2: D, G, H
Currently I'm thinking if it would be better to also rename the second D:
Parent: A, B, C
Clone1: Clone1/D, E, F
Clone2: Clone2/D, G, H
...and what if the parent is part of the hash collision....should the parent keep the name while only the clones change?
Parent: A, B, C, D
Clone1: Clone1/D, E, F
Clone2: Clone2/D, G, H
or
Parent: A, B, C, Parent/D
Clone1: Clone1/D, E, F
Clone2: Clone2/D, G, H
.... waiting for ideas .....
-
Roman, i like the last idea:
Parent: A, B, C, Parent/D
Clone1: Clone1/D, E, F
Clone2: Clone2/D, G, H
I think it would be neatly, my opinion :)
-
actually my current favorite is
Parent: A, B, C, D
Clone1: Clone1/D, E, F
Clone2: Clone2/D, G, H
so only affected clone files may get a subfolder
-
I do agree with Roman.
In case of merged sets, it would be logical to have the parent (which is somewhat considered "the perfect set" in MAME) into the root of the zipfile, and the various clones into their subdirectory inside the zip.
IMHO this should be valid for all sets, not only for sets with name collisions. It will have both the advantage of a single zipfile (as it is in merged sets now-a-day) and of a humanly readable structure to separate parent from clones (as it is in split sets now-a-day)
Just my 2 cents. Eurocents, off-course! ;)
-
well...yes...I can consider this, too....instead of the hash collision warning a general option to allow to store clones as subfolders...
however, this would only be needed if you got fully merged sets.....and since you can switchmerge modes whenever you want I would need to have a dynamic filename getter....depending on the used merge mode...like
string getFileName() {
if (full_merge and (user_wants_subfolders or is_hash_collision_file)) {
return "setname\filename";
}
return filename;
}
hmmm...interesting....need to think about this a bit...
-
Parent: A, B, C, D
Clone1: Clone1/D, E, F
Clone2: Clone2/D, G, H
this is the subfolders ?
me think that is name of files
"name of clone set"_D,E,F
"name of clone set"_D,G,H
dont like idea with subfolders , sorry.
example with any set:
parent - 1942.7z / roms : a.rom b.rom
clone - 1942a.7z / roms: b.rom c.rom
clone 1942b.7z / roms: b.rom d.rom
and blabla
After merge sets have only one set 1942.7z
inside have :
---
a.rom
1942_b.rom
1942a_b.rom
c.rom
1942b_b.rom
d.rom
and etc etc
-
Sorry Oddi but we (well, at least some MAME devs and myself like the idea) do want archive subfolders ;-)
The goal is to keep as much original database information from MAME as possible...so altering the filenames should be a no-go....putting them into a set-subfolder (in full merged mode) however sounds pretty ok to me...
again, this only affects full merged sets...and only the structure within the archives would change.....
-
Ok Roman , me think about that " The goal is to keep as much original database information from MAME as possible." , yep u are right.
Go to subfolders :)