Closed illando closed 11 months ago
The ScummVM database used in RetroArch scanner has nothing to do with the ScummVM detection system, and is not part of this core.
I don't know how updated is, it is handled in https://github.com/libretro/libretro-database.
Personally i don't use the retroarch scanner, I just use .scummvm files and playlist files created manually, based on scummvm detection.
Just need to use the same game ids stored in scummvm.ini in the .scummvm
files inside the game folders.
Steps to manually add a single game to retroarch playlist would be:
That can be time consuming if you have a massive list in scummvm.ini, that's why I have plans to check the feasibility to add a feature from within the ScummVM GUI to export current scummvm.ini to a retroarch playlist file, in the future. Anyways currently the only way to go is manually or via external scripts, which can be easily written to automate the steps above following a scummvm autodetection.
@spleen1981 thanks a lot! I manually edited the playlist file and it's working perfectly.
You can use this external program to do the playlist for you after you add the games to the scummvm internal menu \, and setup some required paths: https://github.com/i30817/libretro-mkscumm
It's a script implementation of what @spleen1981 suggested. Works in android too, if you follow the suggestion at the end of the readme.
I have plans to check the feasibility to add a feature from within the ScummVM GUI to export current scummvm.ini to a retroarch playlist file, in the future.
As follow up for the above, the new 'Libretro Playlist Generator' feature has now been implemented https://github.com/libretro/scummvm/commit/18c3591548d0665b4b92a1810f3a57f9f2797ba4.
It can be accessed from ScummVM GUI > General Options > Backend
.
Details are given in ?
button in ScummVM GUI, libretro core documentation will be updated soon as well.
This is only intended to give an additional easy and automated way to generate playlists, all manual methods used previously are still applicable.
A utility I'm glad to stop maintaining. Good.
Do you handle the save, soundfont, extra, theme and mt32 bios paths in the core too now?
I think upstream just added the soundfont that was in libretro as the 'default', so that's probably handled, but saves not being set actually crashes the core (because of autosave), so just making sure.
Mt32 my script just copies the bios files into extra if it exists in system, considering it's often there for dosbox. Not sure you can't just auto set it to ..\.. if mt32 bios files exist there or copy them too...
I wish the .scummvm files weren't needed anymore too actually, since they're only needed to hold the key to scummvm.ini and playlists are JSON, which can hold arbitrary extra properties. I've got to read the code.
Mmm, never thought about just putting the .scummvm files in a different directory than the game. That's actually much better than the game dirs (that might not be writable in some cases). Why would you give the option otherwise?
That option gets rid of most of my distaste of .scummvm files.
Do you handle the save, soundfont, extra, theme and mt32 bios paths in the core too now?
soundfont
, saves
, extra
and theme
paths should be handled correctly based on what is set in retroarch.
Mt32 my script just copies the bios files into extra if it exists in system
That is not covered, I need to check if there is a way to pass an alternate path to scummvm for mt32 without patching the source upstream. Otherwise conditional copy to extra path would be the only way I guess.
I wish the .scummvm files weren't needed anymore too actually, since they're only needed to hold the key to scummvm.ini and playlists are JSON, which can hold arbitrary extra properties. I've got to read the code.
That depends on libretro sources, the playlists must point to a file, no way to pass a simple separate parameter to the core while loading a game afaik.
That's actually much better than the game dirs (that might not be writable in some cases). Why would you give the option otherwise?
Infact default is now saving hook files to a common subfolder in saves
folder. The option for separate hook files in game folders is provided just in case one wants to keep the previous approach for any reason.
I'm actually a bit sour on options just for options sake in a RetroArch context (so much confusion is caused by them, so many bugs)...
But I guess it's not a big deal in this case. Especially with the best option as default (not... always the case).
Maybe present a user visible error if the place is readonly though.
I also presented as warning to the user if they tried to use a scummvm.ini with paths to games which no longer exist (usually a sign of reusing a playlist from another system or from moving games or having a unmounted game drive).
Not sure if it's better to fail early and force the user to fix his games, or allow those work to pass into a RA playlist and just present a warning. The clean playlist ra option would usually fix it anyway and sometimes it's just because a drive is not connected.
I'm missing something I did too... Oh, portable playlists. You could check if that's on in the settings, and copy in the rgui_browser_directory
setting (file browser) over to base_content_directory
in the playlist when creating it.
Oh but since those paths are not in the games dir (in the saner option), it doesn't apply, because what's being transfered are the games not the .scummvm files. Uh. A actual reason to use game directory hooks.
Oh lol it wouldn't work anyway... the actual modified paths would be in the scummvm.ini so they can't be transformed by the libretro portable path mechanism. So I did that code for nothing.
A pity that option is lost, it's important for multiple devices\systems shared drives. Eh, not that big a deal, it's not like it's impossible to share the data... just this particular playlist (others can be copied).
Invalid paths in scummvm list will be ignored in the playlist creation, exactly as they are greyed out in the list itself.
Any error in creating hook files will result in not adding the entry in the playlist, and an error/warning will be added in the logs.
Paths retrieved from the list are already normalized and made portable (from paths separator point of view) besides settings in retroarch.
Anyways this is intended to be a handy built-in tool for automated creation of the playlist, it does not need to be completely fool proof, as user can still remove or change the path after playlist is generated... However in case of any problem, as the generation of the playlist is very easy now, user can just re-generate it. And read the logs in case of unexpected results.
If you're already normalizing paths directory seperators in scummvm.ini , following RA strategy to fix moved path too with checking those two properties is certainly possible too.
What happens there is when RetroArch loads a playlist (in your case, loads the core), it checks if portable playlists are on, and rgui_browser_directory
(in settings) and base_content_directory
(in the playlist) both exist, but are different. If they are different, it rewrites the string base_content_directory
in all paths that start with it by rgui_browser_directory
(including base_content_directory
), and replaces the dir separator in the rest of the string.
That would be in the scummvm.ini instead of the playlist in your case, because the playlist part would have already been handled by RA (well, with game directory hooks at least). For that reason, you'd need to save the equivalent of base_content_directory
elsewhere.
But I certainly understand why you wouldn't want to complicate it just for this. It is not too bad to set it up once per platform anyway.
But I certainly understand why you wouldn't want to complicate it just for this. It is not too bad to set it up once per platform anyway.
As base_content_directory
and rgui_browser_directory
are not available through API, a possible solution would be definitely hacky and dirty.
Also this kind of automation for a one-time operation that requires at most two actions ('Mass Add' + Playlist Generation both from ScummVM GUI) is probably not worth the effort, I agree.
Mt32 my script just copies the bios files into extra if it exists in system, considering it's often there for dosbox
Retroarch system folder is now added internally to the folders searched by scummvm for extra content https://github.com/libretro/scummvm/commit/fd6835eaf16666fe44630452fdf389c663354120. Hence no need to copy anything, MT32 roms (or any other extra file) can just sit in system folder and will be loaded as needed.
Following the WIKI page https://wiki.scummvm.org/index.php?title=Broken_Sword_1 since ScummVM 2.7.0 the folder structure from the original media needs to be preserved. Older versions of ScummVM allowed to move files to the top level folder, while they now need to remain in their respective subdirectories. So the game is no longer detected with the old structure, but after moving the files following the current instruction it's not possible to add it to the RA playlist after scanning the main follder.
The only way to launch the game is to start the core and add it to the ScummVM GUI.