Please Test: Adding support for "All", "Favorites" and "Last Played" systems

[pjft]

@lilbud well, I really wanted people to make sure they knew what games were their favorites. Is two minutes a long time? :P

That's obviously a bug, great catch. Thanks!

[lilbud]

@meleu Yeah, got it to compile. Installing supposedly fails, as I can't set it as the default, but it runs in the command line perfectly fine.

Here is the error log

https://ghostbin.com/paste/gnnfz

[cyperghost]

@pjft That is exactly what I thought... Thank you for explanation.
The code for future version without gameslist.xml is already made by me.

I "created" the FAV-file format. The FAV-file acts as descriptor of path and emulated system. It stores the info about ROM-path and emu-system to use in one simple file.
With this info you can load any system from any place. I'm sure it's easy to implent into your branch and this would offer all users a way to use favourites.

So maybe you can take a chance and have a look to the BASIC soource-code and translate it to C++. My suggesetion was to first create this in C but then I realised that heavy string manipultion is a better task for annother language.

Take this only as suggestion how a fav-system can be installed without using XML.

Or... that would be my deepest wish you can create a call to a Bash-file by pressing Y-button with marked ROM in menu ;) So you give user the decision what happens by pressing Y-button and maybe you can expand it to X-button also ;) What about this?

How a bash file call can be established can be seen under Prerequisite #5 of topic lfl-create v0.85

[meleu]

@lilbud caught the "bug": you're running the script as root! I'll change the script to avoid that. Thanks.

[UDb23]

@pjft said in Please Test: Adding support for "All", "Favorites" and "Last Played" systems:

I'm working with @UDb23 to create these in Carbon,

Next Weekend you'll get a proposal and "beta" version of the required SVGs ;-)

[lilbud]

My switch logos are already done

[cyperghost]

@lilbud Nice work ;)
I've created favs buttons for IO only maybe @mattrixk can design a set of new one

[lilbud]

What would the es_system.cfg look like for favorite, all games and last played?

[pjft]

@lilbud

There's nothing on es_system.cfg, as they're not hardcoded systems.

If you're looking for the theme folders, they're supposed to be auto-allgames, auto-lastplayed, and auto-favorites.

I've fixed the bug you ran into (thank you!). After launching a game and coming back to ES the application timer starts from zero, which meant that the fade animation would pretty much run until the application got to the same "time" as it had taken for you to get that particular popup to show the first time around. Funny one.

Will update the PR shortly.

[pjft]

@UDb23 No pressure, please - it was more to reassure people :)

[mattrixk]

@cyperghost The logos on IO are just the Carbon SVGs, recoloured to be bi-colour, I didn't actually make them.

[pjft]

I have updated the PR and my branch with a fix for @lilbud 's reported bug! Thanks for sending it over. :)

[lilbud]

@pjft I have updated the dark theme to support this custom build. There are 2 extra backgrounds which add the screensaver prompt (bg-pjft.png) and Options + Favorite prompts (systembg-pjft.png) Both have been added to the Switch-Dark repository

[ohmycommodore]

A great, functional idea! Looking forward to using this!

[cyperghost]

IO theme was pushed to Virtual Systems runlevel :)
https://retropie.org.uk/forum/topic/3853/io-new-theme/41
also available on Github

[pjft]

@cyperghost Sorry, I missed answering this earlier! Thanks for the work here and for the suggestions.

Don't take any of what I'm saying the wrong way, as the internet can lead to wrong interpretations, so bear that in mind when reading this :)

I briefly considered it but I decided not to translate the code to C++. It's not because it isn't good code, but because I don't think it's the right approach here, as well as that porting code is in my opinion a lot more effort than writing it from scratch. :) That's also the same reason I don't think I'll be implementing the "Y-button" to call a bash-file either.

My belief is that ES should be kept simple and accessible for all users, and most of these developments, while great for the community, realistically are only accessible to people who are a bit more advanced in their technical abilities than needed to enjoy RetroPie.

• In the current case, we don't need a FAV file as ES knows how to execute any game it has loaded. We only need to store a ROM path, and rely on es_systems.cfg to know, based on the file's path, how to execute it.
• The user should also be able to create collections of games without having to resort to manually creating text files in the command-line or an editor, or creating symbolic links in separate folders, or duplicating ROMs in their system.

I know we do it because we enjoy the challenge and tinkering :) But in doing so we are restricting the appeal and openness of RetroPie as a platform to a smaller audience.

My goal - after this is eventually merged - is to continue developing it to allow users to manage game collections (that's likely the external final name for "virtual systems" :) ) inside ES.

They will be based on unused existing folders in the user's theme, as ES has a 1:1 relationship to "system-level entries" and "theme folders". And I don't want users to shoot themselves in the foot by creating collections that will not be themed and look ugly as hell. This will address most of the use cases people have been playing with, when creating a "megaman" theme folder or something, and then packing it with megaman games, or "fighting", "sports" or whatever.

Creating custom collections (without an existing theme folder) is out of scope, as there are too many sub-optimally defined user flows, and the end user experience will always be less than desirable.

Hope this clarifies the roadmap and scope I have in mind for these developments in general.

If there's any critical use case I'm missing, please anyone let me know, and I'll take it into consideration!

Thanks.

[cyperghost]

@pjft I totally agree with you.
One usecase is left - if you use no XML file and disabled parsing of them ;)
That's an easy option to speed up the whole ES booting and shutdown process....

But as you said and I already understand... The usecase of the usual user and the user who wants to look what all can be done stands in no relation. Maybe 99:1 and if in future version it is possible to just add new system the relation changes maybe from 99:1 to 999:1.

So thanks for your and @meleu words.

[pjft]

@cyperghost

What I said earlier is that if you don't use gamelists, you can't really benefit from Favorites (as favorites relies on the metadata) and last played (as it relies on the "last played" date).

That being said, you'll be able to add any game to any custom system, and nobody forbids from creating your own custom collection of "favorites", based on a separate theme folder.

That will not be in any way related to gamelist data - we'll store those separately, in files with only the file paths.

Sorry that that wasn't clear :)

[cyperghost]

@pjft Take it easy.... it's clear enough for me
So how does this files look like (filename) and what is the content of these? Just the file path? How can runcommand to be used to load the correct system?
As you see I was in the same situation ;)

[pjft]

@cyperghost Just the file path.

As I stated, ES has the system settings in es_systems.cfg for the respective folders where the source roms are. No new folders need to be created. No files need to be moved around.

I don't plan on creating yet another file type that's redundant.