Ideas to Improve QuickPlay

[butter100fly]

What happens if you go to 'run rom with dialog' and then copy/paste the command-line QuickPlay is going to call into a CMD where you've CD-ed to QuickPlay's root folder? Does it run then? What is that command line? and chris' suggestion is good: what happens if you move one level in your hierarchy and try it there, might that help?

I've never used the folder migration wizard, so you're saying it changes the paths of all three of the areas we discussed?:
1) ROM references in romdata.dats (what about favourites and search results (they are the same file format)?
2) Links that have been made in the media panel (i'm suprised by this, because the media panel might contain paths from any drive, anywhere, so there would be code that says "IF the root drive of this entry is the same as the root drive that quickplay is installed on, then change it to Y", which would have been very forward thinking)
3) Emulators in the emulators.ini

I had thought the folder migration wizard was only about romdata.dat folders....

[shrewd_opinion]

you should include more magic and wizards.
I want to feed unfiltered 0-day warez into quickplay and output a structured library populated with metadata, artwork and videos preferably in the form of a gamepad-driven high-fps ui caching data from a system-service.

So, I would suggest you figure out how to get that done because anything less pretty much might as well be screaming binary into night.

I really don't have time to sort through a bunch of games that aren't ready to be played immediately, which is supposedly what quickplay is implying through its name.

Smell ya later.

[butter100fly]

Yes this doesn't sound like your sort of thing shrewd_opinion: i'd suggest you stick with LaunchBox or HyperSpin

[AFaustini]

Try changing it from ..\ to just .\

It' doesn't works and also makes the roms unavailable.

What happens if you go to 'run rom with dialog' and then copy/paste the command-line QuickPlay is going to call into a CMD where you've CD-ed to QuickPlay's root folder? Does it run then? What is that command line? and chris' suggestion is good: what happens if you move one level in your hierarchy and try it there, might that help?

Occurs the same inside qp. It doesn't open the game. I have some suggestions to fix this.

I've never used the folder migration wizard, so you're saying it changes the paths of all three of the areas we discussed?:
1) ROM references in romdata.dats (what about favourites and search results (they are the same file format)?
2) Links that have been made in the media panel (i'm suprised by this, because the media panel might contain paths from any drive, anywhere, so there would be code that says "IF the root drive of this entry is the same as the root drive that quickplay is installed on, then change it to Y", which would have been very forward thinking)
3) Emulators in the emulators.ini

I had thought the folder migration wizard was only about romdata.dat folders....

The folder migration wizard changes all the 3 areas.

[butter100fly]

thanks for confirming. i'll look into this as a priority

[shrewd_opinion]

When QP is first run, a wizard detects emulators and then ROMs, and after this I'm greeted with a UI which has a list of systems/folders on the left-hand side containing all the detected ROMs. This seems to work well, however when I select a ROM from this list and choose Run ROM from the r-click menu, a dialog box appears telling me there is no linked emulator.
This is a problem.
There are several emulators that should be linked to the ROM which apparently have been detected, so why would QP not automatically link the them?
Enabling auto-linking would go a long way in generating some appeal for what is otherwise a very comprehensive application.
(also, you're right: I am an asshole, but I was totally kidding around in my other post.)

[butter100fly]

hi again

didn't think you'd return to QuickPlay! i was mistaken then

The problem you raise is due to the fact that we don't type ROMS to particular systems with a multi-directory scan:
* firstly, without a lot of random string assumptions on directory locations, we have no way of knowing which system the roms we just multi-scanned are for, while some roms have helpful extensions that give a hint, many do not, for instance any CD/DVD game or any MAME game. If we concentrate on just those roms that have file extensions, these are often collected in zips, querying each zip would add massively to scanning time, and we'd inevitably find zips that contain files with >1 file extension. Add to this that rom file extensions aren't policed, so there are file extensions that >1 system use
* secondly by definition the multi-scanner can scan roms for a number of systems, so we can't ask up front which system you intend to be scanning for
* thirdly any individual directory path on your filesystem might contain roms for different systems in it (this is one reason why the entries in the left-hand side roms sidebar do not 1:1 correspond to systems, you can have a sidebar folder that contains games for multiple systems (for instance you could have a 'shoot-em-ups' sidebar folder)). How can we assume what system each rom on your filesystem is for?
* fourthly, even if we did try and determine the system of each rom we multi-scanned, which of the emulators for that system that have been found on your hard-drive would we assume you want to run it with? There might be many emulators for any particular system, and randomly choosing the first emulator in the list may not be the right one to run the rom

So those are some reasons why, when we multi-directory scan, even if you have some emulators you found, you'll need to manually associate the roms with the emulator you want to run them with, this is easily done with CTRL+A and a right click, and selecting an emulator for a rom associates it with a system, which then allows you to to try and run it with any of the other found emulators for that system. I wouldn't like to try auto-linking because it would inevitably be very brittle, assumptive/opinionated, incorrect and partial.

The problem is avoided if you use one of the other rom scanning methods (right click menu), since you have to choose up-front which emulator you wish to run the found roms with.

So the solution to the problem you raise might instead be to somehow lower the expectation that you won't have to associate an emulator to run a rom, you're right that following the wizards makes you kind of expect magic to happen, the magic needs one more step....I guess we could invoke another wizard when you click on an untyped rom, which first asks for the system and then asks for the emulator, but I wouldn't then like to assume that as the emulator to use for the rest of the romlist

[shrewd_opinion]

Any wizard that you create to facilitate the ease of use is going to require some decisions, such as prioritizing emulators, so you're somewhat correct in your assessment that "it would inevitably be very brittle, assumptive/opinionated, incorrect and partial".
Yeah, there are going to be some people who have their libraries as one single archive, and others who have genre-specific folders of ROMs for different systems. For my own program, I have opted to use some fuzzy-logic and exclusive extensions as a means of facilitating automation.
Any efforts made in this general direction assume a number of things, however...those who are taking advantage of wizards are likely to have a library well within the scope of established parameters to have acceptable accuracy, and for the remainder they always have the existing toolset, right?
The idea is that a loaded shotgun is better than a sniper rifle with an empty mag and it really will keep people around if they're able to get off a few shots right out of the gate.

[butter100fly]

Sure, so what is your program? I guess its not in Delphi?

I think the main issue would initially be with archived romsets: the number of calls to 7zip in order to read and collect the file extensions of every file in every zip in a romlist. Quite aside from any decisions that would need to be made on the results, the scanning itself could prove somewhat excrutiating, particularly as QuickPlay's internal 7zip dll may need retiring:

viewtopic.php?f=3&p=1504#p1504
https://sourceforge.net/p/quickplay/bugs/37/
https://sourceforge.net/p/quickplay/fea ... quests/58/

[shrewd_opinion]

i write skeletonkey:http://romjacket.github.com, in ahk.
searching within archives isn't too taxing.