Please Test: Creating Custom Collections

ohmycommodore

...brother!

pjft

@ohmycommodore The idea is that you can create your own, in case they don't exist, and write whatever name you want to.

I certainly have one for games I play with my wife. And another for Backlog, and games I'm currently playing.

ohmycommodore

yeah, i got it. i just meant it could be an interesting collection to do in a theme, with artwork like mario, batman etc.

HurricaneFan

@ohmycommodore There is another post for standardized custom collection theme names.

Found it: https://retropie.org.uk/forum/topic/12024/themes-custom-collection-standardized-naming/49

chizzer

Absolutely loving this. It's the best new feature in Emulation Station for a long time. Many, many thanks pjft.

cyperghost

@pjft I just came back from holiday ... so the PR merge is a nice surprise ;D

During holiday I had the idea of usage of the Y-button in ES system selction. What do you think of setting the Y-button as quick access to custom-collections or to auto-favorites or do you think I will properly collidate if your are in editing mode in custom-collections?

Thank you very much for your work on ES. I can't add more to @chizzer comment

HurricaneFan

@cyperghost I'm confused on what you want the Y button to do.

Currently, When you aren't in collection mode, the Y button is the favorite button.

When in "add game to collection" mode the Y button is what you use to add games to the collection.

cyperghost

@hurricanefan You start RetroPie and are in the system view mode. Then press Y to get access to your favorite system. It would complete the X button function that chooses a random system - with Y you select the favorites. Not more not less

When in "add game to collection" mode the Y button is what you use to add games to the collection

Therefore I asked....

... do you think I will properly collidate if your are in editing mode in custom-collections?

I'm not sure if it's possible to get a function like this

namyzark

@pjft I love the ability to create custom collections. I was using @meleu's method previously, but I am really enjoying the ability to create these collections within ES.

I am also using @TMNTturtlguy's 'Change ES System' to have groups. This is where I have found a problem.

I have tried to 'hide' the systems and just show the collections on one of my alternate ES Systems. This does not work. While the collection itself shows, any games in the collection linked to hidden systems disappear from the collection. Soon as I add the systems back into the es_systems.cfg file and restart EmulationStation the games appear again in the collection.

Is there a way to resolve this?

Thank you for the option to create custom collections within ES. I do hope we can find a way to resolve this hiccup.

pjft

@namyzark hi. Thanks for your note, and glad you're enjoying it!

Unfortunately, ES is really only able to create collections or populate systems based on games he knows of. He only knows of games that he has loaded from the systems he's aware of, from the es_systems config file.

As such, the use case you're devising isn't really supported in this current setup. If he hasn't loaded the games into a system in the first place, he won't know where to retrieve them from, and he wouldn't know where to execute them in.

If that's your end goal, and the alternative methods work for you, I'd recommend sticking to them for the time being. Or maybe finding a middle ground if it's helpful with the current implementation.

If you'd like to let me know more about the use case (s) you have in mind, I'm always curious about those.

Thanks!

namyzark

@pjft

Use Case:

There are 5 people in my home. 2 are children, 3 are adults. Of the 5 only 1 of them is really technically inclined (yours truly). Many of these people want to play some of the same games (example, Pokemon for the kids).

Potentially, all 5 people want to play the same game without saving over each others saves. I know of 2 possible ways to accomplish this.
A) Save states - built in to ES, and if my end users were more technically inclined I might go this route. But we've already had fallout when one person 'accidentally' advanced the save state too far and saved over someone else's game. Since Save States, even for collections, save back to the original ROM location, this doesn't work well.
B) Create a folder for each system with copies of the ROMs that each user wants. I've been going nes_user1, nes_user2, etc. This, however, gets really crowded, really quickly, on the main ES screen.

So, my end goal, especially now that we had the collection option built in to ES, was to have a collection for each end user and hide all other systems. Then to have the option, using @TMNTturtlguy's Change ES System script, to move back to the 'Show All' systems.

I hope this clarifies my goal for you.

TMNTturtlguy

@namyzark yes, this is an issue with the new custom systems and my script. The script was created in conjunction with @meleu script to work with the es_sysyems.cfg file. It works very well. @pjft new updates do not use the es_systems.cfg file, so it is not completely compatible with the change es_systems script. As you have noted, the script still works, but the custom systems created through the new update won't work. There is nothing I can do to the script to change this either, so you have to decide one direction or the other, keep using @meleu and my scripts which work fine, but take more time and knowledge to set up, or use @pjft new update which works extremely well and is very easy to use and modify.

pjft

@namyzark Thanks. That does clarify the use case.

Indeed, your use case seems to encompass a bit more than ES at this stage, so let me try to break it down.

Showing only the games organized by collections, but not showing the original ones.
Saving separate save files per profile.

At the moment, none of these are supported as main use cases. Supporting #1, while not impossible, is probably something that won't be pursued in the short term at least. While I understand the validity of it, it seems to be a "niche" use case, the need to hide the old systems. Not that there's anything wrong with "niche" in any way - it's just a matter of making sure we balance out the effort and usability of ES for the wider audience while not bloating it with things not many people use (and I'll be the first to claim I have a hard time doing a great job at that).

That would probably be better suited to something like "Kiosk" mode that @zigurana built in the past, though not fully the way it currently exists in. Or maybe "user profiles" - even though for that definition to be consistent, it would probably make sense to be applied across the entire "platform" (ES, emulators, Settings, saves, etc) otherwise it's just broken. So that's a significant undertaking if we go down that last route. An interesting one, for sure. An analogy is that that's kind of like PSN user accounts, where you can share games and keep your own data separate. We are, however, at the cartridge stage at the moment, though, where you have to share your Zelda cartridge with the other people in the house, and hope they don't overwrite your saves.

If we'd want to come up with ways to attempt to achieve that, off the top of my head what comes up is:

Try to use symlinks for the ROMs that would be shared by multiple users, and see if that actually stores different saves. I think someone in the forums was going to test that assumption. It could certainly save storage space.
I don't know if @TMNTturtlguy 's and @meleu 's scripts allow you to hide the systems and just keeping the collections, but if they do I'd recommend sticking to that. At worst, create copies of your system ROM folders with symlinks, per each user (assuming the save states would be kept separate).

I know, not ideal, but these are the only alternatives at the moment I can come up with. Hope these help.

incunabula

@namyzark One solution might be to clone the image you have onto several different micro SD cards (1 for each user) and have them swap it out as needed. If you have a large game collection you could host the roms on a NAS drive and use smaller (cheaper) SD cards to hold just the base retropie install and save games.

cyperghost

@namyzark
What do you want more? A savegame system per user or a system view per user?
I think the system view per user is doable through the custom collections.
Create collections like
Name 1 - Favourite GameBoy
Name 2 - Favourite GameBoy
...

@pjft
I asked for adding Y button for quick accessing custom-collections do you think this can be also usefull as "open a custom collections after ES startup"?
Optionally the Button B can be locked.... So no escape to other systems!

TMNTturtlguy

@cyperghost

What do you want more? A savegame system per user or a system view per user?
I think the system view per user is doable through the custom collections.
Create collections like
Name 1 - Favourite GameBoy
Name 2 - Favourite GameBoy

The issue here is that they will link to same rom and the save states will be overridden. In-fact, this will happen no matter what use case is used. The only way to avoid this is to have multiple versions of the same rom saved so each user has their own rom. Whether you symlink or use the built in ES system, they all use one ROM and therefore the users will be playing the same game and same save states.

cyperghost

@tmntturtlguy Yes... I know.
My intention is the following! But I won't code this otherwise my wife will decapitate me!!!

Create Favourites for every user as collection. That's an easy approch as collection files are simply txt files.
Create a small script to set an active user to /home/pi/currentuser.txt ... It contains username "Julia"
readout currentuser.txt ... and set user "Julia"
3.1 Julias collections are stored in a zip file which contains (Julias - GameBoy.cfg, Julias - SuperNES.cfg).... We extract Julia.zip...
3.2 Restart ES to load collection only for Julia
3.3 Load a ROM from Julias - GameBoy collection (Pokemon GOLD for GB)
3.4 runcommand-onstart.sh readout /home/pi/currentuser.txt to locate active user
3.4.1 runcommand-onstart.sh extracts zipfile "Julia_Pokemon Gold.zip" there are all files stored execpt the ROM, you can get romname with parameter given by runcommand.sh
3.4.2 Launch GB file Pokemon GOLD with Julia's savegames and SRM state
3.4.3 After 5 hours of intensive gaming Julias ends the game
3.4.4 runcommand-onend.sh stores all files to zip exept the ROM itself to "Julia_Pokeman GOLD.zip"
3.5 Start the script again and chosse annother user "Vika"
Replace Julia with Vika and start with 3.1

Got it now? It's just an shematic of how it can be done. I made nearly the same approch here to get all DOOM Wad files and it's savegames in one folder. Instead of WADFILE we will rather use USERNAME

pjft

@cyperghost I saw the suggestion, and thought a bit about that.

I'm not considering implementing that. The custom collections system is always at most 4 systems to the left of the first one. Also, the Y button is semantically associated with "toggling" a status while in the gameview, I don't feel there's a need to turn it into a navigation button in the system view.

Cheers.

namyzark

@incunabula can't do that. The SD Card holder and reader on the Pi stopped working 'correctly' less than 2 weeks after I purchased my pi. I have a fix in place, but it is inelegant, and doesn't work well for 'easy' removing and reinserting cards.

@cyperghost - savegame system per user

@pjft is correct. With custom collections being so close at hand I have found an alternative. My answer is simple, although slightly annoying for the 'in house IT guy'.

Create sub-folders in each primary game for each user in each system (only if needed)
Make copies of games that each user needs their own save for into each users system sub-folder. Luckily space is not 'too much' of a limiting factor here
Create favorite links to these sub-folders for each user.
re-scrape all these 'new' ROM images
Add new games to sub-folders as needed
Repeat ad-nauseum

I'll still have 'too many' folders in the system list. But, since the 'custom collection' folders are so close at hand on start up, it becomes less of an issue since they do not have to scroll through them. The big issue here is peace in the household can resume with no one 'accidentally' overwriting someone else's save files, provided they stay out of each others Collection and user folders.

cyperghost

@pjft Thank you so far :) You have done a lot of improvement to ES and I'm very gratefull for this ;)

But what do you think about a tweak to select one system and open it at ES start?
So you start ES - GameBoy was setted as favourite starting system, and the gamelist menu of GB is opened?

@namyzark
Okay unique savegames ;)

An unique game-saving system per user selction is really easy. Get in touch with this topic
First you need zip support so install zip via
sudo apt install zip

RetroPie offers three methods to run scripts.

runcommand-menu can be entered if you press any button if the grey loading box appers, then you go to Option "User Menu" and there you can change user!

runcommand-onstart.sh will likely look like that and will extract user_savegame per rom (libretro saves and ROM battery saves) from zipfile if a user is correct setted.

#!/bin/bash
# Example of how multi user savestate can be realized
# cyperghost 08/22/17
# untested and written out of mind!

  if  [[ -e "/home/pi/user.txt" ]]; then
      username="$(sed -n 1p /home/pi/user.txt)"
      rompath="${3%/*}"
      romname="${3##*/}"
      cd "$rompath" && unzip -qq -o "$username_${romname%.*}.ZiP"
  fi

runcommand-onend.sh will likely look like that, this will archive all savegames in archive with username. Files will be removed after merged into archive!

#!/bin/bash
# Example of how multi user savestate can be realized
# cyperghost 08/22/17
# untested and written out of mind!

  if  [[ -e "/home/pi/user.txt" ]]; then
      username="$(sed -n 1p /home/pi/user.txt)"
      rompath="${3%/*}"
      romname="${3##*/}"
      data="${3##*.}"
      cd "$rompath" && zip --exclude=*.$data* -mj "$username_${romname%.*}.ZiP" "${romname%.*}".*
  fi

runcommand-menu will likely contain one file for each user
Username is Julia.
So julia.sh looks like

#!/bin/bash
echo "Julia" > /home/pi/user.txt

We need a "DEFAULT USER" that removes user.txt
default.sh

#!/bin/bash
rm /home/pi/user.txt

~~That's all untested and written out of my mind!~~
Updated: It's tested now and works!
See this as a bare way!

EDIT
@namyzark
Well I had annother idea and tested the bash files... There was just one small error in that is elimanted now. So there here it is: Multi User support for savegames!