New Idea/Help Needed - es_systems.cfg Selector

meleu

@cyperghost said in New Idea/Help Needed - es_systems.cfg Selector:

I commented your push

and I replied there. :)

cyperghost

@meleu
I commented my post above. Got a hard week with some nightshifts.
You're right in moving system files ... therefore I still do not recommend not to copy/delete those files I would rather link those.

The original es_systems.cfg should be kept as es_systems.bak.
I also think that this file will be automatically be copied if es_systems.cfg gets lost. So it's alwyas fail safe!

I think it's just the right moment to thank you for investigate even small bash sniplets. I never used bash and I always learn lots from you and I appreciate the help from you (and lots of others users here!)

Öhmm... a downvote? I think you are using your mobile phone :D right?

meleu

@cyperghost said in New Idea/Help Needed - es_systems.cfg Selector:

a downvote? I think you are using your mobile phone :D right?

Damn! Sorry, it was an accident (again)! 😌

cyperghost

@meleu

Damn! Sorry, it was an accident (again)! 😌

De nada

Isn't the right thread here... How are your achivements in Terranigma?

FlyingTomahawk

Great that you guys got all figured out.
So what and where can I download this? I mean the fixed version.

cyperghost

@FlyingTomahawk
That's @meleu tidy version.
https://github.com/meleu/change_es_systems/tree/patch-1

FlyingTomahawk

@cyperghost

Thank you.

TMNTturtlguy

@cyperghost @meleu thank you both for your help. Unfortunately my schedule remains very busy with little time to actually sit and work on my pi. I will take a look at all of this, but it looks awesome!

@cyperghost i will look at you other methods, but I am not sure why you feel my method is "dangerous" as this works with Es_systems.cfg that are copied and moved to a new location. If they get deleted by accident, the main unedited es_systems.cfg should always remain in its original location and be used by default if the .cfg file does not exist in the alternate location.

cyperghost

@TMNTturtlguy It is dangerous. Think about someone loads your script from your repro and starts it but it is not configurated manually. Then he looses his es_systems.cfgbecause all funktions codes do rm /opt/retropie/configs/all/emulationstation/es_systems.cfg first and then copy the changed files (if it exists) :)

So it may be better to get all config files in one folder and just symlink them. Is there no destination file present then symlinking does not work. That should minimize the risk in breaking something. The risk now is at all minimum.... if you know what to do :)

@cyperghost @meleu thank you both for your help. Unfortunately my schedule remains very busy with little time to actually sit and work on my pi. I will take a look at all of this, but it looks awesome!

Thank you in your effords for the nice theme.
I still learn how to get familiar with bash.

TMNTturtlguy

@cyperghost

Thank you in your effords for the nice theme.
I still learn how to get familiar with bash.

This is why the community is so great, we all have so much we can offer and so many different skills, we can't do it all, but with a little help we can all create some really cool stuff!

@TMNTturtlguy It is dangerous. Think about someone loads your script from your repro and starts it but it is not configurated manually. Then he looses his es_systems.cfgbecause all funktions codes do rm /opt/retropie/configs/all/emulationstation/es_systems.cfg first and then copy the changed files (if it exists) :)

This should not be dangerous at all. Again, i haven't looked at your symlink solution, but my solution is not dangerous because if users do not follow the directions and try to run the script, the script will simply do nothing. The default and main es_systems.cfg file is located here: /etc/emulationstation/es_systems.cfg My script only runs in /opt/retropie/configs/all/emulationstation/es_systems.cfg which is the same as ~/.emulationstaiton/ just written out as the full path. As long as the user never deletes the main es_systems.cfg in the /etc/ folder, there is not risk or danger at all. Here is some more information on this from the wiki: Emulationstation Wiki

TMNTturtlguy

@meleu I just tried your script and it does not execute without the sudo commands. BuZz had updated the retropie startup script a few weeks back and he was the one who instructed that I add the sudo command as he changed user permissions when executing scripts from the retropie menu. Have you tried this script on your build? When did you last update retropie script? Thanks

Edit: adding the sudo command back in to both the copy and remove seems to have worked. With my brief testing it appears that the script works well and all other restart functions work properly. I have to take my girls out for a while so i will test more extensively later.

meleu

@TMNTturtlguy maybe you changed the ownership of those files with your previous script. If they're owned by user pi there's no need for sudo.

cyperghost

@TMNTturtlguy @meleu Is 100% correct! Check if some of your config files belong to root... Seems so because you worked with sudo in your last script. So I falsly said to him that he better removes sudo commands what he already did :)

But I think your script is very special ... I really can't imagine to use it :)
It was real fun to play a bit around with and learn a bit new. So I appreciate every comment/tip/hack from more advanced people. I wasn't able to trigger bugs because I commented every file operation out and tested just the behaviour of function call, loop break and restart ability. I think meleu did the same.

Two locations of es_systems....

Yes I rember now, but I alway work in /etc/emulationstation > Seems that I like risk

TMNTturtlguy

@cyperghost @meleu when I get back on my pi I will repudiate my setup script, bet here is the info from buzz when working on this in the past. Thanks link text

cyperghost

Yes but this behaviour was changed.
https://retropie.org.uk/forum/topic/11050/restart-es-via-bash-script/7

There is really no need to act as root. As long as your script works for you it is really no problem but it seems that user privileges causes some errors.

TMNTturtlguy

@cyperghost Ok, so i updated to the most current setup script and I still have permissions errors. Here is the error:

rm: remove write-protected regular file "/opt/retropie/configs/all/emulationstation/es_systems.cfg" permission denied.

Running the script from the retropie menu does not appear to be the issue, rather removing the file from /opt/retropie/configs/all/emulationstation/

Where can i look to find out my permissions for this folder? Thanks

cyperghost

@TMNTturtlguy Owner is pi:pi
Permission to config files is 644 (Need not to be executed)

pi@retropie:/opt/retropie/configs/all/emulationstation $ ls -l
total 52
drwxr-xr-x  2 pi pi  4096 Jul  3 20:46 downloaded_images
-rw-r--r--  1 pi pi  1627 Jun 26 19:31 es_input.cfg
-rw-r--r--  1 pi pi  1475 Jun 26 19:31 es_input.cfg.bak
-rw-r--r--  1 pi pi 20476 Jul  8 19:25 es_log.txt
-rw-r--r--  1 pi pi  1340 Jul  8 14:19 es_settings.cfg
-rw-r--r--  1 pi pi  1470 Jul  7 23:15 es_settings.cfg.bak
-rw-r--r--  1 pi pi  1641 Jun 26 19:31 es_temporaryinput.cfg
drwxr-xr-x 34 pi pi  4096 Jul  8 18:42 gamelists
drwxr-xr-x  2 pi pi  4096 Jun 24 13:02 tmp

TMNTturtlguy

@cyperghost Yes - rookie mistake on my part and of course I bow down to you at @meleu for your knowledge and help!

When running the script prior to the updates made by buzz the sudo command was used. What this did was create the es_systems.cfg file within the folder as a root file. That was the only file in there that was root, but I believe because i was using the sudo command to copy it from the origin folder to the main folder it was giving it root ownership. I simply deleted that file and copied a fresh file in manually, ran the script and now it works perfectly without the sudo code as you and @meleu have correctly stated.

Once again I am on my pi for 5 minutes and need to run, but in the late late overnight hours I will update a few things in @meleu's branch and then update my main repository and issue the script. I know it has a small use case, but I enjoy it, and I think others may as well if we start seeing more themes created for just specific systems like @ruckage neo geo theme. I love the script on my arcade machine because i can set it to only run Arcade games if i want to.

Thanks again!

FlyingTomahawk

I gave this a try using meleus version.

I run

RPi3
ES 2.4.0RP
RetroPie Script 4.2.8
And the following systems

CPS
NeoGeo
FBA
MegaDrive
SNES
NES

I uploaded the script and created those 4 folders.

All -> All my systems
Consoles -> MD, SNES, NES
Customs -> NeoGeo, FBA, CPS
Favorites -> Empty es_system.cfg file

I then switched between the es_system files using the new function in the RetroPie Settings menu. After I select something let's say "Consoles", ES restarts automatically.
But now I get systems that I don't have inside those 4 new es_system.cfg files.
No matter what I es_system file I choose I always get these systems shown.

SNES
FBA
GameBoy
MegaDrive
NeoGeo
NES
Ports

Where is he getting Ports and GameBoy from?? And CPS is gone too.
Not sure which es_system.cfg file gets loaded here.
Normally there is one inside the emulationstation folder which has been deleted and then there are the other 4 which I created for testing. Is there any other place to look for a es_system.cfg file?

FlyingTomahawk

Never mind my previous post.
Looks like the new folders have to be written in small letters.
Instead of "All" it has to be named "all" same goes for all the other folders.
Now switching between the files works like a charm.
May I suggest to to update the Readme file to reflect this or change the paths inside the change_es_systems.sh file.

Thanks guys, job well done.
Now the only thing left to do is to wait for ruckage to release that NeoGeo/Capcom theme of his and I'm ready to rock.

P.S. Still not sure where he got GameBoy and Ports from but since it is solved now I guess it doesn't really matter anymore.