Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
New Forum User Notice Update to the Unity Editor Software Terms

Bug New Input System not installed in 2020.1 after enabling it

Discussion in 'Input System' started by fherbst, Jun 8, 2020.

  1. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    801
    I just noticed that some of our code and some Unity packages broke in 2020.1 after enabling New Input System in Project Settings. Turns out, enabling it will not install the Input System package anymore, essentially breaking all asmdefs that have specific Version Defines for that.

    Is this supposed to work that way? Is this now built-in, and is there a new ifdef that should be used going forward? I couldn't find any docs about this.

    Installing the Input System package in 2020.1 fixes the issue, but previously it was automatically installed when selecting that option in Player Settings.
     
    fherbst, Jun 8, 2020
    #1
    FerdowsurAsif likes this.

  2. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    To the best of my knowledge, this was never the case. Toggling the input backend in the player settings triggers a restart of the editor (gated by a confirm dialog) but otherwise should have no impact on the project and wouldn't modify the package manifest of the project.

    Recommended practice is to have a version define depending on com.unity.inputsystem. This one should only come into effect with the input system package installed (and matching the min version spec).
     
    Rene-Damm, Jun 9, 2020
    #2

  3. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    801
    This is how the dialogue looks like:

    upload_2020-6-9_12-14-23.png

    I can confirm that in 2019.3 it also does not install the package in a fresh project, however I'm still confused.
    Doesn't that mean that whenever someone toggles this to "Input System Package" they must install the Input System package manually, otherwise the project is in a broken state (no input)?

    (for comparison, enabling XR installs the required XR Plugin Management package automatically)

    As said, this behaviour currently breaks a couple Unity-owned packages (e.g. Device Simulator) that have these ifdefs and stop working without first adding the package manually (they just don't do anything anymore). They actually have hacky code in place to check the settings option directly, but only if INPUT_SYSTEM_INSTALLED (which is based on the package being there).
    upload_2020-6-9_12-18-54.png

    So, what's best practice here?
    Or, to put it differently: How can I make sure to wrap old "Input." calls in a way that prevents the code from running when new input is active? Seems I can't really rely on the package being installed after people switched on the option.
    Note: there's exceptions thrown when accessing Input code when only "New Input" is active, that's how I even found the issue.
     
    fherbst, Jun 9, 2020
    #3

  4. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Unfortunately, yes. ATM there's no automatic installation based on that setting. The setting is automatically changed (again gated by a dialog) when installing the package but ATM the same doesn't work the other way round.

    That sounds correct. Is the problem that this #if becomes enabled *without* the package being installed?

    Recommended practice is to use a version define on .asmdefs keyed to the com.unity.inputsystem package. The #define should become active only if the *package* is installed and should not be affected by the player setting.
     
    Rene-Damm, Jun 9, 2020
    #4
    OnatKorucu likes this.

  5. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    801
    The issue we were running is that some people have the toggle on "New Input System" and don't have the package installed. This, besides breaking our code, breakes the aforementioned Unity packages, based on ifdefs that are now not set and the code accessing the Input class (which errors).

    There is no warning, error or anything that this is a broken state.
     
    fherbst, Jun 9, 2020
    #5

  6. Rene-Damm

    Rene-Damm

    Unity Technologies

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    It's possible to detect the case of the backend setting having been toggle but the package *not* being present. The latter can be covered with a version define in an .asmdef file. The backend setting found in the player setings, however, is covered by #defines, too. See docs:

    Code (CSharp):
    1. When the new input backends are enabled, the ENABLE_INPUT_SYSTEM=1
    2. C# #define is added to builds. Similarly, when the old input backends are enabled, the
    3. ENABLE_LEGACY_INPUT_MANAGER=1 C# #define is added. Because both can be
    4. enabled at the same time, it is possible for both defines to be 1 at the same time.
    Agree, though, that the player setting being set to the input setting should mandate the package.
     
    Rene-Damm, Jun 10, 2020
    #6