We just released a preview release of the Input System (1.8.0-pre.1) which contains a new feature called Project-wide Actions. We would love to get your feedback after trying it out. Since this is a pre-release feature your feedback will go a long way in shaping it and improving it for everyone else. Please use this form for your comments https://forms.gle/67brxDs5xWtzGGmz9
We added default project wide actions which should help with prototyping and improve some of the main workflows of the Input System. These actions are available from the Input System settings tab in the Project Settings.
Installation
You can go to Package Manager → Add Package and add it to a project there if Input System isn’t already present in your project.
Otherwise you can manually edit your /Packages/manifest.json file and add “com.unity.inputsystem”: “1.8.0-pre.1” to the dependencies.
Once backports land it will also be discoverable in the package manager if preview packages are enabled in the Preferences.
The minimum Unity version needed is 2022.3.0.
KNOWN ISSUES
When opening the Input Debugger window, the window can be empty on first install. To workaround this issue try switching the Input backends back and forth in the Project Settings → Player menu.
The Project Settings → Input Manager can also be broken on first installs, to fix this try switching the Input backends back and forth in the Project Settings → Player menu.
These newly added project wide input actions are modifiable but currently, there is no way to reset them to their defaults, please keep that in mind when modifying them.
I don’t know about this.
It does make it easier to learn the input system which is great. But not having the flexibility of assets feels a bit dangerous on a large project.
Generally I think project-wide settings should be avoided.
I think it goes back to the compromise of making the tool easy to learn or making it robust for big projects.
Maybe having the window show all of the Input Actions assets that were found in the project, and creating one by default when installing the package would achieve the same thing?
(I wasn’t able to access the from, did you close it?)
You can still create new action map assets yourself and use them just as before. The global actions are just a default set that you can use to start with and expand if needed.
Wiil check on the form tomorrow when I’m back at the office.
Here is some khm grumpy feedback just in case. I still standing astonished how you guys don’t talk to each other. Every fricking department develops their own solution to problems. Why wouldn’t you use the already editor-wide standard method to embed an action asset in the settings page like the: input settings, URP settings, HDRP settings (just from the top of my mind) do? Now you will be chasing a metric ton of silly bugs instead of rely on the more mature editor you already have… Anyway.
Having a global setting for input is finally a good starting point to leverage inputs in a rational way.
Here is my two cents.
As you did with graphics, you should have a selector on top that selects the currently active “Action Map” and switches input action assets during runtime/editor time ( Really needed, especially runtime ). In this way, you have the old-fashioned new input system with assets but you select literally the “default input action asset” by default project-wise.
P.S.
Why rewrite the entire UI for the new project inspector, when you already have it???
The need to stay in project settings is because you want to leverage an input action project-wise, already set. That is cool, but… why do you simply put an input action selector in the project settings with the default input action already selected?
Hello. I have to say that I agree with this. If it simply created an input action file and selected it as the “project-wide default” file all videos and tutorials about the new input system would still be widely relevant and just an addendum would have sufficed to the content creators out there.
That said, it comes with everything already configured for basic needs which is excellent for beginners. As one myself, which has been barred of this whole new input thingy the whole time because the interface of the officially released input system is broken to the point of making the whole damn feature unusable. So this pre-release makes it one less barrage I have go through to learn unity overall.
Now it’d be very perfect if you could get rid of the “string” thing, but that’s nothing a script with some set variables can’t fix.
I’m having a lot of difficulties to learn unity, including the Input System thing, with the “unity learn” part being either out-of-date or just not what I want to learn about or how I best learn things, when not absent entirely, videos are in English, which is not my main writing is fine, but oral is hard to understand especially for fast-speakers. The input system is one such thing where the resources available never quite got me there, and the fact I had to download a whole “unity” beware of the version (not the major but even the minor most) was/sometimes still is troubling as hell.
By the way, if you intend to make it the standard input system, does that mean that in the future the input system will be the standardly installed one, and the old input manager will be a “compatibility package” ?
Overall, this update fix the broken interface, adds a lot of clarity to the input system, comes with most 3rd person controls already in. While I wish it was part of a 3rd person project template for 2022. I’m, I admit, very satisfied. The whole controller part was one of the reasons I hesitated between unity and unreal. C# had me stay, but with this, I’m just glad I stuck to it for long enough to learn about this preview package and can only hope it’s going to be pushed into the released state as soon as possible.
Because reinventing the wheel is more fun than using someone else’s solution, and it also avoids any issues that may arise from using an existing solution with bugs or limitations. I believe that this is one of the reasons why several Unity systems have subpar quality, as they are not utilized internally and people work around them instead of fixing/improving them.
A default input actions asset that always exists and is always enabled is a pretty interesting approach. I think having more than one InputActionAsset in a project is going to be very rare (I still don’t really know what you’d use that for), so this will probably be the correct approach in most cases.
I never really liked that approach. It’s a super-clunky thing that SRPs introduced where project-wide settings lives in the Assets folder instead of in the Edit/Project Settings menu. They probably did that because there was no way to add stuff to the Project Settings menu depending on if a package was installed or not without changing the core of the editor. Now that Settings Providers exists, that approach should probably be deprecated, as packages can put settings into the settings menu.
Mind you it still lives in the assets folder (or settings folder, depends) you just lose the ability to replace all related settings with one swell swoop from the editor UI (dropping another setting asset onto the field). And you need to live through another bugfest until Unity fixes all the issues with this settings drawing train wreck.
We just released a 2nd preview release of the Input System (1.8.0-pre.2) which contains a new feature called project-wide Actions. We would love to get your feedback after trying it out. Since this is a pre-release feature your feedback will go a long way in shaping it and improving it for everyone else. Please use this form for your comments https://forms.gle/67brxDs5xWtzGGmz9
We added default project wide actions to help with prototyping and streamline the main workflow of the Input System. These default actions are available from the Input System Package settings tab in the Project Settings which you can access from Edit.
For all the changes in the release please see the release notes.
Installation
You can go to Window → Package Manager → + → Add Package and add it to a project there if the Input System isn’t already present in your project.
The next 2023.3 alpha version will use that version automatically once you add Input System.
For everyone else you can manually edit your /Packages/manifest.json file and add “com.unity.inputsystem”: “1.8.0-pre.2” to the dependencies.
The minimum Unity version needed is 2022.3.0.
KNOWN ISSUES
The undo/redo system doesn’t work well yet with InputActionReferences and their assignments.
There are still various UX issues with the new UI Toolkit Action Editor which we are working through. Such as:
Search UI is not yet supported
Multi-select is not yet supported
Shortcuts for cut/paste, copy are not yet implemented
The API docs are not available yet on the documentation website
I can’t for the life of me find the 1.8.0 version, even with preview packages enabled. Even changing the manifest returns a package not found warning. I’m using 2022.3.13f1.
EDIT: Was able to use the package, but only in 2023.2.1f1.
EDIT.2: Playmode Options don’t seem to work with Domain unchecked.
The Dirty Asset * shows up after changing some inputs even when Auto-Save is enabled.
You can’t drag a Binding from one InputAction to another. It jumps back as soon as you click anywhere else.
The layout is all sorts of screwed once you use any other sizings than the default one, and even that one is iffy at best.
You get the error “type is not supported string value” once you remove a binding of an InputAction, but only if you deleted it using the Delete key, if you use the UI right-click, that’s not an issue.
The + Icon when adding a binding no longer shows a dropdown, so now you’ll have to right click all the time.
Also, could we get lines or color differences between the elements in the Actions tab? It’s not super readable right now.
Hey @Schubkraft
The project wide Input Actions are an interesting approach, I wonder though: what was/is the reasoning for this?
Is this a feature that was requested?
Nobody came to us and said “We need project wide input actions!” but a lot of people said “Why do I need to do this much stuff? I just want a quick Input.GetKey call!” and this is a solution we think will help with that. Quicker startup when using the Input System and you only need to touch it if you need to change from the default.
I can’t imagine this solution being in any way easier than just saying:
if (Keyboard.current[Key.A].wasPressedThisFrame)
{
// do stuff
}
I haven’t checked the official tutorials in a long time but looking for the first tutorial on the input system shows it taking the most verbose route so there’s the problem. It’s not that it can’t be done easily but that no one knows how to make a tutorial that gets straight to the point using the easiest approach.
The documentation isn’t much better. For a quick start guide it’s not a very quick start even with the new defaults which incidentally could have just been dumped into a folder in the project similar to how a new project includes a “sample” scene.
The direct workflow section is a close second but it loses to my example as it doesn’t show that you can pass an enum or a string which has lead people to believe (I know because I’ve responded to the posts) that it’s at best a hacky solution that can’t scale beyond that.
Said section even tries to incorrectly pass it off in the manner:
You can in fact change your input bindings if you choose to use enums and strings. You just have to take the same approach many of us took for years with the old input system (though it’s now easier as you no longer have to set up every axis and button possible in an archaic input manager).
Fun final fact: it took me months to become comfortable with the new input system and it’s almost entirely the fault of the documentation, the tutorials, and the sample code. Ultimately I had to piece together what I knew from third parties and experimentation which should not have been necessary.
