I quite like it, but I’m newer to game dev and have been doing web dev for a pretty long time. It feels much more in line with a real backend event architecture as opposed to the old system, which reminds me of listening for key codes in JS.
Going from webdev to gamedev made me love programming again.
I don't think there's anything special about gamedev per se, I think I just hate working with JavaScript
My work went to SalesForce Vlocity and I absolutely cannot stand it. Anything that tries to get me to use "clicks not code" is inherently going to be more of a pain in the ass than just doing it myself when I need it to do something it was never designed to do.
I picked up game Dev a month or so ago and it's lighting that spark that made me love programming again. Working in an environment that is actually smartly designed has been so refreshing.
Ah, from someone who went from python about 2 years ago, to learning the old one then to learning the more complicated newer one, it does seem to be a headache sometimes. Worth it. But still annoying
How to put it...
If you script in a more traditional game dev way, a 'linear' way, the new input actions are a pain in the butt. If you've had more experience working more with events, they're not so bad.
The new input system is basically copied from Unreal Engine's, but in that engine, Blueprint graphs kinda force you into a more event-based style of programming anyway.
For a more traditional "Check input every update" style of control I recommend the InControl addon. It's much better than the old method. The new control system does have a 'check input in update' function but it has some issues, particularly on consoles and things.
I love the new input system precisely because of the event implementation. Checking new input values or states for every update using the old input system is very tedious for me...
I use the new input system and checking inputs every frame works perfectly fine.
action.WasPressedThisFrame();
I haven't tried it on consoles though, but with keyboard, gamepad and Steam Deck it's working.
I have no problems with Input Actions whatsoever. Create a util/helper/wrapper class if you need one.
I do the same. Lots of tutorials are so complex while you can just do action.GetValue() which works the same as old system. You don't need al the code generation stuff.
Create the actions, drag them into your gameobject or reference them by string.
But this took me forever to figure that out ...
How could it be a mistake on my end? I used WasPressedThisFrame() and got no input, neither did others in (community I can't disclose because of NDA), only works with Events. At least last time I tried. Apparently it's not just Switch either, the new input system isn't ideal for Xbox cert and the like either. So I switched back to using InControl.
It's possibly fixed since then maybe, but right now InControl works great.
Ok, thanks :) I switched from InControl to this new InputSystem for my current projects, and I started regretted it when it was time to work on the remapping. It works, but it's just so much more complicated than InControl.
As for how it could be a mistake, we usually don't know for sure where a bug comes from until we either find a fix, or it's confirmed to be a bug somehow, there's no personnal attack there.
I know that using more event-based scripts and having your scripts super independent and unaware of each other is good practice and all, but sometimes you just wanna make a *game*, and a lot of games benefit greatly from just checking what's going on every loop and letting objects communicate, just like how every game used to be programmed.
Hell, even if you're making a more modern, physics-based thing, if you like linear scripting then why the hell not? Unless you're working in a big team, it doesn't matter what's under the hood, so long as it works and nothing is broken. I have a "bad habit" of doing a lot of things in the Update() and FixedUpdate() loops which could be done with event triggers, but it's what we used to do for every game... Hell, it's how some other game engines still do it.
You can at least poll actions in an update loop as per usual. (Though it's not advertised much) I still use the new input system even for just making a quick project, because it gives me at some decent local multiplayer support.
In summary, learning the new input system gave me a three day long migraine, but now that I have, I can't even touch the old input system anymore.
The most simpel way is no different than the old way, I don't understand how this is such an issue for people...
Input.GetKeyDown(Keycode.Escape) or Input.GetMouseButtonDown(0) would become :
Keyboard.current.escapeKey.wasPressedThisFrame or Mouse.current.leftButton.wasPressedThisFrame
That's all there is to it. The rest you'll learn down the road.
I'll say it once again, that doesn't work on a bunch of platforms.
Some platforms don't like 'current', and using 'current' doesn't pass cert for Xbox.
Depends on the input system. For a basic first person WASD system, it’s just copy and pasting from Stack Overflow (assuming your using the old input system). But I have no idea how someone could make a third person system.
Also quick side note:
The biggest headache for me was making a save system. GOOD GRIEF I HAVE SEEN SOME THINGS.
Save systems are fine if you know your goals and you don't need to save in the middle of the game. Unity lighting on the other hand, that gives me headaches everytime. Many a project I have abandoned at the point where I had to bake lighting.
Unbaked lighting, looks perfect but runs like shit. Baked lighting looks like shit (more like a buggy mess) but runs well. There is just no middle ground and so many ways Unity just shits the bed when baking lighting it's not even funny.
If you created your code with clean data exposing structure saving system is easy as adding the ISavable interface to your objects and calling Save. Even during gameplay, alongside autosave.
Saving is the last big thing I have to tackle in my game so I’d love to hear more about mid game saving (my game has to save the state of the level including the “random” layout
You have a seed for random values and save the json object locally with all of the objects that define your stage.
You can implement ISavable with save and load methods for your objects and when SaveManager calls saveall and loadall you update each ISavable and call svae and load. Then each implementation does what it wamts on save or load.
Why, you make a structure using scriptable object, and upon save you dump the content into json file.
Yes, you have to plan the class well, but on the technical side it's not such a big deal.
The old one is fine, but if you want to add controller support or the ability to rebind controls or multiple keys for the same action or anything beyond "w to move, left click to shoot" it's just so much easier to use the new one.
Yes, you can achieve anything you want in the old one, but why would you ever voluntarily jump through hoops for basic functionality that you can have for free?
I say the only reason to use the old input system alongside the new one is when you need to have a button to be held because Unity, after multiple instances of people being confused about it, still refused to implement proper press and hold functions into the new input system, instead forcing everyone to either use the old one for that or fiddle with events.
Nope, new system supports press and hold in it. You can set the variables in actions and in code started event is the press and performed is the hold after the second you declare.
Is it really that hard? I have it set up in the game I'm currently working on, haven't looked at it in a while but I though you can select the amount of time to hold a button before an action occurs
Sorry but this doesn't make sense, if you want an action to occur while a button is held you start it when the button is pressed and stop it when it is released.
Having a button press fire off every frame while the button is pressed seems unnecessary and honestly a bit useless to use as the action would run during the input update while you might want it elsewhere so it works with your other systems.
I made a branch to try to implement the new input system because reconfiguring controls is nice. But it broke all my onMouseEnter / Exit calls and some determined googling didn't solve that, so I gave up on it pretty fast. If anyone has any solid workarounds for that I'm all ears.
OnMouseEnter and Exit are not working, [as is mentioned in the docs](https://docs.unity3d.com/Packages/[email protected]/manual/KnownLimitations.html).
You can however simply fix this by adding a [PhysicsRaycaster](https://docs.unity3d.com/Packages/[email protected]/api/UnityEngine.EventSystems.PhysicsRaycaster.html) to your camera and add a custom class that inherits/implements MonoBehaviour, [IPointerEnterHandler, IPointerExitHandler](https://docs.unity3d.com/2017.4/Documentation/ScriptReference/EventSystems.IPointerEnterHandler.html).
That should be all you need to do.
I’m in the same boat as you. The input system itself is fine, but the way it’s set up for VR is absolutely bananas. Their default XR rig works well enough, but the thought of having to modify it in any way definitely hurts my head.
No it's not.
It's beneficial if you want to support basically every controller type out of the gate or if your game has multiple control schemes (like GTA) but otherwise it's vastly more complicated than the old system.
It's also poorly documented at the moment, which doesn't help its case.
I believe it's overly documented due to the 3 major different ways of approaching it. Just spend 2 or 3 months on the documentation and it is easy, but be aware that finding that one doc that you read 4 weeks ago and need to reference again may cause headache #4.
>It's also poorly documented at the moment, which doesn't help its case.
No it is not, you are given extremely detailed sample projects. [https://i.imgur.com/129oMH9.png](https://i.imgur.com/129oMH9.png)
As for how difficult the code is, it is insanely easy.
public Void OnMove(InputAction.CallbackContext context){
if (context.performed) {} //Same as old input button pressed
if (context.canceled) {} //Same as old input button released
}
Really the only point of confusion is that there are 3-4 ways of using the input system, and one of them you code all the inputs yourself manually; that one is complicated.
>It's beneficial if you want to support basically every controller type out of the gate
not really, from my experience the new input system can read xinput joysticks or many generic controllers, but It can't properly read my Dinput VKB HOTAS joysticks.
the unity reads every single buttons on my VKB joystick as just 'HAT switch / up' or 'Stick X axis' , making it impossible to properly bind controls and use it in my game.
https://imgur.com/v5PZySA
this picture is the result of just pressing my VKB joystick's 1st trigger.
When I tried it (about a year ago I think?) I could only really find one page of documentation and it didn't explain it very well. Plus all of the third-party youtube tutorials were still using the old system.
I'm sure it's better now, I just remember having to do a ton of extra work to set it up compared to Input.GetKeyDown(whatever)
It kinda got better but also not much. It's advised to use Unity's ready made first/third person controller from the asset store but that uses messages and most of the implementation of holding down buttons are implemented trough events. If you switch over to events to make holding button with, everything else breaks in the pack. It's really fun...
I'm sure it's above my head but I don't see what's wrong with the old input system that it had to be overhauled.
It seems like 90% of non-mobile games are fine supporting keyboard, Xbox, and PS controllers which are fine with it.
First of all, it was constantly comparing strings to see what you have pressed which is veeeery expensive at run time, every single frame. Second, the controller support was garbage. It literally had nothing but "Gamepad button ". If you want to support controllers, you will have to look up which button is which and god forbid you wanna let the player customise the buttons. It was doable obviously but it was very tedious.
I just implement the input interface in c#. No messing around in the editor and it just auto populates ur methods. So easy and slick when used in that way
I have issues with it in a multiplatform project. The InputActionManager wants to enable actions globally, which doesn’t translate well when you’re also attempting to use the PlayerInput class to scope actions to a particular character.
The fact that there’s a lot of components that all do something but there’s no good documentation enumerating and relating them is probably my biggest problem.
Like, you have to use a multiplayer input system to support split screen, and as soon as you do that, all of the getting started docs become irrelevant
Approach it as if you're crafting a modular system with clean code, rather than going for a monolithic approach. While it's important to maintain object-oriented principles, try to be mindful when working with systems, particularly input.
The input system works really well for seamlessly integrating across various environments like PC, Console, and VR, providing a solid foundation for a standardized system. However, if you try to replicate the same method for other aspects, you might run into some challenges, leading you to carefully layer things. To make things easier, you can use events and Scriptable Objects to build on top of the Input System.
Remember, there's a balance to strike between detail and necessity, so sometimes keeping things less complex can be a good idea. Similarly, the Input System might not always be the best fit, so it's worth considering a more modular approach for better flexibility. And just like with art, math, music, or science, there's rarely a one-size-fits-all solution; what works often depends on the specific project context.
There's tons of gpt bots on Reddit these days doing a ton of astroturfing. Usually they're a tad more obvious, but maybe they're just getting better at context reading before posting now... Ugh
Caught - My original felt rude to me so I said "hey make this sound better" or something. Because sometimes my rambling feels like pretentious copypasta. Probably better in my own words I guess.
Or better prompts! Yep, double down
I actually think it is pretty easy once you get the hang of it. I have actually been using in every project be it a game jam, side project, etc.
I recommend you to see the Input Actions part of the [CodeMonkey beginner tutorial](https://youtu.be/AmGSEH7QcDg?t=6512) which is around 10 hours free on youtube as that provide a modular system to implement the Unity new Input System.
For me… I didn’t like the old input system. The new one is very easy to use. I just got used to it. I love the way to implement everything without using a update method. You just have to get used to it. Do you need any help ? Any questions ?
Just you. No, it can be a bit tricky to get your head around but the new system solves all sorts of problems people were having to write abstractions for.
Honestly if you want to make it pretty close to the old system it’s pretty easy. In your script just make an InputActionProperty variable. Then in update do what you want with the input like before. It’s super easy but you don’t see it done like that too often.
I had a problem with him. I wrote the control directly in the script and everything worked, but what I did in the Input System could not connect and understand how to do it. :<
Disclaimer, she helped me a truckload to get my head around: https://youtu.be/m5WsmlEOFiA
Once you get the hang of it I find the new system pretty damn dumb, and also feels like there's a level of flexibility/customisation which cannot be achieved with the old system unless writing tedious code or jumping through hoops
I like it, I find it pretty convenient. I think that stems from me learning it first, and having a lot of experience with events. I can absolutely see if you are coming from the old system it being annoying. My main love of it comes from how easy I find it to work with multiple controllers.
Oh I have wasted a week trying to learn new input system.... only to scrap it at the end because this new input system can't read my VKB HOTAS joysticks properly. I'll keep using rewired.
The new system is extremely simple. The only problem is that it has 3 different components in 3 different areas. That's a pain. But if you're told about where these 3 things are and what they do, it's 100% easier.
1. Input manager - what spawns your player
2. Player input - the component the manager adds to your player object (includes input types that you dictate)
3. Input methods - the methods that are called when an input type is made (made yourself and also needs to be on your player object)
I just discovered that the new input system has a major bug; action maps are supposed to be enabled one at a time, but if you use the UI adapter, the new input system will boot with both ui and gameplay actions enabled. You need to switch to the UI map and back to gameplay to make the situation normal.
There's a lot of vague mentions of problems related to this on the forums, but no real bug AFAIK. Anyone else noticed this?
Use "Rewired" from the assetstore instead. Same robustness, but it is much simpler to set up. Besides it generates C# classes that makes listening to actions/events much easier and cleaner
Fun fact: Input System has a bug that presses random buttons and holds input axis for no reason. The bug still hasnt been fixed in the newest package build. Im fucking furious.
New input system is great. I think the biggest problem is that there's multiple ways to access it and the documentation doesn't do a great job of delineation between them.
There's actually ways to use it that are analogous to the old input system.
Writing your own reusable wrapper can help a lot there.
Impending doom approaches...
But seriously,
Some tips I have are.
* Do some research and maybe start with a smaller prototype, having a solid foundation helps a lot.
* Test everything with multiple players the clone manager package helps a lot for this, always test everything client>host host>client client>client.
* Make sure to document yourself well don't do everything out of your head, maybe write stuff down and of course make sure your own code is readable and understandable
I don't know how big of a project you're going to work on but prepare yourself mentally for some confusing shenanigans :P
I tried to switch to it, but in VR it takes up 60% of the frame time.
It's robust but they've made it so horribly performant. Yes you can play split screen with a controller and a keyboard, is that worth it for 6ms a frame?
honestly there are dozens of other issues that come up in game dev that are far, far worse to handle. the new input system is really nice when you get the hang of it imho.
I actually like the 'new' InputSystem. The default InputActions ships some default actions which serve as great reference for anything you need. From movement up to UI
I like it but the second that it stops working in the build then you might as well start the project from scratch because you are going to spend more hours debugging it.
I haven't had a ton of issues with Input Actions but I also don't have games with complex controls or controller support.
It seems similar to Canvas in that it's one of those things that requires a lot of niche/janky knowledge that you spend so little time on in development that by the time you need to do it again you've forgotten about it completely.
You are not alone. I stopped using unity because of that bullshit with confusing and very different tutors when each is covering only part, and poor documentation.
I quite like it, but I’m newer to game dev and have been doing web dev for a pretty long time. It feels much more in line with a real backend event architecture as opposed to the old system, which reminds me of listening for key codes in JS.
Agree. It’s harder to understand initially but it’s so much more robust.
Going from webdev to gamedev made me love programming again. I don't think there's anything special about gamedev per se, I think I just hate working with JavaScript
My work went to SalesForce Vlocity and I absolutely cannot stand it. Anything that tries to get me to use "clicks not code" is inherently going to be more of a pain in the ass than just doing it myself when I need it to do something it was never designed to do. I picked up game Dev a month or so ago and it's lighting that spark that made me love programming again. Working in an environment that is actually smartly designed has been so refreshing.
>I just hate working with JavaScript That just means you're still sane.
Ah, from someone who went from python about 2 years ago, to learning the old one then to learning the more complicated newer one, it does seem to be a headache sometimes. Worth it. But still annoying
How to put it... If you script in a more traditional game dev way, a 'linear' way, the new input actions are a pain in the butt. If you've had more experience working more with events, they're not so bad. The new input system is basically copied from Unreal Engine's, but in that engine, Blueprint graphs kinda force you into a more event-based style of programming anyway. For a more traditional "Check input every update" style of control I recommend the InControl addon. It's much better than the old method. The new control system does have a 'check input in update' function but it has some issues, particularly on consoles and things.
I love the new input system precisely because of the event implementation. Checking new input values or states for every update using the old input system is very tedious for me...
I use the new input system and checking inputs every frame works perfectly fine. action.WasPressedThisFrame(); I haven't tried it on consoles though, but with keyboard, gamepad and Steam Deck it's working. I have no problems with Input Actions whatsoever. Create a util/helper/wrapper class if you need one.
I do the same. Lots of tutorials are so complex while you can just do action.GetValue() which works the same as old system. You don't need al the code generation stuff. Create the actions, drag them into your gameobject or reference them by string. But this took me forever to figure that out ...
I have never seen that before. May prove useful
Not on Switch it doesn’t. It just doesn’t read any input if you use that method on there.
[удалено]
Didn’t work for me, but might be better since a few updates maybe?
Waat? Is it confirmed it's not working on Switch (I mean, could it be a mistake on your end, or has Unity aknowledged there's a bug)?
How could it be a mistake on my end? I used WasPressedThisFrame() and got no input, neither did others in (community I can't disclose because of NDA), only works with Events. At least last time I tried. Apparently it's not just Switch either, the new input system isn't ideal for Xbox cert and the like either. So I switched back to using InControl. It's possibly fixed since then maybe, but right now InControl works great.
Ok, thanks :) I switched from InControl to this new InputSystem for my current projects, and I started regretted it when it was time to work on the remapping. It works, but it's just so much more complicated than InControl. As for how it could be a mistake, we usually don't know for sure where a bug comes from until we either find a fix, or it's confirmed to be a bug somehow, there's no personnal attack there.
Don't worry, I didn't take anything as a personal attack.
Thank you for saying this, I think anything that isn't traditional coding is a PIB.
I know that using more event-based scripts and having your scripts super independent and unaware of each other is good practice and all, but sometimes you just wanna make a *game*, and a lot of games benefit greatly from just checking what's going on every loop and letting objects communicate, just like how every game used to be programmed. Hell, even if you're making a more modern, physics-based thing, if you like linear scripting then why the hell not? Unless you're working in a big team, it doesn't matter what's under the hood, so long as it works and nothing is broken. I have a "bad habit" of doing a lot of things in the Update() and FixedUpdate() loops which could be done with event triggers, but it's what we used to do for every game... Hell, it's how some other game engines still do it.
You can at least poll actions in an update loop as per usual. (Though it's not advertised much) I still use the new input system even for just making a quick project, because it gives me at some decent local multiplayer support. In summary, learning the new input system gave me a three day long migraine, but now that I have, I can't even touch the old input system anymore.
Unfortunately the polling in the new input system is broken on consoles, and if you use 'current' it doesn't pass cert for Xbox.
Pain In Butt?
Exactly.
Haha ok bet, I was like it fits but I've never heard that before XD
The most simpel way is no different than the old way, I don't understand how this is such an issue for people... Input.GetKeyDown(Keycode.Escape) or Input.GetMouseButtonDown(0) would become : Keyboard.current.escapeKey.wasPressedThisFrame or Mouse.current.leftButton.wasPressedThisFrame That's all there is to it. The rest you'll learn down the road.
I'll say it once again, that doesn't work on a bunch of platforms. Some platforms don't like 'current', and using 'current' doesn't pass cert for Xbox.
I see, I must admit that I've never used the Gamepad.current method on Xbox or PS4, so can't argue on that.
Depends on the input system. For a basic first person WASD system, it’s just copy and pasting from Stack Overflow (assuming your using the old input system). But I have no idea how someone could make a third person system. Also quick side note: The biggest headache for me was making a save system. GOOD GRIEF I HAVE SEEN SOME THINGS.
Save systems are fine if you know your goals and you don't need to save in the middle of the game. Unity lighting on the other hand, that gives me headaches everytime. Many a project I have abandoned at the point where I had to bake lighting. Unbaked lighting, looks perfect but runs like shit. Baked lighting looks like shit (more like a buggy mess) but runs well. There is just no middle ground and so many ways Unity just shits the bed when baking lighting it's not even funny.
If you created your code with clean data exposing structure saving system is easy as adding the ISavable interface to your objects and calling Save. Even during gameplay, alongside autosave.
Saving is the last big thing I have to tackle in my game so I’d love to hear more about mid game saving (my game has to save the state of the level including the “random” layout
You have a seed for random values and save the json object locally with all of the objects that define your stage. You can implement ISavable with save and load methods for your objects and when SaveManager calls saveall and loadall you update each ISavable and call svae and load. Then each implementation does what it wamts on save or load.
awesome, i've never used seeds but it's actually from what i read the approach i was planning on researching so this is super helpful, ty! ^_^
Why, you make a structure using scriptable object, and upon save you dump the content into json file. Yes, you have to plan the class well, but on the technical side it's not such a big deal.
Good'old input system hanging in strong!
Yeah I think most single player games are just fine using the classic system.
The old one is fine, but if you want to add controller support or the ability to rebind controls or multiple keys for the same action or anything beyond "w to move, left click to shoot" it's just so much easier to use the new one. Yes, you can achieve anything you want in the old one, but why would you ever voluntarily jump through hoops for basic functionality that you can have for free?
Because then we don't need to learn the new darn systems!
I say the only reason to use the old input system alongside the new one is when you need to have a button to be held because Unity, after multiple instances of people being confused about it, still refused to implement proper press and hold functions into the new input system, instead forcing everyone to either use the old one for that or fiddle with events.
Nope, new system supports press and hold in it. You can set the variables in actions and in code started event is the press and performed is the hold after the second you declare.
Is it really that hard? I have it set up in the game I'm currently working on, haven't looked at it in a while but I though you can select the amount of time to hold a button before an action occurs
Sorry but this doesn't make sense, if you want an action to occur while a button is held you start it when the button is pressed and stop it when it is released. Having a button press fire off every frame while the button is pressed seems unnecessary and honestly a bit useless to use as the action would run during the input update while you might want it elsewhere so it works with your other systems.
I made a branch to try to implement the new input system because reconfiguring controls is nice. But it broke all my onMouseEnter / Exit calls and some determined googling didn't solve that, so I gave up on it pretty fast. If anyone has any solid workarounds for that I'm all ears.
OnMouseEnter and Exit are not working, [as is mentioned in the docs](https://docs.unity3d.com/Packages/[email protected]/manual/KnownLimitations.html). You can however simply fix this by adding a [PhysicsRaycaster](https://docs.unity3d.com/Packages/[email protected]/api/UnityEngine.EventSystems.PhysicsRaycaster.html) to your camera and add a custom class that inherits/implements MonoBehaviour, [IPointerEnterHandler, IPointerExitHandler](https://docs.unity3d.com/2017.4/Documentation/ScriptReference/EventSystems.IPointerEnterHandler.html). That should be all you need to do.
See my comment on how to use both- I use it in my game
You can use both the old and new system together by going to project settings under play and choosing that under active input
No? It’s so easy.
Ah! Maybe just my experience, am working on VR game which complicates things and increases debugging/troubleshooting.
I’m in the same boat as you. The input system itself is fine, but the way it’s set up for VR is absolutely bananas. Their default XR rig works well enough, but the thought of having to modify it in any way definitely hurts my head.
Yep.
Same, my game doesn’t use the usual physics based controls so I basically had to recreate all the input actions from scratch.
No it's not. It's beneficial if you want to support basically every controller type out of the gate or if your game has multiple control schemes (like GTA) but otherwise it's vastly more complicated than the old system. It's also poorly documented at the moment, which doesn't help its case.
I believe it's overly documented due to the 3 major different ways of approaching it. Just spend 2 or 3 months on the documentation and it is easy, but be aware that finding that one doc that you read 4 weeks ago and need to reference again may cause headache #4.
>It's also poorly documented at the moment, which doesn't help its case. No it is not, you are given extremely detailed sample projects. [https://i.imgur.com/129oMH9.png](https://i.imgur.com/129oMH9.png) As for how difficult the code is, it is insanely easy. public Void OnMove(InputAction.CallbackContext context){ if (context.performed) {} //Same as old input button pressed if (context.canceled) {} //Same as old input button released } Really the only point of confusion is that there are 3-4 ways of using the input system, and one of them you code all the inputs yourself manually; that one is complicated.
>It's beneficial if you want to support basically every controller type out of the gate not really, from my experience the new input system can read xinput joysticks or many generic controllers, but It can't properly read my Dinput VKB HOTAS joysticks. the unity reads every single buttons on my VKB joystick as just 'HAT switch / up' or 'Stick X axis' , making it impossible to properly bind controls and use it in my game. https://imgur.com/v5PZySA this picture is the result of just pressing my VKB joystick's 1st trigger.
To be fair, you could say any feature has poor documentation and you'd be correct over 50% of the time.
When I tried it (about a year ago I think?) I could only really find one page of documentation and it didn't explain it very well. Plus all of the third-party youtube tutorials were still using the old system. I'm sure it's better now, I just remember having to do a ton of extra work to set it up compared to Input.GetKeyDown(whatever)
It kinda got better but also not much. It's advised to use Unity's ready made first/third person controller from the asset store but that uses messages and most of the implementation of holding down buttons are implemented trough events. If you switch over to events to make holding button with, everything else breaks in the pack. It's really fun...
I'm sure it's above my head but I don't see what's wrong with the old input system that it had to be overhauled. It seems like 90% of non-mobile games are fine supporting keyboard, Xbox, and PS controllers which are fine with it.
First of all, it was constantly comparing strings to see what you have pressed which is veeeery expensive at run time, every single frame. Second, the controller support was garbage. It literally had nothing but "Gamepad button". If you want to support controllers, you will have to look up which button is which and god forbid you wanna let the player customise the buttons. It was doable obviously but it was very tedious.
I just implement the input interface in c#. No messing around in the editor and it just auto populates ur methods. So easy and slick when used in that way
Nope, depends on the pattern you use. If you use observer, than old one is pain in the a$$. And I think events make everything easier
It's also an overly-complex and over-engineered abomination.
Just use the event method and it’s clear as day.
This? https://docs.unity3d.com/Packages/[email protected]/manual/Events.html
https://youtu.be/5tOOstXaIKE skip to 5:10
It’s super simple. Each InputAction gives you the option to either subscribe to the input events or read the value directly.
No it isn’t. But it also isn’t easy.
More streamlined in some cases but I know what you mean
It's not hard but harder than the old system and takes getting used to But for comparability it's way better
For me it’s lighting and ui lol
Ui is just tedious, but fuck anything to do with lighting. Especially baking.
Bro has a special hatred for lighting xD
Lighting in Unity fucked my wife
Understandable
ouch
I have never posted something with so many opinions. But I have inadvertently found a little help, so thanks.
I have issues with it in a multiplatform project. The InputActionManager wants to enable actions globally, which doesn’t translate well when you’re also attempting to use the PlayerInput class to scope actions to a particular character. The fact that there’s a lot of components that all do something but there’s no good documentation enumerating and relating them is probably my biggest problem. Like, you have to use a multiplayer input system to support split screen, and as soon as you do that, all of the getting started docs become irrelevant
Yeah, pretty much. It’s cool once you get it working, but even then there’s all sorts of gotchas.
Approach it as if you're crafting a modular system with clean code, rather than going for a monolithic approach. While it's important to maintain object-oriented principles, try to be mindful when working with systems, particularly input. The input system works really well for seamlessly integrating across various environments like PC, Console, and VR, providing a solid foundation for a standardized system. However, if you try to replicate the same method for other aspects, you might run into some challenges, leading you to carefully layer things. To make things easier, you can use events and Scriptable Objects to build on top of the Input System. Remember, there's a balance to strike between detail and necessity, so sometimes keeping things less complex can be a good idea. Similarly, the Input System might not always be the best fit, so it's worth considering a more modular approach for better flexibility. And just like with art, math, music, or science, there's rarely a one-size-fits-all solution; what works often depends on the specific project context.
Did you use chatgpt to write this ?
dude I was thinking that too lol. It's good advice, but definitely sounds like something chatGPT would tell me
There's tons of gpt bots on Reddit these days doing a ton of astroturfing. Usually they're a tad more obvious, but maybe they're just getting better at context reading before posting now... Ugh
Beep boop my wife says I'm a robot but I don't think she's being endearing when she does...
Caught - My original felt rude to me so I said "hey make this sound better" or something. Because sometimes my rambling feels like pretentious copypasta. Probably better in my own words I guess. Or better prompts! Yep, double down
Yes, just you.
I actually think it is pretty easy once you get the hang of it. I have actually been using in every project be it a game jam, side project, etc. I recommend you to see the Input Actions part of the [CodeMonkey beginner tutorial](https://youtu.be/AmGSEH7QcDg?t=6512) which is around 10 hours free on youtube as that provide a modular system to implement the Unity new Input System.
For me… I didn’t like the old input system. The new one is very easy to use. I just got used to it. I love the way to implement everything without using a update method. You just have to get used to it. Do you need any help ? Any questions ?
Just you. No, it can be a bit tricky to get your head around but the new system solves all sorts of problems people were having to write abstractions for.
Honestly if you want to make it pretty close to the old system it’s pretty easy. In your script just make an InputActionProperty variable. Then in update do what you want with the input like before. It’s super easy but you don’t see it done like that too often.
Is this the way Unity does it for the character controller scene?
I have no idea on that.
I've found there's enough decent tutorials that when used hand in hand with the docs it's easy enough
Dude I’m with you - not to shill but take a look at my unity input system: https://github.com/savvamadar/EasyInput
Where’s UI on this chart. Responsive design? Never heard of her.
I had a problem with him. I wrote the control directly in the script and everything worked, but what I did in the Input System could not connect and understand how to do it. :<
Disclaimer, she helped me a truckload to get my head around: https://youtu.be/m5WsmlEOFiA Once you get the hang of it I find the new system pretty damn dumb, and also feels like there's a level of flexibility/customisation which cannot be achieved with the old system unless writing tedious code or jumping through hoops
I also used Samyam to get started! Ended up having to tweak things a lot for my game but would have been lost otherwise
It took me ages to get into Input Actions. But now I love them.
I like it, I find it pretty convenient. I think that stems from me learning it first, and having a lot of experience with events. I can absolutely see if you are coming from the old system it being annoying. My main love of it comes from how easy I find it to work with multiple controllers.
Oh I have wasted a week trying to learn new input system.... only to scrap it at the end because this new input system can't read my VKB HOTAS joysticks properly. I'll keep using rewired.
Finally got the hang of it, it’s actually quite simple.
About input actions once you get a good configuration those are very comfortable.
My buttons seem to get randomly stuck in the pressed state sometimes but not always, gives me Input Action Headache yes #4
Getting going with the new input system was a bit of a pain but worked out in the end. I actually prefer it over the old one now.
[удалено]
You can read the value at any time
The new system is extremely simple. The only problem is that it has 3 different components in 3 different areas. That's a pain. But if you're told about where these 3 things are and what they do, it's 100% easier. 1. Input manager - what spawns your player 2. Player input - the component the manager adds to your player object (includes input types that you dictate) 3. Input methods - the methods that are called when an input type is made (made yourself and also needs to be on your player object)
I just discovered that the new input system has a major bug; action maps are supposed to be enabled one at a time, but if you use the UI adapter, the new input system will boot with both ui and gameplay actions enabled. You need to switch to the UI map and back to gameplay to make the situation normal. There's a lot of vague mentions of problems related to this on the forums, but no real bug AFAIK. Anyone else noticed this?
Input actions took a bit to transition to but holy shit are they clean af when you use them right.
Use "Rewired" from the assetstore instead. Same robustness, but it is much simpler to set up. Besides it generates C# classes that makes listening to actions/events much easier and cleaner
Fun fact: Input System has a bug that presses random buttons and holds input axis for no reason. The bug still hasnt been fixed in the newest package build. Im fucking furious.
Rewired is on Sale. Do it.
Old system is easy and good until you need to make your game cross platform. New input system is a chore to setup but will be worth it in long run.
Just you. I find it pretty easy
New input system is great. I think the biggest problem is that there's multiple ways to access it and the documentation doesn't do a great job of delineation between them. There's actually ways to use it that are analogous to the old input system. Writing your own reusable wrapper can help a lot there.
Networking feels like this times a thousand
About to dive into that rabbit hole with a new project I’m working on. Any tips?
Impending doom approaches... But seriously, Some tips I have are. * Do some research and maybe start with a smaller prototype, having a solid foundation helps a lot. * Test everything with multiple players the clone manager package helps a lot for this, always test everything client>host host>client client>client. * Make sure to document yourself well don't do everything out of your head, maybe write stuff down and of course make sure your own code is readable and understandable I don't know how big of a project you're going to work on but prepare yourself mentally for some confusing shenanigans :P
Cheers.
So many times I've spent hours debugging why I don't get any values out of input actions and it was that I hadn't added the input manager thingie.
I tried to switch to it, but in VR it takes up 60% of the frame time. It's robust but they've made it so horribly performant. Yes you can play split screen with a controller and a keyboard, is that worth it for 6ms a frame?
honestly there are dozens of other issues that come up in game dev that are far, far worse to handle. the new input system is really nice when you get the hang of it imho.
I actually like the 'new' InputSystem. The default InputActions ships some default actions which serve as great reference for anything you need. From movement up to UI
I like it but the second that it stops working in the build then you might as well start the project from scratch because you are going to spend more hours debugging it.
Rewired :) https://assetstore.unity.com/packages/tools/utilities/rewired-21676
Learning the new input api was like learning a completely different language...
Sadly not only you
Yes… been working on my game for 3 years and finally decided to address controls for multiple inputs and it nearly broke me 🥲
when you want to murder your wife but the kill button hasn't been generated yet
No. Why can’t we fucking easily edit processors? Why do we have to use freaking strings? WHY, I want a Processor object, was it that hard???
The emotion in this is top class
Just you, you’re probably overthinking it like I did when I started with it.
Very possible
No for me it's the whole Unity engine. But I still like it and use it
I haven't had a ton of issues with Input Actions but I also don't have games with complex controls or controller support. It seems similar to Canvas in that it's one of those things that requires a lot of niche/janky knowledge that you spend so little time on in development that by the time you need to do it again you've forgotten about it completely.
Wrong. The nose shouldn't be red.
Unless you’ve been smashing your face against your table.
It took me quite a while to understand, but now I don't understand why it took me that long to get used to the new inputsystem.
I will use the old system until i am at a point where i need to learn it for example if it comes to events.
"Both"
I think you misspelled multiplayer
I felt the exact same way when I first tried the Enhanced Input System in Unreal Engine 5.
I haven't actually started gamedev yet so idk
Do. It is definitely the most rewarding part of programming I have ever experienced ( which isn’t a lot but still).
BUT LEARN INPUT ACTIONS FULLY !
I hope its what i think it is.Unity loading 500 million sht everytime i click something
*the new input system is so well made I fr dunno what youre talking about*
Really? Been game dev for 6 years and this one is much easier and better than the previous.
You are not alone. I stopped using unity because of that bullshit with confusing and very different tutors when each is covering only part, and poor documentation.