1.1.0-preview 2 and preview3 changed Inputhandling

Hey there,

Using Unity 2020.2.4f1

Updated from Input System 1.0.2 to 1.1.0-preview.3 and immediately noticed that my input behaves different now.

I setup a composite binding for movement like this:

With 1.0.2 I could walk my diagonally with my character in my 2D game, with 1.1.0 I can’t anymore.

My code to process the movement right now:

 public void OnMovement(InputAction.CallbackContext context)
        {
            //TODO: Fix Animations!
            Vector2 input = context.ReadValue<Vector2>();
            switch (context.phase)
            {
                case InputActionPhase.Started:
                    Log.Info("Started Move Input");
                    facingDirection                = GetInputDirection(input);
                    gameEntity.SpriteAnimatable.SetAnimationState(AnimationState.WALK);

                    break;
                case InputActionPhase.Performed:
                    Log.Info("Performed Move Input");
                    facingDirection                = GetInputDirection(input);

                    SetPlayerDestination(input);

                    break;
                case InputActionPhase.Canceled:
                    Log.Info("Canceled Move Input");
                    gameEntity.LastFacingDirection = facingDirection;
                    input                          = Vector2.zero;
                    SetPlayerDestination(input);

                    gameEntity.SpriteAnimatable.SetAnimationState(AnimationState.IDLE);
                    break;
            }
        }

I upgraded from 1.0.2 to 1.1.0 preview 1 and there everything was working as with 1.0.2.
Tested with 1.1.0 preview2 and there the issue happens, too, so apparently something was changed or introduced in preview2

So my questions are:

  1. What changed with 1.1.0? Is this maybe a bug? Do I have to specifiy something specific now in the InputAction Asset or maybe in code to make it work like in 1.0.2?
    I looked into the docs and I don’t know exactly what influenced this behaviour,
    was it this:

If so, I tweaked the values in the Global Settings and apparently nothing changed.

  1. I also have the feeling that I don’t understand how the “Canceled” Phase works.
    In 1.0.2 it’s like this:

When I hit “D” and hold the key on my keyboard my character walks to the right all the way. When I release it, they stop.
When I hit “D” and hold the key and at some point hit “S” and hold it (while also holding D) on my keyboard, the input gets canceled and they stop walking. When I release the D key they walk to the left and the started/performed phases for the S-binding get processed. Now this I understand.

But this does not happen if I do the same with this:
when I start hitting and holding “D” and then also hit the “W” key, the character moves diagonally to the right, which is my personal desired behaviour, but if it would be consistent shouldn’t it cancel the input of “D”?

From the sound of it, my immediate reaction would be “sounds like a regression” but gimme a moment to dig a bit into it.

The action you have is probably a Value action and thus wouldn’t be affected by the Button action changes but could well but that part of the changes around that have an unintended side-effect.

And also thanks for looking into this that quick @Rene-Damm :slight_smile:

Hmmm…the movement action is of Action Type “Button”, but with your post now and the changelog it all makes sense.
I just changed the action type to “Value” and set it to “Vector 2D” as Control Type and I got my desired results.
Seemed just a misunderstanding on my end, sorry about that.

BUT I’d still highly appreciate if you could answer the question about the Cancel-Phase in the initial post :slight_smile:

Ah that’s great to hear :slight_smile:

The current action editor stuff isn’t very helpful in diagnosing these kinds of things. It has some very limited support for trying to steer away from setups that won’t work in practice but it’s still easily possible to end up with something that won’t work as intended and the action editor not providing any helpful hints that this is the case.

Ah right. So the canceling pertains to the interaction happening on the action as a whole. If an individual input “cancels” but other inputs keep the action going, the interaction remains ongoing and the action won’t cancel.

Basically it’s part of the whole “abstract away from physical inputs and present a ‘unified’ logical input instead” approach.

So for a Value type action of type Vector2, the cancellation happens when the last Vector2 input bound to the action goes to (0,0). And with one key in a WASD composite still down and thus the composite returning a non-zero value, the action will keep going.

Does that… explain anything at all? :slight_smile:

1 Like

Yes absolutely Rene, thank you very much, makes total sense.
I’ll mark this thread/issue as resolved :slight_smile: