Multiple actions with the same button assignments

Running into an issue with the new Input System regarding mapping multiple actions to the same button

It seems like this is not supported so if you try to enable two different actions that both are mapped to the B button only the first one enabled will actually fire and it also seems like the second one will never fire even after disabling the first action.

Is there an way around this? And is there any way to debug which action is actually consuming the button pushes?

 

Hmm, not sure what's going on there. On head of the develop branch, the following test passes just fine for me.

Code (CSharp):

1.     [Test]
2.     [Category("Actions")]
3.     public void Actions_CanTargetSameControlWithMultipleActions()
4.     {
5.         var gamepad = InputSystem.AddDevice<Gamepad>();
6.        
7.         var action1 = new InputAction("action1", binding: "<Gamepad>/buttonSouth");
8.         var action2 = new InputAction("action2", binding: "<Gamepad>/buttonSouth");
9.  
10.         var map = new InputActionMap("map");
11.         var action3 = map.AddAction("action3", binding: "<Gamepad>/buttonSouth");
12.         var action4 = map.AddAction("action4", binding: "<Gamepad>/buttonSouth");
13.        
14.         action1.Enable();
15.         action2.Enable();
16.         map.Enable();
17.  
18.         using (var trace = new InputActionTrace())
19.         {
20.             trace.SubscribeToAll();
21.            
22.             Press(gamepad.buttonSouth);
23.            
24.             var actions = trace.ToArray();
25.             Assert.That(actions, Has.Length.EqualTo(4 * 2));
26.             Assert.That(actions,
27.                 Has.Exactly(1).With.Property("phase").EqualTo(InputActionPhase.Started).And.Property("action")
28.                     .SameAs(action1).And.Property("control").SameAs(gamepad.buttonSouth));
29.             Assert.That(actions,
30.                 Has.Exactly(1).With.Property("phase").EqualTo(InputActionPhase.Performed).And.Property("action")
31.                     .SameAs(action1).And.Property("control").SameAs(gamepad.buttonSouth));
32.             Assert.That(actions,
33.                 Has.Exactly(1).With.Property("phase").EqualTo(InputActionPhase.Started).And.Property("action")
34.                     .SameAs(action2).And.Property("control").SameAs(gamepad.buttonSouth));
35.             Assert.That(actions,
36.                 Has.Exactly(1).With.Property("phase").EqualTo(InputActionPhase.Performed).And.Property("action")
37.                     .SameAs(action2).And.Property("control").SameAs(gamepad.buttonSouth));
38.             Assert.That(actions,
39.                 Has.Exactly(1).With.Property("phase").EqualTo(InputActionPhase.Started).And.Property("action")
40.                     .SameAs(action3).And.Property("control").SameAs(gamepad.buttonSouth));
41.             Assert.That(actions,
42.                 Has.Exactly(1).With.Property("phase").EqualTo(InputActionPhase.Performed).And.Property("action")
43.                     .SameAs(action3).And.Property("control").SameAs(gamepad.buttonSouth));
44.             Assert.That(actions,
45.                 Has.Exactly(1).With.Property("phase").EqualTo(InputActionPhase.Started).And.Property("action")
46.                     .SameAs(action4).And.Property("control").SameAs(gamepad.buttonSouth));
47.             Assert.That(actions,
48.                 Has.Exactly(1).With.Property("phase").EqualTo(InputActionPhase.Performed).And.Property("action")
49.                     .SameAs(action4).And.Property("control").SameAs(gamepad.buttonSouth));
50.         }
51.     }
52.  

So there must be something else at play here.

Could you give it a try with the 0.2-preview package once it's out? (we've hit delay after delay due to me making stacks of changes in the action stuff)

Also, when you look at the input debugger in play mode, are both actions showing up in the tree and both have the button listed under them?

There isn't really a concept of "consuming input" in the action system. If an action binds to a control, it should receive input from it. Actions will by themselves not make an effort to orchestrate input processing between each other.

 

I've decided to go back to stock input for my game since input demands are simple but I can still answer some of these questions

I did look at the input debugger and what showed in the debugger was always consistent with what was receiving the events. So I guess that means that it's the enable/disable functionality that's working inconsistently.

At some point when I have the time I will create a project specifically to try to reproduce this behavior and see if I can get you some better data

 

I filed a bug report about this (some inputs receiving a value of zero when read a second time). Unity marked it as a duplicate of the following issue (linked), so I voted on that issue to be fixed. You should too if it's causing you problems (in my case I'm postponing upgrading to newer versions of Unity and the Input System) else who knows if Unity will ever consider it important enough to be fixed.

https://issuetracker.unity3d.com/is...ot-received-when-using-input-system-1-dot-4-1