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.
1 Like
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).
This is how the dialogue looks like:
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).
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.
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.
1 Like
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.
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:
When the new input backends are enabled, the ENABLE_INPUT_SYSTEM=1
C# #define is added to builds. Similarly, when the old input backends are enabled, the
ENABLE_LEGACY_INPUT_MANAGER=1 C# #define is added. Because both can be
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.
