I guess I should explain the difference between all the configuration files we have to avoid users getting confused.
Retroarch main cfg, usually retroarch.cfg, you can load different config files via the --config (-c) command line parameter or via GUI. You can also append (although the proper term would be stack) config files via the --append command line parameter. That way you can have a partial file that gets never modified on top of your usual config.
The main configuration NEVER stores remap data.
Overrides: similar to append config (it uses the same internal functions but it’s automated), their purpose is to have some parameters different from the main config without the changes being reflected on the main config.
- You can save overrides via the GUI (quick menu->overrides)
- Overrides are loaded automatically on content load
There are three types of overrides implemented at the moment:
- Core overrides (file will be named after the internal core name. Override will be loaded whenever content is loaded with that core)
- Content overrides (file will be named after the game name inside a folder named after the core. Override will be loaded whenever the content is loaded with that core)
- Content directory overrides (file will be named after the parent directory, it will be saved inside a folder named after the core. Override will be loaded whenever content is loaded from the dir with the core that was used before)
Say we save overrides for: c:\games\genesis\sonic.md using the picodrive core
- Core override: config/dir/Picodrive/Picodrive.conf
- Content dir override: config/dir/Picodrive/genesis.conf
- Content override: config/dir/Picodrive/sonic.conf
Overrides are loaded in that order, core, dir, content. It’s possible to have stacking but it’s not advised, saving overrides doesn’t consider stacking. Saving will compare main config and current config only. Won’t take other overrides into consideration.
Overrides can’t save parameters that aren’t part of the settings struct, like soft filters, input_dpad_analog settings, input_libretro_device. Also they can’t store input bidings as of now. There are more but it’s not fully documented.
input_dpad_analog, input_libretro_device and video_shader are blacklisted on purpose.
Even though those can’t be saved from the GUI they may still load fine if added directly via a text editor.
When an override is active, changes to the config will not be saved automatically
Remaps are configuration files that store the parameters from the controls menu under Quick Menu. This is the recommended method to change core inputs without affecting GUI control or controls for other cores. We’ve been working hard to make this menu support all input remapping usecases and as of now it can do:
- Mapping keyboard keys from more than one gamepad (works with dosbox)
- Mapping more than one button to the same action
- Unmapping buttons
- Unmapping analogs
- Mapping a button to trigger an analog response (tested with mupen, can run on SM64 with the d-pad now, triggers a full analog tilt)
- Mapping an analog to another analog (having more than one analog mapped to the same output causes issues)
- Mapping an analog to produce a button response
Remaps can be saved in the same exact levels as overrides, core, content, dir. Remaps can save dpad analogue mode, libretro device.
Remaps are loaded on content load.
to be continued