clrmamepro [English] > clrmame Discussion
mame merged sets not scanning correctly?
Pandor:
Thanks. So as you say, and what I suspected, it is subject to interpretation (there is no standard unfortunately, and MAME does indeed not care, as long as the file is there somewhere), and it seems CMP and RV differ in that aspect. so a RV merged romset, is not compatible with CMP's algorithm, apparently (and vice/versa).
I've always been a split set advocate, but thought I would change that for this current set. I guess it bit me in the *ss ;D
I'll just stick to RomVault then. it is, in my humble personal opinion a bit more intuitive and user-friendly.
Thanks for the help though. It did clear up a lot.
Pandor:
Just for reference, this is how RomVault interprets the same set:
Roman:
would it list an additional 136081-3030.15d rom with f143f0e16850ad98366db208e956f7402d1ca848 in pitfight4 as unneeded then? Or would it simply mark it green?
Well, it's of course your decision, however if you're coming from MAME's -listxml output, you see that e.g. "136081-3030.15d" from pitfighter 3 and 4 do not have any "merge" attribute set...and if you follow the idea of having the archive structure like
- the archive is named after the parent set
- the subfolders in the archive are named after the clones and each holds the files for that clone but limits it to the ones which differ from its parent
Sounds a bit more structured if you ask me.....(compared to..."ah yeah...and it also needs a file from another subfolder since the clone shares a file with another clone, too)
But again...it's all about interpretation and personal taste.....however it's now 26 years that I hear of a full merged storing method like that (romvault's)...may be an idea as additional view for the rebuilder tool (https://www.emulab.it/forum/index.php?topic=8816.0) which currently supports split, full (always with subfolders) and "standalone" which is also "new" compared to cmpro....
Pandor:
--- Quote from: Roman on 13 April 2023, 11:51 ---would it list an additional 136081-3030.15d rom with f143f0e16850ad98366db208e956f7402d1ca848 in pitfight4 as unneeded then? Or would it simply mark it green?
Well, it's of course your decision, however if you're coming from MAME's -listxml output, you see that e.g. "136081-3030.15d" from pitfighter 3 and 4 do not have any "merge" attribute set...and if you follow the idea of having the archive structure like
- the archive is named after the parent set
- the subfolders in the archive are named after the clones and each holds the files for that clone but limits it to the ones which differ from its parent
Sounds a bit more structured if you ask me.....(compared to..."ah yeah...and it also needs a file from another subfolder since the clone shares a file with another clone, too)
But again...it's all about interpretation and personal taste.....however it's now 26 years that I hear of a full merged storing method like that (romvault's)...may be an idea as additional view for the rebuilder tool (https://www.emulab.it/forum/index.php?topic=8816.0) which currently supports split, full (always with subfolders) and "standalone" which is also "new" compared to cmpro....
--- End quote ---
This way it does save (some marginal) space, doesn't it? as in my pit fighter example, rev3 becomes a parent for rev4, and rev4 only includes roms that are not in rev3. in CMP's case, the roms from rev3 are duplicated from rev3 to rev4 and only the actual (head) parent, pitfight is taken into account, right?
I'm not saying this is the 'correct' way. Just thinking out loud, and trying to figure out the difference between CMP en RV, and why they differ.
What about split then? will CMP also include the rev3 roms into the rev4 zip?
Becuase the way I see it now (I could be completely wrong), merged is just the same as split, but clones are just included as subfolder in the parent/main zip, which could save some space because of zipfile header/encapsulation overhead?
Pandor:
--- Quote from: Roman on 13 April 2023, 11:51 ---would it list an additional 136081-3030.15d rom with f143f0e16850ad98366db208e956f7402d1ca848 in pitfight4 as unneeded then? Or would it simply mark it green?
...
--- End quote ---
re-reading this, I get your point, and is something i'll test. Just like mame, it is possible that RV doesn't care where the file/rom is. and it will mark it green eighter way. but it is still a rom manager, so there should be some 'standard' it adheres to, and not put it randomly in a subfolder/zip that is most convenient, or it would never be consistent.
As you say, I think it will deem it as unneeded, and move it to rev3 where it is 'needed', if not present, and discard it from rev4. But I have not tested this.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version