Видео

The last workflow is really similar to what I’ve been doing except I haven’t been leveraging the generated class, which looks like it handles a good deal of boilerplate for getting all the actions needed (I was manually getting all of them from serialized fields on my ScriptableObject). I’ll definitely try it this way next time. Thanks!

A great video as usual. Thank you!!

Ever since the new Input system was released I've been using the third option, which is very useful. Though I did switch from having events with just the value to having events that also send the state, performed cancel etc, as I find it to be more flexible on the consumer side. As I had more complex inputs, having just the value became kind of a hassle. And having the ability so witch between action maps depending on the context.

Do you think this package is a good solution for building a GOAP AI system? Or is it suited more for behavior trees?

This video was very well-timed for my use, great quality content as always. Keep it up!

My biggest gripes about the new input system: 1. You basically HAVE to use the scriptable object workflow you described, otherwise you'll have to instantiate your action schema in each object you want to subscribe to events and call .Enable() .Disable() etc, not only it's a lot of cruft, but action schemas contain a ton of json which needs to be parsed on instantiation which is quite slow and allocation heavy. 2. I haven't found any way to prevent keyboard actions going through when typing into text fields, i.e. TMP_InputField. Fixing this required developing my own very hacky looking fix. 3. It's apparently trivial to set up bindings in such a way the editor allows them but it then errors out with internal exception in the input system (I.e. NPE) when performing an action. That's bananas. Great video, thanks!

I havent used all th UI portions of the input system as it was bad enough getting keys in the setup stage because it would do weird things.. I also tend to use rewired now

Wow! The video I asked for in the comments, thank you!

Nice overview! It does however miss the, in my opinion, best way to use the Unity Input System: By adding InputActionReference fields to your InputReader SO or component, you get an inspector field where you can assign actions. These assigned actions are serialized and robust and it is not necessary to use the compiled C# class from the action table, which I personally hate, since it triggers a recompile every tile you make a change to the actions - especially in early stages when you're still tweaking a lot this can be really annoying. The obvious advantage is of course that you can swap out actions from the editor easily or create different scriptable objects with alternate mappings, without having to write new classes.

Is Rider free for game programmers using collaboratively with Unity?

Great tutorial, thank you. Are there any performance concerns for this approach? Say we use this across the whole game and reduce reference usage to a minimum, would that be efficient in a big project?

This one is great, I hadn't seen the "like the old input system" way of doing it before, still prefer your last version with the Scriptable object, but good to know the others

I’m having trouble following the link to the actions video. It seems to go nowhere! I’d love to see linked videos in the description

I didn't know there was a way to make things like this. It's really amazing. Personally, I wish your Unity tutorials could be published as a book. Something like "Unity for Advanced Users." I study a lot with official Unity projects, but teacher(your) projects are always a step above.

Thanks for the work you put in on these videos, some really helpful insights. I started using Unity just a short time before the Input system was released (or maybe just before I became aware of it?) anyway... I definitely am not a fan of change myself, so I understand the reservations people have about moving from one method of doing things to another, especially if you have a lot of experience with the current way of doing things. However I do find the new system to be pretty intuitive (after an initial learning curve) , I find it to be easier for me when it comes to supporting multiple input devices , just seems a little cleaner over all IMO.

I've been using the Scriptable Object approach ever since I saw Unity's Scriptable Object Architecture video. I'm a university student, and have only been using Unity since October, I really enjoy your videos (although sometimes they're a little complex for me)!

I love the new input system for its flexibility, but they really messed something up in Unity 6. For some reason inputs just stop working and require an editor restart every couple hours.

Great video! Definitely will check out those interfaces. I'm currently using your Event Bus to raise input events on a singleton InputManager. Using the interfaces to generate those methods will save some time wiring things up, thanks!

There is also another workflow that allows you to subscribe directly to the individual input action assets. It's like the Interface/SO approach, but on a per-action basis.

I planned to just watch this video for my own entertainment without expecting to learn anything new but I ended up learning about a c# feature I did not know of at 2:50.

Great video! It's nice to see different ways of working with this system. When using the PlayerInput component, is there downside to subscribing to each of the InputAction's events directly? For example, playerInput.actions["Attack"].started += Attack();

This is great! After watching several other tutorials, only one mentioned the C# class, but your video offers a lot more depth and gave me a much better understanding. Thanks for all the insights!

Very very nice. Input reader as SO is hot. - I'd like to add that the samples for the input package are super useful, i.e. there is button remapping already in there.

Great Video!

Very good overview. I like the way you abstracted the input allowing consumers to either subscribe to events that you forwarded on or properties. I actually got into a bit of a flame war following that very pattern in my Joust tutorial. Their primary hangup was that we basically have "a subscription within a subscription". i.e. you have a middle-man that's receiving the events from the input system forwarding those with events of its own. I actually made a follow-up video on abstracting user input explaining why that's a good thing.

Using a Scriptable Object for the Input Reader is genius! Never would've thought of that!

Which workflow do you tend to use and why do you prefer it over the other options?

Amazing video as always! Would love to see a follow-up video on displaying input actions using the UI Toolkit and reacting to input device changes to update the bounded input actions.

solid tutorial! I've been using the scriptable object approach for a while and it's great if you want separate maps for different Input States (like on foot, in a vehicle, etc or KBM vs Controller). really helps only sending input data to only the current object you're controlling. Also I just got Rider after watching your vids the past few months, I am absolutely loving it and it's a huge upgrade from VS 2022, especially with hlsl cus it actually formats properly instead of being a jumbled mess in VS

I also use a handler with SendMessage methods

Great one as always 🎉 Would u consider doing some XR stuff in the future?

You are by far my favorite channel on RUclips when it comes to coding. You and Sebastian Lague are the best <3 Been watching for a very long time, I love to see that your channel is growing!

Great Video! i want to ask where do you call the EnablePlayerActions? and i have a problem where i need to enable domain reload for it to receive input when you run it for the second time, do you have a solution for this? thank you!

I have 5 characters with separate inputs. This will come in handy and your previous video as I get some input calls after new scene load with newest 2022.3 LTS. Is say I should Dispose()...preety sure after creating new inputs I disable them in OnDisable. So yeah... have to search for a solution ;) Happy Sunday thank you! <3

Thanks for the great videos as always. from south korea.

Glad to see the channel growing! The Input system has always been a chore and a source of frustration for me. Especially when updated features will randomly break your workflow and cause bugs. This is great as a source for a tighter more streamlined work process to navigate. Thanks a ton for this!

Nice video! The only disadvantage I see with this approach is not being able to access the InputReader from non-MonoBehaviour scripts.

As always, great video! Thanks a lot Adam! In my case I just don't know if it's ok to set the input package to Process Events in fixed update, then I have consistent input (50Hz) and synchronization with physical simulations for controlling the player via Rigidbody2D (with Interpolation). Is it okay, or can there ever be a problem with that? In my case everything works very smooth and properly. But, you always read input in update and transfer logic of physical movement into fixed update with Rigidbody, far as I saw in your videos? :)

Awesome! I didnt look into it too much because I always felt the prototyping is easier with the "old" system. Glad I can somehow use the "better"/"newer" system without the hassle and overload it seemed to imply. Direct reading FTW ^^

I've been working with the input system for a while now and never actually bothered to read past the wall of config to get to those interfaces lmao. Very informative, thanks!

Happy Sunday! Thanks for the vid

Nice!

I create my own input reader. I create a ScriptableObject that I can store input action references in. I then throw that ScriptableObject into a custom input reader with some public methods that check the references when called. And finally I can check that input reader for inputs like the old input system. I keep swearing that I will swap over to the event version, but I'm lazy, and this works.

Haven't watched yet, but i can tell this is what i need, thanks

Never been this early lol. Also I never found a reason to use the new Input System but maybe this tutorial will serve as good introduction. Thanks !

Happy Sunday! I hope this video clears up any confusion about Unity's Input System-let me know your favorite workflow or if you have any questions below!

How to stop Unity infinite loop, like "while (true)" using Rider?

How could we update the shader to move it so the clouds scroll across the sky to give a bit of a cloud moving effect? :) could you share please?

I've got so many ideas on how I could implement these things into my game just watching this video. Another banger, extremely helpful!