RFE: possible way to remove the need for .scummvm files

[i30817]

Don't get too excited, this idea still requires special handling of metadata.

Basically, instead of keeping the scummvm.ini 'id' of the game on a file in the game directory, have the option to keep it in the playlist as a extra game entry and the game directory path as the 'path'

Since the current playlist format is json, adding new specialized entries is no big deal.

Why?

Because adding files to game directories is not always possible and doesn't scale to dozens, much less hundreds of games scummvm supports.

Since scummvm games data files are 'always' read only users might very well stuff the games into cdroms or dvds or compressed read only filesystems. I find it 'user unfriendly' to require users to add files, especially files not required upstream that have ids that are subject to random change depending on the vagaries of the scummvm scanner and might very well decide to change names if the user recreates the scummvm.ini file.

Besides that, how would the playlist be constructed?

Here is the hard sell part. It probably wouldn't until the there is a special scanner for scummvm games or the scummvm core gains the capacity to update a playlist when its internal 'list of games' gets updated.

However i already have a external tool that could fill in that data if the scummvm core had the capability to use it, so it would be useful now.

TL;DR: add the capability (maybe to libretro) to add contextual 'arguments' to playlist entries. Have the scummvm core use that as a pointer to the (already scanned in the core) game id to start.

Fill the playlist somehow, preferably by having the scummvm core modify the scummvm playlist when it writes to scummvm.ini. Or just use my utility.

Profit: no longer have to create .scummvm files in every single game directory, no longer have to 'scan twice'.
Unhappiness: special case for special unicorn core scummvm requires scanning from inside the core GUI (this already is required mind you, people are just misled into thinking the 'normal scanner' is enough, when it really isn't).
Ambivalence: scummvm is probably not the only core in the future that could use a 'argument field' in playlists to avoid problems like this again, although the 'context specific file' approach is often useful too (dosbox cores and conf files for instance) if the information is dense and stable enough, the format exists from upstream and there is no proxy for it like scummvm.ini 'ids'.