player input action/axes names to properties autogeneration and autoexposion


Current state:
Now you need to define action names by hand in over 3 places: editor/ini, cpp input binding, umg input events

It would be usefull if UHT will parse project file DefaultInput.ini and collects all action and axes mapping names you added there from editor or code enviroment and export this list then to some autogenerated file with static properties or constants, so you can use them in cpp or blueprints.

you add in editor new input action “USE” and assign "E "key to it
it saves it to DefaultInput.ini


when you run project building it parses DefaultInput.ini and collects “USE” as ActionName (similar to UInputSettings::GetActionNames() does at runtime)
then it adds new property const or static to a class in some autogenerated file with name: “InputAction_USE” and marks it to be exposed for blueprint

then you can simply use it in cpp in SetupInputComponent() like

InputComponent->BindAction(InputAction_USE, IE_Pressed, this, &AClass::function);

then you can simply get and use it in blueprint where it required, for example in “ListenForInputAction” node

So, what it does for developer:

  1. you define input name in one single place
  2. then you can simply use constant names placed to variables everywhere
  3. you will not do any mistake when writing action name by hand anywhere

+1 … In addition:


Its all too easy to break the Input system during integration of outside 3rd-party projects. You can end up with silent failures with INI / Project-Setting-Inputs no longer binding to any Events (lost among endless trivial warnings). An ability to Merge Inputs could help big-time here, with a way to rename each and keep both (as per Windows Explorer file copies etc).


Overall, an ability to audit Projects for Inputs would cover important cases such as bindings that are just ‘dropped into’ Pawns directly. These separate / isolated in-graph Bindings, could then be added to the master Project-Settings-Inputs, or show up in an INI etc. If so, the whole process would be more streamlined. Since Epic is working on BP-Text assets anyway, perhaps 3rd-party tools with Advanced-Search will have a role to play here…