Feature request for the next version

Forum rules
No roms requests or illegal links

Post a reply

Smilies
:D :) :( :o :shock: :? 8) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: :clap: :hum: :gnak: :lol: :super: :uh: :toobad:
View more smilies

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Feature request for the next version

by Logiqx » Tue Oct 31, 2006 9:52 am

There are two other significant possibilities:

D) main set + multiple clone (treat like A)
E) multiple clones w/o main set (the most complicated scenario)

Anyway, I think that there are two important points here:

1) It is non-trivial to implement. It may seem simple when talking about single clones and stuff but there are some very odd boundary conditions that must be considered (hell, we haven't even got into resources or games where the parent and ROM have exactly the same ROMs) and I am sure that the result would be spaghetti code. No longer would the code be processing one game at a time with static ZIP requirements but they must be pooled together (to figure out which ROMs exist, which games are fully satisfied and the required ROM movement) and potentially shuffling ROMs in 3 directions. In coding, we should all strive for 'as simple as possible but no simpler' (thanks for that one Albert).

2) From the sounds of what Eric said, it would be a complete rethink/rewrite to the core of RomCenter... not just a few extra lines of code that can be plugged into an existing function (there is nowhere suitable in the RomCenter design). As Eric says, it pre-calculates a static database based on the 3 main organisational options.

I understand where you are coming from and you are right in saying that it could be done but imo (n.b. I am not the author of RomCenter but I do write clever tools that need to understand ROM relationships) the benefits do not justify the complexity.

Logiqx

by nailbomb » Mon Oct 30, 2006 11:49 pm

looked at my sets again, i found these possible occurrences (of course you may have more...):
A) main set + single clone
B) single clone w/o main set
C) main set w/o clones

i'd like to have A) with split-mode and B) with unmerged mode.

hmm, maybe it is possible to have a sortable column instead, that could indicate the type of each set like A,B,C,D ... so i could manually select them at once and apply a different structure mode to each type of set, how about that?

by Wanderer » Mon Oct 30, 2006 11:34 pm

nailbomb wrote:
That wouldn't actually work because MAME does not search all related clones for a required ROM. It only searches the immediate parent and the clone itself.
oh, i didn't knew that! seems i do only have single clones - i'm sorry, everbody forget what i said before :roll:
Hi there

As i said before, this may be a wish for MAME: If a clone requires some files in a mainset and those files exist but other (irrelevant) files of the mainset are missing, the clone should be executed normally. IMHO, it should be working like this.

by nailbomb » Mon Oct 30, 2006 11:22 pm

That wouldn't actually work because MAME does not search all related clones for a required ROM. It only searches the immediate parent and the clone itself.
oh, i didn't knew that! seems i do only have single clones - i'm sorry, everbody forget what i said before! :roll:

by Logiqx » Mon Oct 30, 2006 9:42 pm

nailbomb wrote:
OK, suppose a game has 5 clones. To which clone the main game's files will be added? Select one of them arbitrarily?
to that particular clone which requires these. if more than one does, pick one of those arbitrarily (to avoid duplicates, thats the whole point).
That wouldn't actually work because MAME does not search all related clones for a required ROM. It only searches the immediate parent and the clone itself.

In the example above, you would be breaking 4 clones just to hide an incomplete parent. It is far better to have an incomplete parent and five working clones than to have no parent and five clones, four of which do not work.

Logiqx

by nailbomb » Mon Oct 30, 2006 7:32 pm

hi guys,

i'm glad you care about my suggestion, in fact i do appreciate your concerns, so i know you have tried to understand what i wanted to explain to you (mostly...) ;)

well, to keep things short i will try to reply to your statements instead of flooding you with even more confusing details.
OK, suppose a game has 5 clones. To which clone the main game's files will be added? Select one of them arbitrarily?
to that particular clone which requires these. if more than one does, pick one of those arbitrarily (to avoid duplicates, thats the whole point).
What about the main game's roms that do not exist in any clones? Discard them or just leave them in the main file?
if that would be the case just stick to regular split mode.
What purpose would be served by adding the MainSet's common roms to i.e. Clone1? Clone1 may then contain all the roms needed but Clone2 will still need another Set in order to work properly. It would not be MainSet any longer, but it would be Clone1. So what really is the gain in your idea?
you are absolutely right. the gain is that no incomplete titles would be enlisted, as there would be no archives of incomplete main sets, simply put an unmerged mode without duplicates.
Maybe the common roms should be copied in all clones ? (...)
well no - if you want this, thats unmerged mode + deleting the rest.
PS: congratulation for the desciption of the problem: Description, problem, solution, Even an algorithm... cool
have to admit, i am a software engineer myself, thats my kind of thinking :)
Huh? Isn't that un-merged mode?
you're right again, that's not what i meant...
Yes, un-merged when the main set is not complete and merged if it is complete.
almost. unmerged mode when not complete (w/o duplicates) and split if it is complete.
Nailbomb, IMHO, in that case RC should show C1 and C2 as green.
and again you are right - what i meant is that i do not need the main set itself, only for the clones - so why not integrating it in one?

ok, thank both of you for your responses - i'd like to add that one can do this manually, either using split mode and merging incomplete main sets to one of their demanding clones, or using unmerged mode and getting rid of the duplicates. both will do the trick, but would be nice if RC could do this itself...

bye

by Wanderer » Mon Oct 30, 2006 4:50 pm

RomCenter wrote:Yes, un-merged when the main set is not complete and merged if it is complete. :?
OK, so what nailbomb suggests is to not have a global un-merged or merged mode, but to depend on whether the specific Master is complete. Wow, this would certainly be complicated code-wise.
nailbomb wrote:Using "Split" i would get a main set archive that is required by C1/C2, but not playable itself
Nailbomb, IMHO, in that case RC should show C1 and C2 as green. If they are not playable, then this might be a wish for MAME and not for RC.

by RomCenter » Mon Oct 30, 2006 4:36 pm

Yes, un-merged when the main set is not complete and merged if it is complete. :?

by Wanderer » Mon Oct 30, 2006 4:10 pm

Hi Eric.
RomCenter wrote:Maybe the common roms should be copied in all clones ?
:? :? :? Huh?
Isn't that un-merged mode?

by RomCenter » Mon Oct 30, 2006 4:05 pm

Maybe the common roms should be copied in all clones ?

Anyway, I see the problem, but I don't think it is really an important one.
The solution is simple on paper... But it's different in the source code !

Merged, split or un-merged modes are statics. The database is fixed one and for all when you change the mode, then the status of each rom is re-calculated based on the new database structure.

Your mode is dynamic, it depends of the completness of the main set. It will involve more calculations for each rom analysed.

Even if you add a single rom in a main set, it could result in a lot of roms moved from clones back to main set.

PS: congratulation for the desciption of the problem: Description, problem, solution, Even an algorithm... cool 8)

Re: Feature request for the next version

by Wanderer » Mon Oct 30, 2006 10:30 am

Hi there and welcome to the forum. I don't know what Eric's response will be in your comment but i'd like to point out some difficulties in your idea.
nailbomb wrote:the solution:
if a set has one or more complete clones but an incomplete main set that only contains roms required by it's clones - just don't create the incomplete main set at all and store it's roms in one of the clones that requires these roms.
OK, suppose a game has 5 clones. To which clone the main game's files will be added? Select one of them arbitrarily? What about the main game's roms that do not exist in any clones? Discard them or just leave them in the main file?

Let's just leave those questions for a minute. There is another issue here. What purpose would be served by adding the MainSet's common roms to i.e. Clone1? Clone1 may then contain all the roms needed but Clone2 will still need another Set in order to work properly. It would not be MainSet any longer, but it would be Clone1. So what really is the gain in your idea?

Feature request for the next version

by nailbomb » Sun Oct 29, 2006 3:13 am

hi there,
first thank you for this nice tool of yours, it makes life alot easier!

my suggestion:
would you mind adding a fourth option to the rom structure settings, that would be some kind of mixture of "Split" and "Un-merged" mode?

explanation:
i do like each title to be in a single archive, so i prefer using "Un-merged" over "Merged" mode. Of course "Un-merged" mode wastes some disk space, because some roms may be stored redundantly. So i could go with the "Split" option to have some disk space saved, but there is a special issue with "Split" that i do really dislike...

the problem:
given a main set M and two clones C1 and C2 that share some roms from M, the "Split" option would store all roms of the main set in M and C1/C2 would only contain their additional roms. But what if i do possess all roms required by C1 and C2, but lack some roms from M that are not needed by C1/C2? Using "Split" i would get a main set archive that is required by C1/C2, but not playable itself - using "Un-merged" there would be no incomplete main set, but disk space would be wasted, because the roms from M would be stored in both C1 and C2.

the solution:
if a set has one or more complete clones but an incomplete main set that only contains roms required by it's clones - just don't create the incomplete main set at all and store it's roms in one of the clones that requires these roms. this would be like the best of both worlds (concerning "Split" and "Un-merged" modes) - no waste of disk space and no redundant archives.

the code:
i guess this should be really easy to implement, just duplicate the "Split" code (derive or copypaste) and at that particular point where your code determines if a main set has to be created, check that...
  • the main set would be missing some roms
  • there is at least one clone having all of it's roms available
  • the main set does not contain any roms that are not part of any clones
if all checks are successful just branch the code to distribute the mandatory roms of the main set (without duplicates) over the clones where appropriate, otherwise proceed as usual (in "Split" mode).

ok, i hope you get the idea and i'd be really pleased if you'd consider to pick this one up...

thank you!

Top