I have a menu that allows a player to re-assign the key binds. The modified key bind data is written to a new file called “PlayerInput.ini” rather than overwriting DefaultInput.ini. My question now is what needs to be called or changed to get the engine to load this new config file instead of using the DefaultInput.ini file?
You would probably have to dig deep into the engine source.
Happy hunting 
oasf, that isn’t an answer. If you literally have no clue of the answer, then do everyone a favour and refrain from posting.
The config stuff for player inputs is really overly complicated and inflexible. I decided to ditch most of it and go with a simpler and more flexible setup.
It really isn’t.
Part of the problem is you shouldn’t be saving to a separate file in the first place. Config properties are read following the config file hierarchy. What you want to is to be saving to the last file, in the user’s saved directory. The config path is auto determinated depending on shipping/non-shipping, installed/non-installed builds, but you can work around that by using FPaths::GeneratedConfigDir(). Call SaveConfig on your input settings giving it that path, and it will be automatically read at load time.
I havent checked his code yet but Rama usually do good stuff so you should look at it.
Except if you have a good reason, I would not set the userbinding in DEfaultInput file. Just because it’s the default configuration that you set for your game when you built it.
If you override the default ini, you won’t be able to revert to the default configuration without harcoding it in another place.
During the development, you are updating the DefaultInput file manually or via the Editor interface then your UI should update the user ini file so the default settings will be overriden and loaded properly.
If you don’t want to follow this approach, I would suggest that you look at the Engine code level, how they built their Editor UI for keybinding.
if you don’t want to mess with the engine, another option would be to create a controller config manager in your game layer.
the manager can load a DefaultControllerConfig.ini file with various controller configurations.
i.e.
FConfigCacheIni::LoadGlobalIniFile(UControllerConfigManager::ControllerConfigFileName, TEXT(“ControllerConfig”));
in our case, we have default configurations set to be perobjectconfig.
when a user selects a controller config, it will copy the binding values over to PC->PlayerInput
It was meant as an indication to the complexity of the task at hand.
Your answer, however, was completely useless…
I’m taking another look at the stock config system. (Glutton for punishment, I guess.) The biggest problem I’m seeing is that the existing system doesn’t clean up after itself. For example, if I rebind a “Fire” action 20 times, I get 20 “Fire” entries in the ini file. This is unwanted behavior.
How and when are you saving the input settings class?
Saving when the user hits the apply button and the menu closes.
UInputSettings::StaticClass()->GetDefaultObject<UInputSettings>()->SaveConfig();
I do a RemoveActionMapping() followed by AddActionMapping() with the new bind before saving.
Sounds right. Since InputSettings is DefaultConfig, IIRC SaveConfig without parameters overwrites Default, is that what’s happening? There are a few provisions to change the path depending on shipping/non-shipping and installed/non-installed builds, it should be saving to FPaths::GeneratedConfigDir() but I haven’t touched input settings in a while.
If this is being done while a game is running, you’ll also have to call ForceRebuildingKeyMaps on your PlayerInput in order for it to reflect changes that have been made.
On a tangential note, handy shortcut for getting default objects: GetDefault<UInputSettings>()->SaveConfig();