The new forum is online, hope you enjoy it!
what exactly do you mean with "import set names from text files"?
You mean you have a textfile holding set names (either line by line or somehow separated by a character?) and you want to use that as "Filter". So if your file holds "pacman" and "005" you want that the loaded datfile is limited to these two (plus their dependencies).
If that's the case, I could think about enhancing the filter (which currently does regex and xpath) maybe by entering something like "file:c:\temp\list.txt".
Or do you mean something else?
While some minor things come in here and there, I've spent time on writing the readme for the scanner. Actually I've combined the rebuilder with the scanner package so that only one readme is in the package describing scanner and rebuilder....
Two things I still think about are:
- should the backup folder be visually available (and required) or automatically chosen (and can be altered in the settings xml....like the temp folder, which is automatically something in your %TEMP% folder but can be changed)...I somehow prefer a visible available one....
- should the settings xml, and some created folders (scans, fixdats and exports) be moved to %APPDATA% by default. I still somehow prefer having everything in one non-uac protected folder...but most likely since I'm old fashioned...Surely I could do it by default in %APPDATA% and you could edit in the settings xml....
MAME on the otherhand creates it ini files in its folder, too....
Maybe I start with the old fashioned way.....I mean you're used to it when you used clrmamepro.......and we talk about a 0.0x version here..
So....comments are welcome....
Old cmpro can filter on driver status only.
With the new scanner (and xpath) you will be able to filter on anything inside the xml ;-)
When you talk about "labeled preliminary" are you refering to driver's status,cocktail or emulation attribute? Or all of them?
<!ATTLIST driver status (good|imperfect|preliminary) #REQUIRED>
<!ATTLIST driver emulation (good|imperfect|preliminary) #REQUIRED>
<!ATTLIST driver cocktail (good|imperfect|preliminary) #IMPLIED>
one possible xpath for the emulation attribute would be
xp://machine[driver[not(@emulation='preliminary')]]
or if you want emulation and status attributes being something else than preliminary, you can use
xp://machine[driver[not(@emulation='preliminary') and not(@status='preliminary')]]
the dependencies (needed parent/bios/devices) get added internally
ok....small wip mainly about filters:
one little thing on my to do list was supporting xpath for filtering, so I've added that and it gives you fantastic possibilities to filter on specific things..
The filter input field (or commandline attribute) is used for this. Currently it supports regular expressions for filtering machines on name only (see rebuilder readme.md). Using xpath filterings gives you more power. To use it, you need to prefix the filterstring with "xp:", otherwise it's the regular expression filter and your xpath expression needs to select software, machine or game elements.
So here we go with some examples:
Filtering a -listsoftwarelist output by only taking the Commodore software lists into account:
xp://softwarelist[contains(@description, 'Commodore')]/software
Filtering a -listxml output by selecting machines which have a baddump disk:
xp://machine[disk[@status='baddump']]
Filtering a -listxml output by selecting machines which have preliminary emulation status and Taito as manufacturer:
xp://machine[driver[@emulation='preliminary'] and manufacturer='Taito']
If you are familar with xpath, you already can imagine what you can do here. If not, learn xpath ;-)
Another thing with filtering is that you most likely want the dependencies included automatically. So you want to filter on a clone machine, but you also need the parent/bios/devices files included.
The filtering does that for you now, so if you filter on pacman, it will also include all the dependencies for you.
Attached are some screenshot parts which show some filtering for the examples above, also one showing the dependencies (including showing empty machines, which you already know as a feature).
On a side note I did some work on speed improvements, solving some thread safety things which should also positively affect the rebuilder core. And I found a way for handling the weird things like the samples of battles and homerun in a full merged environment...if you have no idea what I'm talking about, well, ignore me or check cloneof versus sampleof versus fullmerged).
So....tada...till next time
Time will tell. Tosec? Well, as long as they follow the xml layout of MAME I don't see a problem. I haven't thought about any 1G1R mode yet though. For now, a clean, small core is all I'm interested in.....
That sounds wrong (if I fully understand it), you're saying that the scanner adds files to unselected sets? How? By fix-missing? If a set is disabled it should not even complain about missing files nor should a fix-missing operation work on it. In full merged sets you may run into weird effects if you e.g. enabled a clone but got the parent disabled, then of course the "parent" set exists but only with the clone files....Disabling sets is a bad idea anyhow ;-)
Actually that idea came up right now while writing this post...and I definetly put it on my list. One thing is questionable though: Such a selector would only pick machines on their own. There is no "also include parent / clone / bios / devices"....but hey...I need something to do for the future....
