First thing first, i’m using a custom branch of engine source code master branch (so is more 4.28 than 4.27) where i have enabled Motion Controllers mapping in the Input Mapping Context, you can see the pull request here https://github.com/EpicGames/UnrealEngine/pull/8389 .
This also happen with UE5 Early Access 2.
Now that i can map Motion Controllers to an Input Action i noticed a weird behavior, the Input Action is triggered only if the Motion Controller key i want to use is also bind in the project settings.
For example, if i want to use the A button on my Valve Index Controllers i have to:
- Go in project settings → engine → input
- Create an action mapping and bind button A
- Create an Input Action
- Add the Input Action to the Input Mapping Context and bind it to the button A
- Use my Input Action where i need it
Looks like the action mapping we create in the project settings “act like a bridge” between the Motion Controller and the Input Mapping Context, you don’t even need to use the action mapping, it just has to be here as a dummy.
This happen only with Motion Controllers, or at least with Valve Index Controller (i only have this VR device so i can’t test on others like Quest 1/2), mouse, keyboard and gamepad works fine.
I wonder if is a limitation of the Enhanced input system or of OpenXR Input.
They probably haven’t implemented VR input support for the enhanced input system.
The way the input system in OpenXR works is that you set up a set of actions and add suggested button mappings to each one. After that you don’t have direct access to the buttons. The input is communicated entirely though the actions. This is likely why the button mappings for motion controllers are hidden.
You are right, in the FOpenXRInput::BuildActions() function they get the mappings from InputSettings, for what i understand looks like not an easy task to include ICMs here.
Maybe create different OpenXR input profiles for each ICMs could be an idea.
I mean, right now make all the action mapping for each controller input into the project settings and let them works like bridges is the easiest way to deal with it, but it would be fun work on some code that avoid it
After exploring the code a little more in deep looks like rebuild the OpenXR Input mapping on the fly everytime you change the ICM it could be a solution.
Ok, after exploring the code again i think the easy way to deal with it is still map all the motion controller inputs in project settings like in the example project and than use Input Action as i described in the OP, too many classes involved and trying to remap inputs on the fly require to change the code in classes that doesn’t need to know about the existence of the Enhanced Input plugin, place references of the plugin into the engine source code here and there is not possible because it will break the purpose of the plugin to be … a plugin.
Maybe in the future the Enhanced Input code will be core stuff inside UE5 instead of a plugin an it will make sense to change other classes code.
@VictorLerp is this going to be a continued issue in upcoming releases?
This is correct, but it’s our plan to do so! Expect this sometime after 5.0 however.
Any update on Enhanced Input implementation timeline?
The work has started and we’re aiming for 5.1, but that could change at any time so don’t plan as if that’s a given!
Other than potential dev confusion, are there any downside to building with both systems? I have most of my inputs using Enhanced and as long as I use that work around its fine, but since both are being ping’d I also have some inputs just using just the regular input system.
I’m honestly not sure how you’re using it atm, but I’d recommend you stick with the traditional method until we support it officially!