Godot Tips on handling Input : Input Singleton vs Input Event - Detection and Unexpected Issues

[@vader9133]

This isn't just a solution for input, it's also a tutorial for one of the cleanest state machines I've seen yet. Very nice work.

[@sharron6151]

Thank you so much for your indepth explainations in this whole series! Many problems are caused by overly quick "do x in 1 min" tutorials without going into depth behind it. You're doing a great service to helping me and all the people finding this series in the next few years👍

[@NiklasAndersson7]

Wow. Just found your channel. This is high quality content! Thanks a lot. *subscribed*

[@MrReirgen]

Thanks for the video dude, your contribution to the knowledge about RTS games in Godot is really appreciated. By the way, to further improve performance, have you thought about trying Jolt Physics?

[@nanotechgamedev]

Jolt is really nice, and it could work as an optmization, however it makes you depend on a third party tool, which some people don't like to, so for these tutorials I am going to do my best to avoid using it, however yes, perfomance increases a lot if you are using jolt physics, which might be one of the reasons why Horizon forbidden west used it, really good stuff, thanks for mentioning that up, didn't knew about it until your comment.

[@reptiliannoizezz.413]

I'm confused... What do we put inside each "INPUT_STATES." in the Set Get code, and inside each "if" line inside the _input func?

[@nanotechgamedev]

TLDR: For the Set Get is anything you want to happen whenever the INPUT_STATE changes to run automatically, this is a way of reducing code to not write it with extra lines with the new state given to the variable from someplace and it stays in one place neatly organized, the ifs inside the input function are controlling what is going to happen with player input commands, they are specific conditions for the things I want executed in a particular order, these conditions can be whatever you want to check at that specific state, - INPUT_STATE is a int, a number, we define them as a enum to be more visually clear what they mean, so we can define specific states for the interface input, like IDLE, BUILDING_MODE, FORMATION, these in a enum would be like enum{ IDLE, BUILDING_MODE, FORMATION }, this would be the same thing as defining as an array like [ 0, 1, 2 ], but now in code we can write IDLE, BUILDING_MODE, instead of 0, 1, 2. The Set Get code for INPUT_STATE is a way to run code when these states changes, it's just another place you can execute code, so instead of having to write them whenever we assign a new value, we can run extra code in a set get, the code can be anything you want to execute, Let's say you wanted a sound to play whenever you changed states, instead of calling it everytime together in the code whenever you change the INPUT_STATE, INPUT_STATE = IDLE PLAY_SOUND() You can just put that inside the set get functions whenever INPUT_STATE changes, so then just by changing our INPUT_STATE = IDLE, we would play a sound. That's why set get is useful, you can execute code whenever a variable changes automatically. The if lines inside inside the _input function are conditions for things specific I want to control, the way I am organizing my code is for the Input of the player to first see what is the STATE of the interface, that's why we do the ( match INPUT_STATE: ) command, then later check some things specifically. These things can be anything you want, the IFs are just conditions to execute something or not, For instance, I created a formation state to control how the Input is going to be used whenever we have units selected and want to move them as a formation, this is just an abstract way of controlling the player inputs when the interface is at a given state, this avoids having to branch out a bigger tree of conditions with a lots of IFs and elses,

[@reptiliannoizezz.413]

@@nanotechgamedev Ohhhh, of course. Currently I have nothing I want to happen when the state changes so that might be why I didn't figure it out. Who knows in the future tho. Thanks! I did eventually figure out the _input part tho and got it working by copypasting the code I'd made from previous tutorials

[@TheChexmo]

do you have any video explaining a good way to make drag and drop mechanics? it's useful for UI and so for gameplay

[@nanotechgamedev]

No videos about it right now, but from the top of my head I would make use of Rect2.has_point(point:Vector2) functions, we can pool the mouse movements to know if it is inside a certain ui graphic by retrieving a name or object, then after a click and drag we can copy the mouse position to the ui element, on the mouse release we check if it's inside another Rect2 to snap the ui to the new place, or if it's invalid, we can reset back to the original place the ui element, this plus a few changes on the modulate color to show some feedback that you are dragging should be enough to make a drag and drop system, of course, there are many other ways you can do this, Godot might have something built-in with controls and containers, I think with areas2D there's something about them being clickable, but I would probabilly do it this way with Rect2s,

[@TheChexmo]

@@nanotechgamedev yeah, thanks for answering in the first place... I've been looking for any content about drag and drops for a while and found nothing very interesting. I'm starting a game where drag and drop is the core mechanics, in few words, so the topic is becoming important to me. The few tutorials I found are not detailed enough to be clarifying nor deep enough to let me understand how to customize the solution to my needs. Nevertheless event handling for touch(mobile) and pointer(pc) aren't the same, they have their own methods in the standard api. I believe a video with your style in this topic would be helpful for the community.

[@SosumiInc]

This was a fantastic tutorial. Thank you.

[@sp.v.207]

this great, thank you

[@vittoork21]

br? esse sotaque n me engana

[@nanotechgamedev]

Yea, another one that knows it, sotaque sempre fica na lingua né rsrs,