Setting Up the New Unity Input System in Unity 2021
For the most up-to-date instructions on any process, it is always best to look directly to the source.
These instructions are also customized to the Unity version you are currently using so make sure that the documentation version of Unity matches your Editor version.
As always, Unity makes it easy to import modular components of the Editor via the Package Manager.
Simply select Window > Package Manager, set “Packages” to Unity Registry, and scroll down to or search for “Input System”.
Select and click Install.
A pop-up dialog will appear asking if you want to enable the backends.
If you do not want to use the old Unity input system ever, click yes.
This is recommended for new projects.
If in the future you change your mind, you can change this setting by going to Edit > Project Settings > Player > Other Settings > Configuration > Active Input Handling.
If you wish to use both the old and new Unity input systems simultaneously, click “No” on the pop-up dialog and then change the Active Input Handling setting in Project Settings to “Both” which will also prompt you to restart the Unity Editor.
But I Can’t Find “Active Input Handling” in Project Settings…
If you do not see “Active Input Handling” in the Project Settings, navigate to Project Settings > Player > Other Settings > Configuration > Api Compatibility Level.
If you see “.Net Standard 2.0”, you will need to change this API setting.
In older versions of Unity, select “.Net 4.x”.
For newer versions of Unity, Select “.NET Standard 2.1”.
What is Going on with the .Net Version Numbers?
You might be wondering why .Net version 2.1 is used instead of 4.x in newer Unity versions.
The simple explanation: Microsoft sucks at naming things.
Let’s face it, they named everything in their OS based on real life objects from a physical office.
Desktop, folders, trash bin, etc.
Want to view something else on your Windows PC?
We’ll call it looking out a new “window”!
In all fairness, that led to easier adoption for those of us born before the dawning of this millennium.
In the case of .Net frameworks though, it is actually just confusing for no reason since they kept naming new frameworks (.Net Core) the same as old frameworks (.Net Framework).
Not to mention, the original framework has “framework” in the name while the new framework does not, just to add another layer of confusion to it all.
First, there was .NET Framework going all the way back to 2002.
Then there was .NET Core, relatively new by comparison having come out in 2016.
If .Net Framework had died in 2016 or close to it, the confusion would be much less, but it continued on until 2019, giving developers 3+ years of overlap.
Speaking of overlap, both .Net Framework and .Net core shared overlapping APIs as well which is no doubt what led to the unimaginative naming scheme for .Net core in the first place.
Microsoft either saw this naming convention problem ahead of time, circa 2012 when they introduced .Net Standard, or they just really liked naming more things as .Net.
Joking aside, .Net Standard was used to identify the version of .Net Framework, .Net Core (also a framework) and other frameworks such as Mono, Xamarin, UWP, and Unity under one umbrella for compatibility purposes.
Long story short, .Net Standard describes the particular versions of .Net Core, .Net Framework, and other frameworks under its own separate version number.
One version number to rule them all.
In earlier versions of Unity, “.Net 4.x” referred to the .Net Framework.
In newer versions of Unity, it explicitly states .Net Standard, which would include a version of .Net Core and also a version of .Net Framework except that after .Net Standard 2.0, .Net Framework no longer exists and thus it refers simply to .Net Core as well as other Frameworks such as Mono, Unity, and Xamarin.
But don’t worry, now that you’re caught up, you can expect all of this to change again with .Net 5 (Core)!
Per Microsoft, “The motivation behind .NET Standard was to establish greater uniformity in the .NET ecosystem.
.NET 5 and later versions adopt a different approach to establishing uniformity that eliminates the need for .NET Standard in most scenarios.”
The crux of the problem is everyone wants to say .Net [insert version] and leave it at that.
Even Microsoft did that in their documentation above.
But without adding “Standard”, “Core”, or “Framework”, we open ourselves up to confusion!
Okay, I’m Done with My Tangent (Or was it a Side Quest?)
That’s it for this article, I hope you enjoyed!
