Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.

    Read our full announcement for more information and let us know if you have any questions.

Button Action Input Type and Enable/Disable don't seem to play along well?

Discussion in 'Input System' started by Yoraiz0r, Sep 7, 2019.

  1. Yoraiz0r


    Apr 26, 2015
    Hello all,
    First I want to say new input system is fantastic and miles more convenient to use than the former system, it's been a blast to integrate it into my current project!

    Now - regarding the topic mentioned in the title:
    • I have an InputActionAsset that I enable/disable for certain events in the game. (I do it via the c# generated class for my input mapping's enable/disable for specific Action Maps)
    • If I have a button held down, and I disable the actionmap, the button triggers a canceled event.
    • If I have a button held down, and I enable the actionmap, the button does NOT trigger a started event (or any event at all).
    • (Not sure if relevant) releasing the-event-skipped button while the map is active, then pressing it again works perfectly fine.
    the fact that a button doesn't get started once the map is enabled is slightly inconvenient, did I encounter a bug or is this an intended behavior? If it is an intended behavior, is there any way to undo it / properly re-trigger the events / never cancel them to begin with?

    Thank you for your time!
  2. Rene-Damm


    Sep 15, 2012
    Nice to hear :)

    Yup, that's indeed intended.

    So, the thinking here is that if, for example, you go into a menu screen and the escape key is bound to an action that exits the menu, then if the escape key is already pressed when going into the menu, it still shouldn't just quit the menu.

    The easiest way is to just switch the action to be a "Value" type action. Basically what you're saying to the system with that is that you want your action to respond to and relate the current value the controls bound to it. Which, unlike for buttons, will make it immediately respond to whatever the current value is. I.e. if a button is already pressed when the action is enabled, the action will simply go and immediately pick up that value.

    Note, however, that you still get the cancelling. When you disable an action that's in progress, it'll cancel itself. That part invariably happens.

    The one exception to that is "Pass-Through" actions. These basically bypass almost all of the built-in behaviors of actions. A pass-through action never cancels and it never starts. It simply performs every time an input value changes.

    ATM pass-through actions don't perform that "initial state check", though, that value actions do. Meaning that when a pass-through action is enabled and one of its bound controls is already actuated, the pass-through action won't do anything. It'll require actual input in order for it to trigger/perform.
    Yoraiz0r likes this.