Can't see new system in EmulationStation

BuZz

@hiulit said in Can't see new system in EmulationStation:

My question is: How can I copy that system in /opt/retropie/configs/all/emulationstation/es_systems.cfg in the scriptmodule? And shouldn't it just work from /etc/emulationstation/es_systems.cfg?

You don't - /opt/retropie/configs/all/emulationstation/es_systems.cfg is not created by default. If you have that file you have created it yourself - it overrides the system default in /etc and is designed to be used for people to override the system one.

hiulit

@BuZz Uops! My bad... I don't recall creating that file myself...

Should I then check if /opt/retropie/configs/all/emulationstation/es_systems.cfg exists and then copy the newly created system from addSystem() in /etc/emulationstation/es_systems.cfg to /opt/retropie/configs/all/emulationstation/es_systems.cfg. Is that a good practice?

mitu

@hiulit A scriptmodule should only modify the system's es_systems.cfg file, not the user's configuration file. You should use the addSystem and mkRomDir helpers to add a new system and addEmulator to configure an emulator for that system and don't worry about - the possible - user created es_systems.cfg.

hiulit

@mitu That's exactly what I'm doing. But since the system only gets created in /etc/emulationstation/es_systems.cfg and I also have /opt/retropie/configs/all/emulationstation/es_systems.cfg (and it doesn't have the new system in it), the latter has preference and the system doesn't appear in EmulationStation.

hiulit

@mitu Should I, somehow, tell the users to copy the new system from /etc/emulationstation/es_systems.cfg to /opt/retropie/configs/all/emulationstation/es_systems.cfg if they have that file?

BuZz

Then delete the other file? Users who have created that file should be aware they need to maintain it themselves - it's in the documentation anyway.

mitu

@hiulit said in Can't see new system in EmulationStation:

Should I, somehow, tell the users to copy the new system from ...

No, as @buzz said, this behavior is documented - if you have a customized es_systems.cfg file, then updates to the RetroPie maintained file are not propagated to your own file. This is the default behavior for any scriptmodule (that adds or modifies a system), there's no point in adding any exceptions to it.

hiulit

Alright! Thank you both @BuZz and @mitu . I'll leave the scriptmodule as it is then. Less hassle for me :P

hiulit

@BuZz @mitu One more question: If I update RetroPie, would /etc/emulationstation/es_systems.cfg be overwritten and thus I would loose the new system I added?

mitu

@hiulit No, the file is not overwritten on upgrades - it's just edited through the usage of scriptmodules (addSystem/delSystem).
If your system is added through a scriptmodule, the upgrade of said scriptmodule would otherwise add the system back anyway.

hiulit

@mitu Ok, thanks! That's good to know. I thought that /etc/emulationstation/es_systems.cfg gets overwritten with every update, that's why I had the /opt/retropie/configs/all/emulationstation/es_systems.cfg.

In that case, what's the use of /opt/retropie/configs/all/emulationstation/es_systems.cfg?

BuZz

@hiulit seems we are going over this again and again :)

/etc/emulationstation/es_systems.cfg gets updated every update with the systems you have installed (so you get new file extensions etc).

/opt/retropie/configs/all/emulationstation/es_systems.cfg is available if users want to manage it themselves - eg. custom sort order, own systems etc. This file needs to be manually kept in sync with the retropie one.

hiulit

@BuZz Thanks! All clear ;)

hiulit

@mitu @BuZz Sorry to "open" this thread again, but could you tell me if addEmulator works inside a loop? Something like:

    for i in "${!bin_files[@]}"; do
        addEmulator ...
    done

Because it's only adding one emulator right now.

Or let me rephrase it: How can I add more than one emulator in emulators.cfg?

Thanks!

mitu

@hiulit said in Can't see new system in EmulationStation:

Or let me rephrase it: How can I add more than one emulator in emulators.cfg?

Yes, it should work. For instance

adding multiple entries for the same system (i.e. the same emulators.cfg) - xroar
adding multiple entries in multiple systems (i.e. different emulators.cfg) - lr-fbalpha.

hiulit

@mitu Ok, it works fine when adding multiple emulators "one by one", like in the examples you showed me, but not if try to add them inside a loop. And I think it's because the emulators.cfg file gets overwritten every time addEmulator is called, right?

Anyway, I did it like the examples you showed me and it works. Thanks :)

mitu

@hiulit said in Can't see new system in EmulationStation:

And I think it's because the emulators.cfg file gets overwritten every time addEmulator is called, right?

Not really, the same thing happens also in the xroar installation script and it's not a problem.

hiulit

@mitu But in the xroar there's no loop to add the emulators.

When I try to use something like:

 for i in "${!bin_files[@]}"; do
        addEmulator ...
    done

Only the last emulator gets written in emulators.cfg

mitu

@hiulit Without looking at the full code fragment, it's hard to say if it's a bug in your code or something in addEmulator.

hiulit

@mitu Well, I've already used the "one-by-one" method, but here's what I had

function configure_godot-engine() {
    mkRomDir "godot-engine"

    local bin_files

    if isPlatform "x86"; then
        bin_files=("godot-3.0-x11-x86-32.bin" "godot-3.1-x11-x86-32.bin")
    elif isPlatform "aarch64"; then
        bin_files=("frt_094_310_arm64.bin")
    elif isPlatform "rpi1"; then
        bin_files=("frt_094_310_pi1.bin")
    elif isPlatform "rpi2" || isPlatform "rpi3"; then
        bin_files=("frt_094_310_pi2.bin")
    fi

    for i in "${!bin_files[@]}"; do
        addEmulator 0 "$md_id-$i" "godot-engine" "$md_inst/${bin_files[$i]} --main-pack %ROM%"
    done

    addSystem "godot-engine" "Godot" ".pck .zip"
}