Delete artwork files associated with certain roms?

[nullPointer]

Hmm . . . I'm not thinking that a filtering tool should add content to the GameEx.ini at all; I'm hoping it could do quite the opposite. I envision that the filtering tool would parse a list of excluded ROMs from GameEx.ini. From there the tool could move or delete the ROMs in the excluded list along with any associated artwork. When it finishes transferring files the tool could update GameEx.ini to remove any listings for ROMs which were previously excluded from GameEx, but which now no longer exist at all (having just been moved or deleted).

This comes around full circle to the elephant in the room. The filtering tool can’t (or at least shouldn’t) transfer any parent set where the user still wishes to retain a clone of the parent set. And even that only holds true where the end user is utilizing merged or split/merged sets. If the user has unmerged sets a filtering tool can remove parent sets unencumbered by interdependencies between ROM sets.

Artwork gets even more convoluted since sometimes it’s named in relation to the parent and sometimes it’s named in relation to the clone set.

Once again though, it’s not my pig, not my farm (as we say out west). I’m confident that Adultery can/will come up with something great. So I’m certainly not saying, “Hey write an app exactly like this,” just throwing out some ideas for consideration.

Edit: Wrote split or split/merged when I meant merged or split/merged

Edited February 21, 2012 by nullPointer

[Draco1962]

Agreed. The only thing I can see using the gameex.ini file for at all is, for the purpose of a plugin, is to provide the ROM and media paths data. Other than that, the data contained in catver.ini can help to create a list based upon the categories and the rom names, which in turn can be used to manage (remove or delete) the selected content. BTW, is that a pink elephant?

[Adultery]

How bout this:

Proggy deletes roms and assets. Plugin finds and removes assets based on GameEx's filter list at startup. Neither dependant on the other.

Or maybe the proggy can accept command line arguments and the plugin passes them and forces a list update.

[nullPointer]

Sounds like a winner to me! Option B sounds pretty neat in that you could share common code between the two components (I'm thinking about the modules responsible for moving files around), but either way would be pretty sweet. Thanks for considering this program!

[Adultery]

I have a few ideas for sure. Gotta finish my current project first though (which is close).

[Draco1962]

In the end, the prog should be "So easy a caveman can do it..."

While we are generally "Newb Friendly," I think that the the bulk of the progs available tend to not be and the assumptions are that, if you want to enjoy system emulation, then you must do lots of hard work and learn how to X, Y, and Z.

The reality that bites us in the ass and turns away new blood is that we have a generation coming into the ranks that have never touched a command line and experiences are GUI-centric. I don't mind command line options as an "advanced option" for experienced users that want to make additional tweaks to the process. To have the basic options to select which media to move or delete after setting up the paths and the categories and generating a list would be great.

Basic options should follow KISS (and not the band). Advanced options would have command line options available.

[Adultery]

Well its as complicated or as simple as the user makes it. The plugin would send the CL, the user would only need to tell the plugin where the exe is.

Ad much as I hate noobz, I try to make things simple or advanced. Lots of options ate great as long as the options are optional.