Feature: update console support

[juliadin]

I am currently going through the lists of supported consoles and adding things, fixing things.

I am also introducing the {console} token that is replaced with the more or less canonical name of the console. I hope that’s ok. It’s a more specific way of doing things than the —dir-dat-name which largely depends on the dat creators view on the name (which differs between groups). I tried to get the different names from different regions into one string, trying to respect POSIX and Windows file system limitations. It would be useful for my collection at least, feel free to shoot the idea down though :).

[github-actions[bot]]

:test_tube: Branch testing instructions

This pull request can be tested locally with the following command:

npm exec --yes -- "github:juliadin/igir#feature_update_console_support" [commands..] [options]

Comment generated by the Pull Request Commenter workflow.

[juliadin]

I have a list with about 200 names of consoles to canonicalize (generated from parsing hundreds of dat files that were available to me). Funnily most of them are supported by batocera or libretro in some capacity, some have standalones available ... I had a look at what daijisho offers as presets and I am trying to filter the most obscure stuff out but I think it wouldn't hurt to have canonical names for most of them.

[juliadin]

@emmercm Would be nice to know if you approve of the canonical name via {console} and if so: which name should I choose? I am tending towards using the name from the country where the device was developed, excluding (Super)Famicom/(S)NES, Genesis/Megadrive etc where the popularity of both names is overwhelming.

[emmercm]

@juliadin I scanned through the diff so far and it looks good to me. I would probably personally err on the side of using console names copied & pasted from No-Intro DATs, as those are seemingly the most used DATs these days.

Do you have any consoles you're not sure about?

[emmercm]

Something worth thinking about @juliadin is what is the use case for this over {datName}? Maybe it would help sort ROMs when not using DATs, but it would likely drop a lot of data if it can't find an appropriate {console} using filename extensions. Whatever we do here will be just as opinionated as the naming used in DATs, and it might be best to encourage people to just use DATs that they prefer best.

[juliadin]

@juliadin I scanned through the diff so far and it looks good to me. I would probably personally err on the side of using console names copied & pasted from No-Intro DATs, as those are seemingly the most used DATs these days.

Do you have any consoles you're not sure about?

Thanks, yes. The Odyssey 2 aka Philips G7000 aka Philips Videopac (not +) for example ...

[juliadin]

Something worth thinking about @juliadin is what is the use case for this over {datName}? Maybe it would help sort ROMs when not using DATs, but it would likely drop a lot of data if it can't find an appropriate {console} using filename extensions. Whatever we do here will be just as opinionated as the naming used in DATs, and it might be best to encourage people to just use DATs that they prefer best.

The usecase I was thinking of was when using DATs from multiple sources (like No-Intro + some aftermarket DATs) the naming conventions might differ and that causes 'some mess'. I don't know yet if it is really worth the trouble but when for example using some metadats from libretro together with No-Intro and Redump, I ended up with a lot of very similarily named folders.

[juliadin]

In the end this is https://xkcd.com/927/ all over again but the usecase would be that by using regex igir could bring many opinionated namings into one opinionated naming ... I still think it is worth the work.

[emmercm]

I see the use case for mixing multiple input DATs, though I typically don't because it's highly likely duplicate ROMs will be output with different filenames. Though there is normally not a ton of overlap between No-Intro and Redump.

I'm good with this if you are, I don't see a ton of harm in it, and I think documentation will go a long way toward clearing up any confusion.

[juliadin]

After thinking about it for a while I guess you are right. While the main task of the pull request still makes sense (adding as many .dat Regexes for game systems as possible and finding out if any supported emulation devices can work with these) my draft for a new tag doesn't ... it just adds to the confusion that working with .dats can be as it is. What turned it around for me was that especially the dats for working with game systems that support multiple formats or where formats matter this makes things harder, not easier. It seemed like a good idea and seemed to solve a problem I thought I had. Thanks for helping me think about it again :).

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.09%. Comparing base (ae85f69) to head (a8f25d2). Report is 369 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #846      +/-   ##
==========================================
- Coverage   93.37%   93.09%   -0.28%     
==========================================
  Files          86       86              
  Lines        5374     5374              
  Branches     1230     1230              
==========================================
- Hits         5018     5003      -15     
- Misses        338      352      +14     
- Partials       18       19       +1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[github-actions[bot]]

:lock: Inactive pull request lock

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Comment generated by the GitHub Lock Issues workflow.