"Save Key Mappings" node working in editor but not packaged?

Development Programming & Scripting Blueprint
, , ,
1

Hi all, I’m using the “Save Key Mappings” node to save my input mappings and it works fine in editor, but when I package the game it no longer works.

As far as I can tell in the editor it saves it to the file “[ProjectDirectory]\Saved\Config\WindowsEditor\Input.ini” but then in packaged that file doesn’t exist - is there any way I can make it exist in a packaged game and work like it does in editor?

image
image495×304 22.8 KB

2

Update: If I manually put “Input.ini” in the packaged game in “Saved\Config\Windows” it will read the file, it just won’t write to it with “Save Key Mappings”. So yeah, I just don’t get how to make it write to that file when packaged like it does in the editor.

3

A few things to check, since “Save Key Mappings” (the legacy Input Settings path) is unreliable in packaged builds:

  1. Where it writes: a packaged game writes config to //Saved/Config/Windows/ (note “Windows”, not “WindowsEditor”), or under %LOCALAPPDATA%//Saved/Config/Windows/ when the game is installed somewhere not writable (e.g. Program Files) or run as a Shipping build. Search both locations after calling the node, the file may exist but not where you looked.
  2. The legacy node only saves bindings that go through the Player Input / Input Settings system. If you are using Enhanced Input (default in 5.x), those rebinds aren’t stored in Input.ini at all. Use the Enhanced Input User Settings (Project Settings > Engine > Enhanced Input > User Settings, “Enable User Settings”), then call Map Player Key on the Enhanced Input User Settings object and Save Settings. It saves to a SaveGame slot, which works the same in packaged builds.
  3. The most robust, engine-agnostic approach: create your own SaveGame class holding an array of (Action Name, Key) structs. On rebind, write it to a slot with “Save Game to Slot”; on startup, load it and re-apply with Enhanced Input’s Map Player Key (or Input Settings’ Add Action Mapping). SaveGame slots live in Saved/SaveGames and always work packaged.
  4. Make sure Input.ini isn’t marked read-only in the package and that you aren’t running the build from a read-only location.

I’d go with option 2 or 3 for anything you plan to ship.

4

chen is right about the path difference, and there is one more layer: that node only saves the legacy input settings bindings. if your project uses enhanced input those rebinds never touch input.ini at all, so packaged or not there is nothing to write.

the packaged safe route is the enhanced input user settings. turn on enable user settings in project settings under enhanced input, apply rebinds with map player key and call save settings. that writes a savegame slot instead of an ini file, and the subsystem reloads it on boot, so it behaves teh same in editor and packaged. keep a reset to defaults button that calls reset to default so players can undo bad binds.

you can also try Advanced Input Rebinding System, a profile saving addon for Unreal Engine that persists rebinds across sessions and packaged builds with reset to defaults included: Advanced Input Rebinding — Enhanced Input Key Remapping, Profiles & Cloud Sync | Fab

5

Thank you both for the replies. In the end, I did indeed go through the tedium of manually saving each binding to a SaveGame slot and then loading them in etc!