Settings xml is not packaged in some cases

[zach-morris]

See https://github.com/kodi-game/game.libretro/issues/78

Tested recently on Kodi 19.1, OSX 11.6. Steps to see issue:

Install an addon from the standard Kodi repository. In my example I installed game.libretro.mame2003_plus When the addon is installed, I note that the addon screen shows that the addon cannot be configured Start a game, go to settings>Advance Settings and see the same thing "This addon cannot be configured"

Opening up the addon directory, there are no files in: ...path to addons/game.libretro.mame2003_plus/resources/

If I manually move the settings file and language files generated in: ...path to userdata/addon_data/game.libretro.mame2003_plus/generated/ to: ...path to addons/game.libretro.mame2003_plus/resources/

And restart Kodi, then I can configure the addon. It appears that the generated files are not being placed in the correct directory. I did not exhaustively test these addons, so unsure how many are effected.

[garbear]

Is this issue specific to mame2003_plus? It looks like they migrated to the libretro settings API v2: https://github.com/libretro/mame2003-plus-libretro/blob/984ff55ce0f7cace6cbde37338da663a4c485130/src/mame2003/core_options.c. We'll need ctype support for v2 as in https://github.com/kodi-game/kodi-game-scripting/issues/69

[zach-morris]

I've tested a smattering and so far the answer appears to be yes (all other addons I've tested are working), so maybe it is all cores that have migrated to v2. I'll see if I can find another v2 addon to test this theory. However, the settings.xml file appears to be generated, because it's in the userdata folder, so it would appear it's working to some degree (granted I'm not familiar with how exactly kodi-game-scripting does it's magic).

Edit: MAME 2003 has the same issue (also a v2 core), but Beetle PCE, Beetle Saturn, Pokemon Mini do not (also v2, although I don't know if kodi-game-scripting is grabbing the latest and greatest for these or not)

[garbear]

I would assume that, when v2 support is added, the libretro team would keep v1 as compatibility. Indeed, this is the case for PokeMini: https://github.com/libretro/PokeMini/blob/42ab7b2a92a35958957039d7c538fda9ea178d08/libretro/libretro_core_options.h#L435

My guess is that the migration to v2 was tested with a v2 frontend, and v1 may have broken for a small number of cores, and wasn't noticed because it wasn't tested with a v1 frontend. You can see that PokeMini picks up the v1 settings correctly: https://github.com/kodi-game/game.libretro.pokemini/blob/master/game.libretro.pokemini/resources/settings.xml.

The best thing we could do is migrate to v2, then we wouldn't have to worry about devs not testing legacy v1 support.

[zach-morris]

V2 sounds like the way to go. I'm not a C programmer, but I'll mess with it using the info you put into the other issue and see if I can muddle through it. Only semi-related, there are some settings that are dynamically generated. The best example I can find of this is opera-libretro: https://github.com/libretro/opera-libretro/blob/master/libretro_core_options.c#L35

The kodi version of the addon picks up the settings for opera_bios and opera_font as 'disabled'. In Retroarch, these settings are only settable if the core finds the appropriate files in the appropriate directory, otherwise 'disabled' is correct. In Kodi, even with the appropriate files in the appropriate directory, the setting isn't dynamically generated and therefor always reads 'disabled'. This is a pretty unique case though, and I don't know how many settings this actually effects.

[eigendude]

Only semi-related, there are some settings that are dynamically generated. The best example I can find of this is opera-libretro: https://github.com/libretro/opera-libretro/blob/master/libretro_core_options.c#L35

An easy solution I thought of, that doesn't require extending the libretro API or Kodi, is to simply patch the cores to always show all settings, or pre-compute all options for a given setting. Libretro would ignore settings that don't apply. Not ideal, but at least it's easy.

Next solution would probably be extending Kodi's binary add-on API to pass settings at runtime. We used to support this for a single PVR add-on, but it was very incomplete (the equivalent of libretro's v1). I think the primary goal is to get v2 working in kodi-game-scripting. Then I'll look into extending the unused settings translation in this add-on to generate settings for Kodi at runtime.

EDIT: work account

[zach-morris]

Makes sense. I think the settings that do this at runtime are few and far between.