Ignore filenames when loading systems

[PhilaPhan80]

This enhancement allows users to specify one or more files that should be ignored during the system loading process.

(Inspired by posts such as: https://www.reddit.com/r/RetroPie/comments/5rnips/neogeo_and_mame_how_to_hide_bios_files_in_game)

Any files explicitly added to an <ignore> node within the es_systems.cfg file will be excluded from the game list that is displayed to the user. Each filename MUST be wrapped in double quotes (since some filenames contain spaces). Filenames are not case sensitive.

Example:

  <system>
    <name>arcade</name>
    <fullname>Arcade</fullname>
    <path>/home/pi/RetroPie/roms/arcade</path>
    <extension>.7z .cue .fba .iso .zip .7Z .CUE .FBA .ISO .ZIP</extension>
    <ignore>"filename1.bin" "filename2.iso" "filename3.zip"</ignore>
    <command>/opt/retropie/supplementary/runcommand/runcommand.sh 0 _SYS_ arcade %ROM%</command>
    <platform>arcade</platform>
    <theme>arcade</theme>
    <directlaunch/>
  </system>

[cmitu]

EmulationStation already ignores BIOS files - they're declared in the mamebioses.xml resource file.

[PhilaPhan80]

This has actually been very helpful for my Philips CD-i setup, but I imagine it could benefit others as well.

The BIOS files (cdibios.zip, cdimono1.zip, cdimono2.zip) are not automatically ignored within the cdimono1 directory. I assume this is because the system is not officially supported. Regardless, I was able to get it up-and-running thanks to several tutorials, and this helps to hide those files from the game list.

I did notice similar requests to hide files during my cursory search for the same thing, so I figured I'd give it a try and keep the solution as isolated and optional as possible.

[cmitu]

The mame BIOS exclusion is applied on arcade and neogeo systems (I think based on the platform), that's why it was not applied to cdimono1.
IMHO the same mechanism could be used for other systems, without forcing the user to modify the es_systems.cfg, which on RetroPie is - by default - a system file.

[pjft]

Thanks for taking a stab at this. I will side with @cmitu on the implementation though. I would not add it to es_systems.cfg either, as we don't want users to be editing that file.

I understand that the original mechanism might not be as flexible as you'd like it to be, so if that'd not be ideal, perhaps adding such a tag to a gamelist would be wiser. See original PR: #432

[PhilaPhan80]

Thanks for clarifying, @cmitu and @pjft. I didn't realize the es_systems.cfg file was considered a system file that others shouldn't be encouraged to edit. There aren't any comments at the top of the file warning against it (food for thought), and I've seen various tutorials that list steps to do so (probably also not realizing the same).

Regardless, I still think there's value to giving users a way to exclude any files they want without being limited to a pre-defined list (i.e. agnostic implementation vs. system or platform-specific logic).

Your suggestion of the gamelist files sounds pretty similar to what's happening here. Just want to confirm before I dive deeper -- the [system]/gamelist.xml files aren't considered system files like the other one? In other words, they're okay to edit manually?

[pjft]

Gamelists are completely game for editing manually - scrapers use them, users use them.

@cmitu any thoughts on using gamelists for this? Or would you want to elaborate on using the mamebioses.xml file and whether that'd be a better option from your perspective?

If choosing that file, then it'd still be overwritten when updating ES, am I mistaken? Unless, once again, we wouldn't expect users to manually edit it.

@PhilaPhan80 we already have a "" tag there which does not quite do what you're going for here, so we'd need to choose a separate tag.

[PhilaPhan80]

I'm not sure a mechanism like mamebioses.xml is going to meet the requirement of being able to exclude any user-defined file/folder from the gamelist on any system for any reason (user's prerogative), but I'll wait to see what @cmitu adds before proceeding further.

@pjft In your last post, you mentioned that a tag already exists, but it looks like the tag name got clipped. Can you edit or repost it?

[pjft]

Oh, that's quaint. I expect it's because I used < > around it, and was parsed as something. It's "hidden". So, writing that word inside < > will be blank.

[cmitu]

@cmitu any thoughts on using gamelists for this? Or would you want to elaborate on using the mamebioses.xml file and whether that'd be a better option from your perspective?

If choosing that file, then it'd still be overwritten when updating ES, am I mistaken? Unless, once again, we wouldn't expect users to manually edit it.

I was thinking of a more generalised approach of mamebioses.xml - just have an 'resources/exclude/.txt' and whatever ROM name is found there, it can be excluded from the listing. The resources/exclude/* can be loaded from the install dir or from the user's folder, similar to how other resource dependant files (i.e. .svg files) are loaded, so they can be editable by the user and they're independent of gamelists/system definitions.

[PhilaPhan80]

Thanks, @cmitu. I'll give that a look and respond when I get a chance.

[PhilaPhan80]

@cmitu After a slight (😅) delay due to life priorities, I've returned to this topic. Taking your advice, I'm in the process of implementing a solution based on a user-editable resource file.

I have one question before I proceed too far. I think I'm noticing while stepping through the code that the gamelist.xml files aren't updated if a game/folder isn't recognized upon load. Specifically, if I ignore the files I'm currently testing, the front end will hide them from the UI, but the gamelist.xml files will still hold onto them for subsequent loads.

I stumbled upon this entry of yours from 2018 (coincidentally the same day as today!) where you say that's by design. Do you happen to know -- is this still true today? (https://retropie.org.uk/forum/post/156311)

If so, I'll stop where I am and clean things up for a pull request.

If no longer by design, can you point me to the pull request that implemented that change so I can take a closer look at it?

cc: @pjft

[cmitu]

I stumbled upon this entry of yours from 2018 (coincidentally the same day as today!) where you say that's by design. Do you happen to know -- is this still true today? (https://retropie.org.uk/forum/post/156311)

Yes, it's still true. Unless you delete the entry from EmulationStation, it's not removed from the gamelist.xml.

[PhilaPhan80]

Thanks for confirming. I won't add that logic as part of this effort, then, since it would be out of scope.

I'm going to close this pull request and open another one from a separate branch, but I'd like to keep this open for now so I can continue to comment and then link the two together.