Signals in Godot are Amazing!
Вставка
- Опубліковано 2 сер 2023
- Follow Me on twitch: / chaff_games
In this video I show you the fundamentals of using signals in Godot. I will give you some Godot tips and trick to help you improve your use of Godot signals.
Signals in Godot are truly amazing!
In Godot, Signals allow the nodes in your scene to easily communicate with each other without requiring a direct reference to one another. You can do some seriously amazing thing in the godot game engine. And in the new Godot 4 signals have become even better. So sit back and learn all that they can do.
Get the FPS Template Here: chaffgames.com/fps-game-templ...
Join The Discord: / discord
Support the Channel: / chaffgames
My Latest Course: www.udemy.com/course/building...
My Set Up:
VO Mic: amzn.to/3QfnL6d
Audio Interface: amzn.to/46MFidg
CloudLifter: amzn.to/49dMUqE
Camera Mic: amzn.to/4980cFh
Case: amzn.to/46JiTxi
CPU: amzn.to/471Jeah
GPU: amzn.to/3si8r0G
Keyboard: amzn.to/3tPL6nC
Mouse: amzn.to/46KhM0h
As an Amazon Associate I earn from qualifying purchases.
---------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------
Please like and Subscribe! It's truly appreciated
#GameDevelopment #GameJam #Godot
Links to my Socials
Instagram: / chaff.dev
Twitter: / chaffdev
Itch.io: chafmere.itch.io/
Website: chaffgames.com
What Feature should I cover next! Comment Down below and I'll the most liked one!
Regarding your last cable metaphor, Id say a signal is more like yelling from one room, and someone listens in another. You dont really care who listens and dont have a specific cable going there. Whereas a function/method with a known reference is like the cable, having a set start and end point that can be traced.
NGL that was exactly what I wanted and I'm so glad you uploaded this video, thanks a lot.
My suggestion for the next video would be Control nodes, the way they scale is confusing as hell.
I come from Roblox Studio so I know just how crazy good events are, but making them in Godot is much easier and more intuitive once you get it. Thanks for showing this!
Signals are a really powerful type of inversion of control. I strongly recommed use them even if you want to call a function of a child node in the parent node. Make references to other nodes make your node more and more dependent of each other, that makes your project more difficult to maintan. So, please priotirize use signals
Having switched from BO3 modding, moving to singleton function libraries & storage in Godot, to now getting serious with signals, I'm definitely a bit surprised the concept of a 'global event bus' isn't implemented by default, at least to my knowledge.
BO3's version of a signal system (notify (the signal event), endon (end current function if node receives specified signal), & waittill (allow node to resume upon signal if waiting)) one is able to specify things like "level waittill(, [sender_capture]);", & "level notify();" as opposed to self / specific_object waittill(, [sender_capture]);" and "that_specific_object notify();" respectively. Cross-node, cross-script, no outright defining functions or receivers at all. Just single-line notifications.
Edit: Where Godot's signal system may be connecting cables to & from defined ends, BO3's has the additional ability to be a bunch of vague people standing in various rooms & one guy yells, alerting everyone who was told to stand in that room & it'd be pog if this could become a standard reality in Godot, as great as it is.
That's a rather specific design pattern, but easily done with Godot signals. All the "vague people" in each "room" could connect to a signal (one signal per "room") and you have what you want. You could improve it by using an autoload singleton script in which you would do a little queue or stack depending on what you need.
with singleton, are you talking about the "AutoLoad" featured on godot? doing a "signal manager" on godot is so goated and simple is amazing
@@ragiex6624 Yep, I think I'm talking about AutoLoads, but just for the function libraries.
I did an initial connection setter to, upon a emission on of a node, call various functions from the specified receiver nodes when a level begins. Not quite a signal manager, not even autoload, but it works for its use case.
connectGroup(sender_group_name:String, receiver_group_name:String, signal_name_of_senders:String, receiver_functions_to_run:Array)
connectGroup("goals", "exits", "_AllBoggiesRescued", ["revealExit", "revealExitLadders"])
@@tudorm1203 Definitely something I should dedicate some more time to after the completion of my current project.
I gave it time earlier, months before I made my host comment, but I wasn't able to readily figure out substitutes for neither ENDON nor WAITTILL, as it doesn't seem like Godot is currently capable of handling busy functions from the outside.
To my understanding, even if I track active functions, I can't exactly do anything with them. I hope I'm just missing something.
If you have any insight, experience, or relevant theory on this, I'd love to hear !
Problem with signals is I need to know what node I am connecting to. At that point it is a glorified list on the main object that has a bunch of delegates. I would rather have a static or global list that I can subscribe where ever and have no care in the world who calls it.
Memory issue
I think the most convenient way of using signals is to have the signals be emited from an autoload. Let's say the autoload is called Sgn. If player got damaged, the player it will emit a signal like Sgn.emitsignal("healthchanged",new_health). The health bar which could be anywhere in the Hud scene structure can connect to the signal and work as intended.
Whats the full of HUD?
Just found your channel, great reasource for those learning godot :)
Little editing glitch at the start with the repeated line but overall great
👀glitch? I went over so many times I can’t believe I missed it.
I had major Déjà vu just watching the first 15 seconds of this video.
for real it freaked me out
I dislike the hype that signals get. I'd rather use global variables. It is extremely rare the cases where I need to use a custom signal.
Example, you hit the target and need to notify the UI.
There is only one UI in the game, I have the UI declare itself as the only UI on the game, so in it's "_ready" function we have "Globals.ui = self".
Then the bullet hits the target, when the bullet enters the body I call right there:
Globals.ui.update_bullet_hit().
It's that simple. There's no get_node(../) shennanigas. There's no declaring a signal. There's no signal emit. There's no signal connect.
At the end of the day, if that what works for you, then that’s best way to to it. I really like hearing about all the different ways people overcome these challenges.
I also dislike Signals. It creates a spaghetti msg everywhere. It's confusing to me as a noob at programming. What do you mean by "Globals.ui = self" ? If I understood you're creating an autoload(singleton?) placing there all your global variables and methods that can be used by any node. Right? Would be great if you could help me because I'm desperately trying to avoid the hard coded path nodes. I really don't get why everyone uses it. One simple change and the entire project will crash and it doesn't even get you an error until the game is running
@@nadadenadak It's good to read comments on this video. I really don't understand why the signals are so praised. They seem like a terrible programming rpactice to me. Then again, I'm not very experienced programmer and I've only made couple of games in GameMaker before, so maybe I'm missing something.
Your design is fine if you're ok with never supporting a split screen / co-op mode where there could be multiple UIs at once
This sounds like you could make the UI a unique node and do get_node("%UI") from anywhere
Question, Sensei ☝️
You said signal is the way nodes to communicate to each other without reference, but from very little thing I know as we try to connect to emitted signal, we still need to write the "connect" using the emitter name, for example:
Head Node(Emitter)
Signal took_damage(amount)
emit_signal("took_damage", 999)
Body Node(Listener)
onready var head_node = "head_node path"
func _ready():
head_node(emitter).connect("took_damage"(signal name), self(target), "calculate_damage"(function that reacts to the signal))
Or did I miss something?
Please, answer 🙏
no this isn't how signals have to work when you select the emitting node go to the node tab, after that connect your signal ( you have to assign a signal first like you did in the Head Node ) with any node in the current scene.
hope that helps
@@awesomewow668 Thank you
Perhaps I should have worded it differently. Since you can connect a signal without creating a direct reference but you can also create a direct reference to connect a signal, if you need to. Or even in your example the emitter object doesn't have a reference to the listener. The listener has a reference to the emitter to facilitate the connection.
@@Chaff_Games Does this concept apply on both 3.X and 4.X?
This is predominately Godot 4 Focused but I'm pretty sure that most of these concepts work in 3.X. The functions you use are different though and 3.X doesn't have Callables which reduces the utility a bit as well.
I don't quite understand what do you mean by you don't need a reference to a specific Node to connect the signal.
Kinda yes... You don't need in the code. But you still need a reference through the signals inspector.
Anyway you bind together two entities. Yes, not through the code but they are still bind together through Godot.
I though the idea of signals is that some entity creates signal and all other entities can just subscribe to signal through some abstraction. I mean without binding anything anywhere. One entity invokes signal and the other listens to it by the signal name or id or something.
Yes, this what I mean here.
@@Chaff_Games But that's not how it works though. You can't just have one node create a signal and emit it so that any node who wants to do so, can subscribe to the signal and receive it. Not without either of them having a reference to the other. Because at least one of them needs to exist when compiling so you can connect them, whether you do it in the editor on through code.
This is precisely my confusion with signals.
I'm new to Godot and just learning about this stuff. It really bothers me to work on the editor and the code feels empty. I'd rather do everything in code, just like the "$" node reference method.
How can I use signals like that? To clarify, it bothers me to go pressing buttons in the editor every time I want to connect two nodes or scenes. I'd rather just write it in code. The documentation feels better that way as well, as I can see everything in the code unlike the signal method where there are only ambiguous icons, signaling that I'm connecting two nodes or scenes.
Thanks for taking the time to explain this. I thought the same thing. What Godot implements doesn't seem like the observer pattern to me
I like this video for showing what it can do... but it would be better if it showed how to do it more in depth.
signals more like Sometimes I want to bang my head to the wall 😩 every single time I made one it get even worse and more complex 😭
When I saw
signal ...
signal ...
signal ...
signal ...
signal ...
signal ...
signal ...
signal ...
signal ...
signal ...
signal ...
at the top of the code file, I started to have ~questions~ lol
Do you count the signals of the built ins and ask the same questions?
@@Chaff_Games That's a good point. Although I would say those are slightly different in that you're probably usually only going to ever actually use 1 or 2 of those, rarely more.
Yeah fair. I know a lot of people seem to dislike using signals. But I much prefer them over calling a function directly. To each their at the end of the day. You want to poll a variable in the process function, I won’t stop you. But you won’t find it in my project.
@@Chaff_Games Sure, and thanks for sharing the way you like to do things. I'm still fairly new to Godot, so I was trying to take the temperature on standards. Sharing code on youtube takes guts lmao
@sibotime sometimes the comments get you feeling pretty bad (not yours though I was having fun with it).
Is it possible to send a signal to a node in another scene?
If the scene is loaded under the root scene. If it’s not loaded then no. You will still need a way to connect them, a lot of people use auto load singletons to handle that.
I hate that they implemented them with strings. So much unnecessary overhead, if you use alot of signals and it is just stupid.
You just have no idea about signals, neither about compatibility, and i don't think you should criticizing such a topic unless you have a better idea
@@vexymous I can criticize whatever I want. I used them and I find it stupid. They are harder to debug, not as easy to work with and not as optimised as UIDs as integers for example. What do I don't understand?
@@vexymousdo you have a better idea than a more efficient implementation than strings?
They don’t have to be strings anymore.
@@Chaff_Games what variables can work now? And which one is the most performant?
yo this is funy assssssssssssssss
This seems unnecessarily painful imo. Perhaps I just got to get used to it.
???? you literally add a single node to the different objects and then code what you want it to do it's so simple
Honestly, signals are the one thing that I think are a downgrade since moving from Unity. There's still coupling between nodes because either doing through the inspector requires you to have both nodes in the same scene, or doing it from code requires a hard reference to the emitter. Back in Unity, you simply have an object emit an event, and other objects just subscribe to the events without any referencing to the emitter.
You can create a singleton that acts as an event bus to avoid coupling between emitting node and listener nodes.
@@martinendrst1410 how can I create a signal with no reference in a gdscript as singleton?
Hard agree.
@@martinendrst1410 within a month of making this comment, I actually found that out! It kind of patches that problem up.
@nadadenadak look up event bus godot tutorial, that's how i found out.
I'm just learning Godot and it seems like a downgrade from GameMaker as well. Why can't I just write a single line of code like with the "$" sign method of referencing nodes? Why do I have to go messing about in the editor?
After the whole unity mess up, I tried to go and I found signals to be just the dumbest thing I've ever seen in a program in language. I mean, why would you need something like a signal to connect notes together? Why can't you put multiple script on one note? If you wanna do that cause essentially the way it was explained to me. Is that signals baseline? Make it so nodes can have access to Gd script. The other notes have connected to them. It's very confusing, especially for beginners and like I said, higher level. Programming languages like C-sharp and c plus plus in their perspective. Game engines, you just write another script and just attach it to the game object. I mean, it's done, it doesn't have to be yo. It's difficult to get a game object to move or do something. Buy beer and I'll just write another script so I don't get the whole y Gd scripted. Hawaiian gymnastics and good. Those things that are so great to have these signals everywhere.
I don't know, baby. I'm missing something or if. It's something that you know.Maybe I just don't understand but I literally have tried and tried to understand what these things do and why we need them and from what I can tell.It's only because of g d script incapability of attaching multiple scripts to a node
Signals are real common in programming 🙃
Signals are the worst thing about Godot. I hate them so much.
You’ll get used of them ;)
this is a joke isn't it
Well I’m trying to be funny.