Please add a portable option
Hey there! It's your lucky day as QuickPlay is entirely portable and has never used the Windows Registry at all. You can just plug in that USB drive! If you need more help please join us over at https://forums.quickplayfrontend.com
Please add a portable option
Media panel background
[multiloader] mod load command for overrides...
[efind] correct override position mistake in CD-i
[efind] additions for modern emus and some amendments to calls
[icons] switch icons
[mame filepaths] seems to be an aborted attempt to split out functionality from fMameOptions
Sorting order lost after removing orphaned ROMs
Thank you for the reply. I actually prefer the way Quick Play looks too, but seeing a gallery of screenshots is useful when you're going through a full set. Anyway, this is just a suggestion for the future.
I must admit I'm not planning on this, but in the future it might be possible as an easy-win. The thing QuickPlay seems to do that other frontends don't is datagrid-style view with all the search and organisation possibilities you get that comes with that, and the grid combined with the media panel is a pretty fundamental part of how QuickPlay works. With new technologies it could be pretty trivial to turn the grid into this kind of shopfront as a view, but atm don't hold your breath! I do think...
Grid layout
Cancel/revert renaming with ESC
To give more details to this request. In Quick Play, I think there are 3 ways to use IPS files, all are accesible after right clicking the rom that has already been added, in this example, I'll use Super Metroid: You can patch your file and create a new patched rom, which I never use and is not related to this request, or you can link and IPS file to a rom, and this is the one I think it could be upgraded if possible. So when you select this option, you will be prompted to name it (which can be left...
If this would take too much time to implement, I can just rename the games manually. It'd be nice to follow the same sorting scheme as Windows, though (Example [A] > Example 2 [A]).
Yes. What about showing just the Name and System columns and making them uneditable for virtual folders?
yes numbers sort higher than an open square bracket without some custom sort algorithm e.g: https://groups.google.com/g/borland.public.delphi.language.delphi.general/c/NWJ83Xc0OjQ?pli=1 https://stackoverflow.com/questions/15318304/delphi-customsort-with-numbers-and-letters There are some ideas here though: https://stackoverflow.com/questions/52428793/sort-function-problem-with-strings-containing-square-brackets
Yes I can - my theory: a change to Virtual Folder columns has unexpected effects on the previously edited (real) romdata's column selections (often it changes to match the virtual selection, but sometimes, depending on the fields chosen to hide/show, the columns selected/deselected don't quite match up). Can you confirm I've got that right or not?
mass-add IPS files
Sort punctuation before numbers
does the 'System' that gets added to a normal folder persist after you close and open QuickPlay? Yes. Does it only affect the folder you switched to after the virtual folder, or does it affect all normal folders? It seems to always affect only one of my normal folders in a random way. Can you reproduce this?
Well, I actually like the way they're displayed. The background with the magnifying glasses makes it clear to me that I'm not seeing one of my normal folders. If you feel that's not enough, what about adding a bar at the top or bottom with a reminder that the current view was generated automatically from a search? Something like: This list was generated automatically from a search. Edit query
Yes absolutely thanks for making that very clear! You're absolutely right that's a job to do: 'normal' folder options that don't apply should be removed, 100%. But I still think there is a 'misleading' aspect to the virtual folders, because even if we remove these options we are STILL left with effectively pre-made quieries pretending to be normal romdata folder views, and its still not self-explanatory that there is a difference in use case and functionality - making them unnecessarily complex to...
Yes absolutely thanks for making that very clear! You're absolutely right that's a job to do: 'normal' folder options that don't apply should be removed, 100%. But I still think there is a 'misleading' aspect to the virtual folders, because even if we remove these options we are STILL left with effectively stored procedures pretending to be normal romdata folder views, and its still not self-explanatory that there is a difference in use case and functionality - making them unnecessarily complex to...
Changing search/virtual folder columns affect normal folders
I undertand what you're saying, and does the 'System' that gets added to a normal folder persist after you close and open QuickPlay? Does it only affect the folder you switched to after the virtual folder, or does it affect all normal folders?
The biggest issue here is not the changes are reverted, but that normal folders are affected unexpectedly after you change the columns in a "search" view.
Hey, Tony. Since edits made from within the virtual folder aren't saved, you could remove the Rom Properties context menu entry altogether from virtual folders. Remove ROM from Romlist and other options that don't apply to virtual folders should be omitted from the context menu too. The terminology isn't misleading to me. It's just that these options are available but don't work.
Hey, Tony. Since edits made from within the virtual folder aren't saved, you could remove the Rom Properties context menu entry altogether from virtual folders. Remove ROM from Romlist and other options that don't apply to virtual folders should be omitted from the context menu too. The terminology isn't misleading to me. It's just that the options are available but don't work.
Hey, Tony. Since edits made from within the virtual folder aren't saved, you could remove the Rom Properties context menu entry altogether from virtual folders. Remove ROM from Romlist and other options that don't apply to virtual folders should be omitted from the context menu too.
Hey, Tony. It seems that you misunderstood my report. For example, I created a search/virtual folder for "Mario" and then used it to change the game type of all games at once across different systems. I expected to see that game type when I opened the static folders for each console, but the changes weren't saved. Since edits made from within the virtual folder aren't saved, you could remove the Rom Properties context menu entry altogether from virtual folders. Remove ROM from Romlist and other options...
Hey, Tony. It seems that you misunderstood my report. For example, I created a search/virtual folder for "Mario" and then used it to change the game type of all games at once across different systems. I expected to see that game type when I opened the static folders for each console, but the changes weren't saved. Since edits made from within the virtual folder aren't saved, you could remove the Rom Properties context menu entry altogether from virtual folders. Remove ROM from Rom list and other...
Hey, Tony. It seems that you misunderstood my report. For example, I created a search/virtual folder for "Mario" and then used it to change the game type of all games at once across different systems. I expected to see those game types when I opened the static folders for each console, but the changes weren't saved. Since edits made from within the virtual folder aren't saved, you could remove the Rom Properties context menu entry altogether from virtual folders. Remove ROM from Rom list and other...
Hey, Tony. It seems that you misunderstood my report. For example, I created a search/virtual folder for "Mario" and then used it to change the game type of all games at once across different systems. I expected to see those game types when I opened the static folders for each consoles, but the changes weren't saved. Since edits made from within the virtual folder aren't saved, you could remove the Rom Properties context menu entry altogether from virtual folders. Remove ROM from Rom list and other...
[images] cover backgrounds thanks Sintanan
[minimise style] bugfix that was breaking this...
added release changelog
up version no.
LIB DIR ADDED TO CODEBASE...
LIB DIR ADDED TO CODEBASE...
[romlist] relabel 'delete rom'...
60de1 - fixed https://forums.quickplayfrontend.com/viewtopic.php?f=10&t=1337
[romlist] relabel 'delete rom'...
[romlist] prompt before clearing romlist
[open dir] properly escape filename...
[joypad] incorporate Ulaos code to test...
add timer to stage
update QPNode.exe
Import/Export Custom ROM Data extend rom properties
fixed in 15b14fc86fb, however note theres a corresponding export of roms that would benefit from having the same treatment and I did not do this
[export] #49 - added name and comment to ini export...
[mame] fix bug with filepath logic...
[mame] basic filpath printing qpmame executable...
[mame] remove prototype mame filepath form...
[mame] readonly mame emu in mfm printer...
[mame] finish mame emu hardcode - softlist printer...
[mame] start to change mame emu dropdown in printers...
[mame] finish replace emu edit in 1st mame printer...
[mame] trim mame.ini's rompath properly...
[mame] trial popup preventing invalid filepaths...
[build] trial a test qp install...
[mame] start to build mame rompath logic...
[mame] extra dir path into class variable...
[mame] readonly combos on mame options form...
[mame] improve gatekeepers for xml scan
[mame] be honest about scan requirements...
[mame] clear up mame exe name and path...
[mame] clear up mame exe name and path...
[mame] rompath now looks up on mame exe change...
[mame] save all settings on destroy mame opts...
[mame] rompath clearing logic shown workking...
[mame] persist dropdowns for mame rompath types...
[Mame] add mameRomPath setting...
[mame] all rompath combos display all paths...
[mame] qpnode now returns real mame rompath
[mame] rompath now in a dropdown...
[mame] supply a mame path to backend...
[mame] print rompath in mame options form show...
[mame] scaffold rompath-getting logic in filepath opts
[mame] scaffold call to node api
[mame] wire up mame xml edit in filepaths form...
[mame] filepath rads and chkboxes live on form...
[mame] wire up mame emu combo in filepaths form...
[mame] filepath opts to tab group in mame opts...
[mame] filepaths...add action for menu...
[mame] mame filepaths form named and labelled correctly...
[mame] scaffold mame filepaths form...
Synctool - case sensitive computername
see comments against #52, given the implementation, we should work out what the desired behaviour should be thanks for these btw, sorry for delay, just coming out of a long period of covid-conditions-with-young-children, which hampered hobby dev efforts considerably!!!!
this happens because search folders aren't stored as romdatas at all, they are akin to stored database quieries, with an attempt made to render them as if they were romdatas. Course this can be helpful since the results are generated fresh each access, but unhelpful when you want to reify the results So, given this, what would you like to happen? I guess ultimately the terminology is misleading and there should be a 'search' and the ability to save both the search AND print off a timed/dated res...
[qpnode] fix minor pkg version of qpnode...
[qpnode] fix issue with native module...
[qpnode] upgrade qpnode from node 12 to 14...
Changing search/virtual folder columns affect normal folders
Changing ROM properties in a search/virtual folder has no effect
[qpnode] upgrade qpnode from node 10 to 12...
Synctool - case sensitice computername
Mametool - can't capture cmd output