We’re developing a VR application and struggling to get the input system working. We have 3 mapping contexts in the PMI asset: one for player movement input (joysticks), one for tracking the hand pose (touch buttons), one for menu (oculus menu button).
We now try to add a 4th context, which is the same as the first one, joysticks, but is set up for left-handed instead of right-handed people. However as soon as we add this fourth input mapping context to the PMI asset, all inputs break.
Do you really need 4 mapping contexts at the same time?
I think you might be using the context not as it is intended.
Mapping contexts should be used for specific areas
Like
An inventory mapping context could have controls that only work in the games inventory
A menu mapping context for menus
A In-game mapping context for character actions
A vehicle mapping context
You would remove other mapping contexts while switching areas.
etc
Other mapping contexts would be removed before adding the new one so the input’s change between the areas of the game.
If your VR game uses touch, joystick and hand tracking you should probably have this in one mapping context.
The same action in the mapping context can have multiple controller inputs (keyboard,mouse,gamepad,vr inputs)
The only plausible context change would maybe be for VR versus the rest , if the input outcome really changes the logic computations.
You are right that we could indeed coalesce some of these contexts.
However we are not using these 4 contexts at the same time – only 3 are active together at any time. As far as I can tell, the very action of adding a mapping context to the list inside the PMI asset – without actually activating it – is enough to break this system.
If the PMI asset can only hold up to 3 contexts at any time, that seems like an issue (even your example given above lists 4 already), however at the very least this behaviour should be documented somewhere, no?
There’s no limit to the amount of IMC’s the PMI can contain, the VR Template contains 5 (for reference). What I think you’re coming across here, is that you have one or more Input Mapping Contexts (or Input Actions) that has the same Description. This will break Enhanced Input as the Descriptions has to be unique.