Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Enabling ActionMap emits InputAction callback.

Discussion in 'Input System' started by RegdayNull, Jul 4, 2020.

  1. RegdayNull

    RegdayNull

    Joined:
    Sep 28, 2015
    Posts:
    65
    Hi.
    I am making simple join system, that listening unpaired devices. Simple flow.
    1. Press A to join (via onUnpairedDeviceUsed)
    2. Create a player and Enable some ActionMap, that uses A.
    3. This ActionMap instantly sends InputAction.CallbackContext to the handler. With performed and cancelled events, not only cancelled. Why? Any way to solve this?

    Unity 2019.3.13f1, latest available InputSystem package.
     
  2. rejemy

    rejemy

    Joined:
    Nov 1, 2013
    Posts:
    13
    I'm also running into this issue. I have two InputActionMaps that correspond to different controls for movement and using the pop-up menu system. However, when I disable one InputActionMap enable the other, the new one instantly processes the button that is still down from the action that enabled it, and fires the action and does something unwanted. I'm thinking about putting in a pause before enabling the other InputActionMap, but it seems a bit sloppy because the player could hold the button down an arbitrarily long time. What would be really helpful is a way to tell the input system to ignore all all input already happening, so it can start fresh. Not sure how to do that.
     
  3. rejemy

    rejemy

    Joined:
    Nov 1, 2013
    Posts:
    13
    It occurs to me that one solution would be to make any action that can result in an input state change only fire on button release. It still feels like a sloppy solution though, for a few reasons:

    Actions that cause input schemes to change will feel slower than other actions, due to firing on button up instead of button down.

    As a programmer you have to be careful of any action handler that could cause input maps to change, even as side effect in other code.

    It also can still fail and cause weird things to happen, because a player could randomly be holding down another button when they do something that causes a change of input maps. A cleaner solution would still be to have some way of asking the input system to ignore all actions that started before the InputActionMap is enabled.
     
  4. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Set the action type to "Button".

    Not the most obvious thing. "Value" performs what's internally called an 'initial state check'. I.e. if an action of type "Value" is enabled, it will go and check the state of its bound controls in the next update and if they are already actuated, will fire. This is designed so that, for example, a "Move" action bound to the left stick will immediately make the character move if the stick is already actuated -- instead of first requiring the stick to change value.

    "Button" type actions, on the other hand, will not perform that 'initial state check'.
     
  5. RegdayNull

    RegdayNull

    Joined:
    Sep 28, 2015
    Posts:
    65
    The type is "Button". No any InputActionMap enabled during joining routine, though. I've started sheduling and switching InputActionMaps in LateUpdate. That's fixed the issue. Canceled events still called, but it is not problem for me. But it can be. I've found another weird behaviour. If "safe callback calling" crashed (i.e. any exception in bound callback function) - callback will be called next frame again, but only once.
     
  6. rejemy

    rejemy

    Joined:
    Nov 1, 2013
    Posts:
    13
    Thanks Rene-Damm, that was my problem. For some reason I thought that button-type controls defaulted to InputActionType.Button, but apparently not! Manually setting them to button gives me the behavior I want!