Custom Retronas Directories/Symlinks

[zacaronii]

I really appreciate all of the options retronas offers, but I wondered if I could setup my own custom directories with symlinks to the generic roms folders. I know I CAN, but I wanted to make sure nothing in the ansible playbooks would cause any custom setups to get overwritten in the future.

For instance, I know you have an emudeck setup, but I have been using retrodeck and would like to configure a directory for that. In this particular case, I think what I'd actually like to do is just use the emudeck setup as a base, rename the primary directory to "retrodeck" and make some tweaks to some of the folders from there to customize it for retrodeck.

Actually, to expand on this question a bit, if I make customizations to any of the directories is there a possibility for that to get overwritten if I'm not actually going in and rerunning the ansible playbook for that specific share?

[sairuk]

You can run a custom playbook from the Update menu if you wanted to build one, however when it comes to the software dirs and specifically the retronas_systems.yml file (which ideally you'd want to edit) there is every possibility future changes could impact any custom setup but so long as your playbook is completely self-contained it should be OK.

i've added support for a retrodeck folder in the testing branch if you want to try it out

[sairuk]

i've also added support to my update checking tool, which checks against the es_systems.xml for supported systems, so hopefully that is correct for RD

[zacaronii]

That's a really neat tool! I'll hop on the testing branch and try the retrodeck setup here in a little bit.

I love this project by the way. Thank you for all of the work you've put in to it. Do you have any preference on how people who want to support the project contribute to it?

[sairuk]

Do you have any preference on how people who want to support the project contribute to it?

not really atm, i suppose if anything code, tickets, tutorials but ultimately just enjoy it

[zacaronii]

I installed the retrodeck folder from the testing branch, and I did a comparison of the default directories from retrodeck and retronas. I provided my csv with my comparison, so you can check my work if you'd like. However, these are the changes I found necessary to align the directory structure more accurately with the default from retrodeck. This is specifically for the roms folder. I'll try to actually learn how to use git, so I can be more useful and provide an actual pull request in the future.

Suggestion

REMOVE ags -> ../../roms/commodore/amiga
REMOVE android -> ../../roms/platform/android
REMOVE androidapps -> ../../roms/platform/android/apps
REMOVE androidgames -> ../../roms/platform/android/games
REMOVE atarijaguarcd -> ../../roms/atari/jaguar/cd
REMOVE coco -> ../../roms/tandy/trs80colorcomputer1
REMOVE dragon32 -> ../../roms/dragon
REMOVE flash -> ../../roms/other/flash
REMOVE fpinball -> ../../roms/pinball/fpinball 
REMOVE mame-advmame -> ../../roms/mame/mame
ADD mastersystem -> ../../roms/sega/mastersystem
REMOVE megadrivejp -> ../../roms/sega/megadrive
REMOVE model3 -> ../../roms/sega/model3
REMOVE ngage -> ../../roms/nokia/n-gage
REMOVE oric -> ../../roms/oric/tangerine
ADD pc -> ../../roms/ibm/pcxt
REMOVE ps4 -> ../../roms/sony/playstation4
REMOVE samcoupe -> ../../roms/milesgordon/samcoupe
REMOVE sneshd -> ../../roms/nintendo/superfamicom
ADD stv -> ../../roms/sega/stv
REMOVE symbian -> ../../roms/symbian/symbianos
REMOVE tanodragon -> ../../roms/dragon
REMOVE triforce -> ../../roms/sega/triforce
REMOVE trs-80 -> ../../roms/tandy/trs80
REMOVE vpinball -> ../../roms/pinball/vpinball
REMOVE xbox360 -> ../../roms/microsoft/xbox360
REMOVE zmachine -> ../../roms/infocom/zmachine
REMOVE zxnext -> ../../roms/sinclair/zxspectrum
 

retrodeck_roms_directories.csv

[zacaronii]

Hey, Xargon! Thank you for the quick follow up on this topic. Also, thank you for all of the work you are doing on RetroDECK.

If I understand correctly, it looks like almost all of the directories I mentioned as needing to be removed are actually commented out in the following file under the linux directory. es_systems.xml

The only ones I see that are not commented out in this .xml, that don't seem to be generated in the default RetroDECK roms directory, are the 3 android entries. Would it be acceptable to comment these entries out?

REMOVE ags -> ../../roms/commodore/amiga
REMOVE android -> ../../roms/platform/android
REMOVE androidapps -> ../../roms/platform/android/apps
REMOVE androidgames -> ../../roms/platform/android/games
REMOVE atarijaguarcd -> ../../roms/atari/jaguar/cd
REMOVE coco -> ../../roms/tandy/trs80colorcomputer1
REMOVE dragon32 -> ../../roms/dragon
REMOVE flash -> ../../roms/other/flash
REMOVE fpinball -> ../../roms/pinball/fpinball
REMOVE mame-advmame -> ../../roms/mame/mame
ADD mastersystem -> ../../roms/sega/mastersystem
REMOVE megadrivejp -> ../../roms/sega/megadrive
REMOVE model3 -> ../../roms/sega/model3
REMOVE ngage -> ../../roms/nokia/n-gage
REMOVE oric -> ../../roms/oric/tangerine
ADD pc -> ../../roms/ibm/pcxt
REMOVE ps4 -> ../../roms/sony/playstation4
REMOVE samcoupe -> ../../roms/milesgordon/samcoupe
REMOVE sneshd -> ../../roms/nintendo/superfamicom (I don't see this in the .xml at all, unless I'm overlooking something)
ADD stv -> ../../roms/sega/stv
REMOVE symbian -> ../../roms/symbian/symbianos
REMOVE tanodragon -> ../../roms/dragon
REMOVE triforce -> ../../roms/sega/triforce
REMOVE trs-80 -> ../../roms/tandy/trs80
REMOVE vpinball -> ../../roms/pinball/vpinball
REMOVE xbox360 -> ../../roms/microsoft/xbox360
REMOVE zmachine -> ../../roms/infocom/zmachine
REMOVE zxnext -> ../../roms/sinclair/zxspectrum

[sairuk]

Yeh there are ~6 es_systems.xml files in the retrodeck repo, @zacaronii your thinking is we should be using the linux one that has stuff commented out.

Although assuming the other es_systems.xml entries are valid targets we'd need to cover all scenarios since we're a storage endpoint in this case, so having all directories available makes sense for our end.

[zacaronii]

Yeah, that makes perfect sense. I don't know for sure if those other entries are utilized by the project at the moment, or if they are just entries from the official ES-DE repo. The docs currently state that the RetroDECK project only supports Steam OS and limited Linux desktop support, at the moment.

If RetroDECK is only leveraging the es_systems.xml in the linux directory, then perhaps it could make sense to use that one.

However, if there are no adjustments that can be made that make sense for both projects, then we will just have to leave it at that. 👍 Honestly, there are several ways I could see to work around this on the user side, if that ends up being necessary.

[zacaronii]

Hey @XargonWan , sorry to bump you on this again. I appreciate you taking the time to respond to the inquiries here. I just wanted to follow up again to see if you could confirm our understanding of how RetroDECK is using the .xml files, so we can assure that Retronas is grabbing the most accurate information.

To be clear, Retronas is parsing this file, right now. RetroDECK/ES-DE/refs/heads/main/resources/systems/unix/es_systems.xml

However, this one appears to better match your description of having certain systems commented out. RetroDECK/ES-DE/refs/heads/main/resources/systems/linux/es_systems.xml

Is it an accurate understanding that RetroDECK is using the one in the linux directory to represent the supported systems, or are the other .xml files maintained, as well?

[sairuk]

just so we are all on the same page

we were checking only the unix systems originally as it seemed complete. we now check all the entries of all es_systems.xml files for the systems in the resources directory using our check_systems tool to compare against other projects we already support.

we take those results and add them to our mapping file retronas_systems because we have a directory structure that is expected to provide the same files across multiple projects using symlinks.

i'd assume the linux file is the correct one, now that its clear the commented systems are not used by the project intentionally. we can pull back those entires in our mapping file easily enough if so.