ScummVM playlists are created by the core itself. ScummVM core is first started up with start core then you let it scan the games itself (or provide a sufficiently problematic settings agnostic Scummvm.ini time if you find that intolerably slow - i use ScummVM CMD line and bash to create this in my server, edit out settings that conflict and edit the paths to the âSAFâ version of them then import it into -scummvm android upstream not retroarch android- because itâs mucho much faster and has less false positives and the names of unknown games are better to add insult to injury).
Anyway after that you have a normal ScummVM window with the games, then go into global options and the backend tab. In the retroarch core version there will be a button to create playlist which does what youâd expect.
This was done this way because although ScummVM CAN run games by just giving them a engine identifier retroarch scanner(s) had no option to put such a Iâd into the playlists (the older method was the user putting a file in the game dir and was as horrid as youâd expect with thousands of games) and because the ScummVM scanner frankly does very complicated things retroarch canât like putting in different options in the engine for different versions of the same game, turning a game into 2 or more, changing options due to user in gameoption changes, etc etc etc.
So to avoid bugs related to misidentified games that wouldnât exist upstream, retroarch just punted everything to ScummVM. First you use ScummVM, then the playlist gets created by the user/core not the RA scanner.
I would not even mention it because I agree with this mostly. Except Iâm pretty sure that if retroarch finds a (upstream not core) ScummVM rsaf path, itâs different than the retroarch rsaf path. Their prefixes are different so the core itself has to be fixed to work with the libretro saf prefix. I wouldnât mention it myself, except itâs a obvious incompatibility which kind of has to be fixed for anyone using upstream scummvm network storage to use it for retroarch ScummVM. With luck itâs just changing a string prefix. But considering how ScummVM likes to use some kind of encoded paths to avoid forbidden characters it might be more complicated than this.
As I said a very specific to one core problem for a feature that retroarch in general is only implementing bit by bit now (cores need to use libretro VFS for passing SAF paths to work).
If the saved playlists views are indexes into actual playlists thatâs both interesting and worrying with how they have to be not indexes but mappings because the base playlists will change often.
Frankly I love manual playlists and the manual scanner much much more than any other in retroarch regretable necessities like scummvm aside. Views are cool but theyâre only useful supported by other metadata features like a lucene like tag search system (which doesnât exist), better story/character related tags (I like the hardcore101 tags but anything more than the basic âaction adventureâ is better. The best tag there is âfranchiseâ and frankly that one is not too good either, wonât mention series/subseries numbers or clones) and a robust amount of metadata (which exists for some platforms but not all). Worse with the manual system itâs wholy dependable on using only names+system to match since checksum or serials arenât there at all. Iâm assuming this is the root of the problem of finding a whole lot of missing games in the explore tab, more than missing metadata. And maybe sometimes changed nointro/redump names (Iâm ignoring some dumps I use that have no actual retroarch database like whdload Amiga dumps which were âsupportedâ by mapping their actual names to the commodore Amiga database somehow, which only works with the normal scanner not the manual).
Maybe one day. I personally use a single core for CPS1, CPS2, CPS3, FB Neo Arcade, FB Neo AES, and FB Neo CD, and saving configurations and shaders is very tedious. The files have to be named differently, and saving hundreds/thousands of games this way can be a waste of half your life