Core specific override behavior has changed

[piikkisika]

EDIT: Actually, seems that support for core specific configuration has vanished altogether in the latest build(s). There’s even no “Configuration Per-Core” option available in the Configuration submenu. I suppose that’s just a bug and will be fixed. If so, I think the problem I’m describing below will be fixed as well.

------ Original message below

I just updated to latest nightly build and seems that at some point during last couple of weeks the behavior when core specific configs (core_specific_config = true) are in use, core specific overrides are disabled, has changed. That was how it worked in build 2016-07-21. However in the latest build core specific overrides are enabled in such case.

That change is clearly visible when running retroarch_debug.exe --verbose with the exact same parameters. In the older version it prints “Overrides: can’t use overrides with with per-core configs, disabling overrides.” and in the latest version it prints “Overrides: core-specific overrides found at E:\Emulators\RetroArch\config\Genesis Plus GX\Genesis Plus GX.cfg.”

My configuration for differentiating Sega Game Gear specific configuration (such as different shader etc) to other genesis_plus_gx core supported systems depends on that feature, so I’m disappointed that it has been changed. So is that change intended?

If that change will stay, is there some other way I could specify those Game Gear specific settings with just command line parameters and/or core specific overrides, but without game specific overrides and core specific configs. The problem I currenly have with core specific configs is that - as most configuration settings are identical across all cores - I’d prefer to keep those common settings in one master config file - or in the main retroarch.cfg that is. I don’t know if that’s achievable when core specific configs are in use, since at least it seems to me that it basically overrides everything in the main retroarch.cfg, even if you don’t specify some setting in the core specific config.

2016-07-21 E:\Emulators\RetroArch>retroarch_debug.exe --verbose -L cores\genesis_plus_gx_libretro.dll “…\roms\Sega Game Gear\Castle of Illusion Starring Mickey Mouse (USA, Europe).gg” --appendconfig “config\Genesis Plus GX\gg\gg.cfg” RetroArch [INFO] :: Redirecting save file to “…\roms\Sega Game Gear\Castle of Illusion Starring Mickey Mouse (USA, Europe).srm”. RetroArch [INFO] :: === Build ======================================= Capabilities: MMX MMXEXT SSE1 SSE2 SSE3 SSSE3 SSE4 SSE4.2 Built: Jul 21 2016 RetroArch [INFO] :: Version: 1.3.6 RetroArch [INFO] :: Git: 1c40598 RetroArch [INFO] :: ================================================= RetroArch [INFO] :: Config: appending config “config\Genesis Plus GX\gg\gg.cfg” RetroArch [INFO] :: Config: loading config from: E:\Emulators\RetroArch\retroarch.cfg. RetroArch [INFO] :: Config: loading core-specific config from: E:\Emulators\RetroArch\config\genesis_plus_gx_libretro.dll.cfg. RetroArch [WARN] :: Config: core-specific config not found, reusing last config. RetroArch [INFO] :: Resetting undo buffers. RetroArch [INFO] :: Loading dynamic libretro core from: “E:\Emulators\RetroArch\cores\genesis_plus_gx_libretro.dll” RetroArch [INFO] :: Overrides: can’t use overrides with with per-core configs, disabling overrides.

2016-08-02 E:\Emulators\RetroArch>retroarch_debug.exe --verbose -L cores\genesis_plus_gx_libretro.dll “…\roms\Sega Game Gear\Castle of Illusion Starring Mickey Mouse (USA, Europe).gg” --appendconfig “config\Genesis Plus GX\gg\gg.cfg” RetroArch [INFO] :: Redirecting save file to “…\roms\Sega Game Gear\Castle of Illusion Starring Mickey Mouse (USA, Europe).srm”. RetroArch [INFO] :: === Build ======================================= Capabilities: MMX MMXEXT SSE1 SSE2 SSE3 SSSE3 SSE4 SSE4.2 Built: Aug 2 2016 RetroArch [INFO] :: Version: 1.3.6 RetroArch [INFO] :: Git: fb2b53e RetroArch [INFO] :: ================================================= RetroArch [INFO] :: Config: appending config “config\Genesis Plus GX\gg\gg.cfg” RetroArch [INFO] :: Config: loading config from: E:\Emulators\RetroArch\retroarch.cfg. RetroArch [INFO] :: Resetting undo buffers. RetroArch [INFO] :: Loading dynamic libretro core from: “E:\Emulators\RetroArch\cores\genesis_plus_gx_libretro.dll” RetroArch [INFO] :: Overrides: core-specific overrides found at E:\Emulators\RetroArch\config\Genesis Plus GX\Genesis Plus GX.cfg. RetroArch [INFO] :: Overrides: no game-specific overrides found at E:\Emulators\RetroArch\config\Genesis Plus GX\Castle of Illusion Starring Mickey Mouse (USA, Europe).cfg. RetroArch [INFO] :: Config: appending config “E:\Emulators\RetroArch\config\Genesis Plus GX\Genesis Plus GX.cfg”

[piikkisika]

Actually, seems that support for core specific configuration has vanished altogether in the latest build(s). There’s even no “Configuration Per-Core” option available in the Configuration submenu.

[hunterk]

per-core configs are indeed gone. they were buggy and messy, and anything you can do with them can be done with overrides and/or --appendconfig from the command line.

From what you described, you’ll be better-served by overrides, anyway, since you want most of your options to be the same and then you just put the handful of options you want to change into an override cfg. If you want to load a specific whole config file from the command line, just use -c /path/to/config.cfg

[piikkisika]

Ok, thanks for quick response. Sure I can do it with loading a whole config using -c, but the point is that previously it wasn’t necessary, which was great.

Actually I didn’t even use per-core config file at all, just the fact that whenever core_specific_config = true, then core overrides were not loaded. The reason for that was that whatever is set in --appendconfig file is overridden by what is set in core specific override if available so setting core_specific_config = true in the --appendconfig file was just a way get around that.

What I’d need is that --appendconfig works the other way around, such that what is set in --appendconfig file(s) takes always the most precedence. I understand that it’s not something that just can be changed, but could there be another command line parameter such as --overrideconfig that works just like --appendconfig, but overrides everything?

[piikkisika]

Thanks for your reply.

“Appendconfig works at startup. Overrides apply at content load so overrides are loaded later.”

That’s why I suggested a new command line parameter --overrideconfig, which would be applied last, after content has loaded and core/game specific overrides have been applied. The use case where I think --overrideconfig would be useful is described in the first message. If it’s too cryptic, I can try to explain it better. But later, now I’m on mobile.

[piikkisika]

Ok, I understand your point of view and respect that you took the time to respond.

However, I really think that RetroArch should have more flexibility with configurations. The current situation that you can have only one override configuration per core (not counting game specific overrides) is a severe limitation, because there are cores that implement support for more one system, some of which may require quite a bit different configurations. This is especially true considering the fact that there’s no concept of system in RetroArch, which implies that it’s not even possible for RetroArch to know which systems a core supports. That contradicts with the “one config override per core” philosophy and makes it impossible to make comprehensive configurations without compromises for cores supporting multiple system.

I know I’m not the only one with trouble of getting the configurations for genesis_plux_gx_libretro core to run both Game Gear games and Mastersystem/Genesis games. I’m not saying, though, that the command line parameter is the only, or the best, solution for the problem described, but it should be addressed somehow.

I hope I don’t seem too arrogant, I just try to be constructive with feedback. I really love RetroArch and appreciate your effort, and only want to make it better by improving the things I see could be improved.

[hunterk]

I’m not really seeing the problem. You can still launch a specific config with -c, you can append additional options with --appendconfig and you can override settings with override configs. RetroArch indeed doesn’t know what a ‘system’ is. If you want to do system-specific stuff, you’re going to need to use a frontend that cares about that stuff or compile multiple copies of the same core with different internal names so RetroArch sees them as different cores (I made a thread with such “split cores” in the Windows subforum; there’s genplusgx-sms, genplusgx-gg and gambatte-gbc).

[piikkisika]

The problem I have is that I would like to use core specific overrides as default configuration for a specific core, but if I do that, there’s no way I can override the settings that are set there with any kind of trickery in command line parameters or configuration files.

For example, for genesis_plus_gx_libretro I had core overrides that worked with Mastersystem and Genesis games and could be lauched simply calling retroarch.exe -L cores\genesis_plus_gx_libretro.dll <rom>.

“config\Genesis Plus GX\Genesis Plus GX.cfg” video_shader_enable = true video_shader = “:…\common-shaders\cgp\crt-royale-kurozumi.cgp” video_hard_sync = true core_options_path = “config\Genesis Plus GX\core-options.cfg”

Now with Game Gear games I could override those settings by using the following appendconfig file (by calling retroarch.exe -L cores\genesis_plus_gx_libretro.dll --appendconfig config\Genesis Plus GX\gg\gg.cfg <romname>), but it relied on the fact that setting core_specific_config = true disabled loading core overrides. Now that it doesn’t work anymore, my elegant solution is gone, since core overrides override everything, everytime.

“config\Genesis Plus GX\gg\gg.cfg” core_specific_config = true video_shader_enable = true video_shader = “:\shaders\shaders_cg\handheld\console-border\gg-5x.cgp” video_hard_sync = true video_scale_integer = false aspect_ratio_index = 2 core_options_path = “:\config\Genesis Plus GX\gg\core-options.cfg”

[FONT=arial] Everything else (i.e. not set in either of those files) is set in the main retroarch.cfg. [/FONT]

[Thatman84]

Hi guys,

I just wondered if you could confirm a couple of things as I’m a big per core config fan, being an inexperienced retroarch user and mainly using Android.

1. Will the removal of per core configs be global across platforms, specifically Android (I expect yes)

2. Is there any plans to make the overrides system less manual or will it always need a user to create the override config file by hand from scratch, or copy/paste. (From previous comments from Radius I also expect yes)

If I’m correct in my assumptions above imo this will make retroarch much more labour some to set up (in some/many cases). I know retroarch is not here to babysit inexperienced people but the override system does take quite a lot of time to fully learn.

Example making a simple override of an overlay enabled.

The process needed as I see it from someone that has never used retroarch. (Remember I’m android to user)

1. Get used to all the menus there are and how to apply/change

2. Identify the lines in the retroarch.cfg that are required (which can be hard as there is a fairly random order) or read the default.retroarch.cfg for details.

3. Create the override file and then figure out they need to be in a folder named “like the core name”

I know this stuff is not to difficult for most people and the benefits of using overrides is really good but from a novice usability point of view the above steps seem like something that would put people off. (Also this becomes much harder to do with a game pad and Android TV, easier to get the computer out and edit things like that, which makes it less user friendly again)

With per core config the steps as I see it.

Turn on per core config within the retroarch gui Make changes Exit (with save in exit on)

Everything gets created and that’s it done. This seems much more user friendly.

I don’t mind moving with the times but retroarch is very feature rich and per core configs is a good feature.

You guys do a grand job whatever will be will be. I just don’t like seeing negative comments elsewhere and here about retroarch. Hopefully my comments are not taken as negative that is not my intention.

Maybe another really good guide like the “getting started with retroarch” covering configurations and how they are read by retroarch and different ways to set things up, is in order.

[GemaH]

I was also using per-cores configs but after i was forced to make a fresh setup with overrides i wouldn’t want to go back. Before, i had 40+ different configs and whenever i wanted to do a change that affects all cores/systems, i had to edit all of them. Now i only need to change something in the default .cfg and the individual core differences stay in the overrides. And i can still load custom cfgs when i use a launcher anyway so i didn’t lose anything in the end, i was just forced to re-config my setup more efficiently.

Plus, i was using all those cfgs mainly for core and shaders loading. But now core loading doesn’t work from cfgs anymore and shaders are saved for each core just like controls per core do, so you don’t need a separate cfg for them anymore (unless it’s a core with multiple systems where you want different shaders).

It’s a much cleaner and easier to maintain setup, but yeah, it’s not as user friendly because you need to edit files outside the RetroArch Menu. However, i remember reading somewhere that “you can use overrides, however these can only be created manually for the time being”. So, based on that, i assume that in the near future we might be able to create these overrides through the menu, thus the user friendliness will be restored (i think).

But anyway, IMO, i think the only thing left now in order to eliminate the need for custom cfgs completely (even with launchers), would be to have separate system cores for all multi-system cores, like how Mednafen does it (with the exception of MESS for obvious reasons). Instead of one Gambatte core we could have two, one for GB classic and one for Color. Same with Genesis GX plus. Just how there’s already a Mednafed PSX, a Mednafen PCE, and so on. This would make per-core configs even less needed since we could use separate overrides and different shaders per system.

[Thatman84]

I think I will make the transition when I have time.

I can see the benefits and guess it will become easier if they override creation within menus happens.

I’m just spoilt by how good retroarch is now as I missed all the “good old days” it’s a bummer the launcher I use on Android can’t specify a config file but that’s not retroarch problem.

I agree the system thing would make things better for retroarch users

[piikkisika]

But anyway, IMO, i think the only thing left now in order to eliminate the need for custom cfgs completely (even with launchers), would be to have separate system cores for all multi-system cores, like how Mednafen does it (with the exception of MESS for obvious reasons). Instead of one Gambatte core we could have two, one for GB classic and one for Color. Same with Genesis GX plus. Just how there’s already a Mednafed PSX, a Mednafen PCE, and so on. This would make per-core configs even less needed since we could use separate overrides and different shaders per system.

Yes, that would simplify the configuration with those specific cores, but generally speaking I don’t think there should be such requirement for a core, that it should only implement one system. It’s not always that simple what qualifies as a system. For example, Game Boy Color can be seen as an extension to Game Boy, as all the games that work in the latter also work in the former (but not the other way around). Still it makes sense to see them as separate systems. But how about Sega Genesis and 32X, are they separate systems? By the same logic as with GB/GBC, they are. And what if you throw in another Genesis extension Sega CD, that can be with or without 32X. It just gets very messy.

Thus, I don’t think such requirements for cores should be put in place, but let core developers just implement which systems they desire. It is the libretro client (such as RetroArch) that should provide the means to cope with these multi-system cores in an elegant manner. And by elegant I mean that you have no need to manage multiple main config files, and no need to compile split cores on your own (needing to go through the tedious task of get the build environment up and running first, which is by no means something an average user should have to do), and no need to use some front-end for a simple task such as this.

[Thatman84]

Thanks for letting us know override saving is coming that will be awesome. Doesn’t matter when it comes it’s just really nice to know it’s on the radar.

Playlists overrides sounds like a really good way around “system” concept. Would that work by creating a playlist for all the games for a specific console. Then when a game chosen in said playlist is loaded specific overrides are applied.

That fine sir would be amazing.