Thank you for this! It video helped me better understand using a signal bus. BTW to anyone getting the error 'argument 2 should be callable', change Signal.connect("score_change", self, "some_function") to Signal.connect("score_change, self.some_function
That's actually huge for threads, thanks for that, I thought they just fixed the notation to be relative of the node that the threaded function was called from, didn't know you could still use "self"
Hi, i wonder is this use case for autoload: Let's say we are on open world and we creates monster procedurally and monsters emits damage signal, So because we creates monsters on runtime we cannot connect to player via editor UI, we have to connect via script so this method can be used right?
Depends on the design I guess.. When you're using areas or rays or some-such for collision checks, you can use that to figure out what object you're communicating with (and telling it to receive damage or such). But for entities that don't use any sort of collision check, I suppose an autoload could help for signals, yes. For turn-based games perhaps?
So in the autoload script (aka signal buss) it would make sense to have stuff like: combo counter player dead player health score music state But for things like: adding an impulse to an object checking collisions (in order to emit a signal) it would be better to have them connected by their relevant scripts. eg, if the player hitbox collides with an rigidbody's hurtbox, emit a signal that adds an impulse to the rigidbody. Would there be any drawback to including these sorts of things in the autoload?
I think the main issue with that would be code readability. You want to be able to find things again later if you need to make any changes. When a hitbox collides with something, it already automatically emits a signal at that specific node, so you can use that to gain any needed info. No point sending one elsewhere for that. So yeah, autoloads are best for anything you need access to from objects that aren't directly related / that shouldn't have to keep track of which other objects exist or where in the tree they are.
@@iaknihs Thanks for getting back to me. I appreciate it! For context, I'm trying to make a Touhou 1 style game, where players bounce a ball through collectibles scattered around the stage. So this is a rigidbody2d (ball) colliding with an area2d (hitbox) Once I got this working, however, I discovered that this mechanic was very unpredictable, making gameplay tedious and frustrating. So now I'm trying to redo it as a boomerang-style mechanic, where the rigidbody ball goes out and comes back to the player position. I can get it out, but I can't get it to return to the player. I was thinking of maybe trying a follow path2d, rather than forces. Anyway I'm rambling now, but thanks again! have a good one :)
Nice video! It certainly helps when you need to spawn a node in some far node. I have question tho. Instead of creating signals. Why not store the node ScoreLabel reference in the autoloaded script and then change it from anywhere, like in the player node directly? I'm trying to really avoid hard coding stuff and get node is terrible due to this and signals still require you to mention the method using string. It's a big problem. Change some name anywhere and I'm screwed =/
If you store a reference to the ScoreLabel in the autoload, that's probably fine in this simplified case (only 1 emitter and 1 receiver), but in reality you'll often end up with lots of nodes receiving the same signal and acting on it in different ways (say, lots of enemies being notified that the player has entered a specific area that affects how they should act, or crates being notified that the player is short on ammo and maybe they should drop a bit more of that than usual). On the flipside there are also situations where you might have 1 signal that can be emitted by multiple different nodes (say there are different things that can make the player's coins go up like the player picking them up, a projectile hitting them, depending on the game maybe even an enemy running into them. Now rather than the player emitting a signal of collecting a coin it might make more sense for each coin to emit the same global signal when it gets collected). As for hardcoding, generally Godot works on the assumption that nodes know their children, but not their parents (call down, signal up). So a parent can call methods on children, but children should stay decoupled and not have to know their parent. So if a parent wants to know what the child is doing, it can subscribe to a signal there. The 'event' autoload is outside of that distinction, but is essentially a sibling to the entire tree. As long as you make sure to keep all global signals in an easy-to-find place you shouldn't have to refactor a lot even if you change something. Case of doubt, Ctrl + Shift + F (or Cmd + Shift + F) does exist as shortcut in Godot to let you find and replace occurrences of a method/signal name and similar things across all files. Godot 4 has also streamlined signals a bit more so you no longer have to use "strings" but can use callables instead.
if you were going to eventually be making a shop system and wanted to store your currency value (score) where would be the best place to store it? because I'm assuming on the player wouldn't be the best place. Great tutorial also + 1 sub
If several systems are gonna interact with it (player increases it when interacting with things that give money, shops increase or decrease it, the UI displays it possibly in several places, etc.) I would personally put it into an Autoload specifically for storing game data. (like most stuff you might wanna write to save files later) Also thanks!
Thank you for this! It video helped me better understand using a signal bus. BTW to anyone getting the error 'argument 2 should be callable', change Signal.connect("score_change", self, "some_function") to Signal.connect("score_change, self.some_function
That's actually huge for threads, thanks for that, I thought they just fixed the notation to be relative of the node that the threaded function was called from, didn't know you could still use "self"
thank you buddy
Thank you for teaching this
People may underestimate the power of autoload but its very very important
Hey, very nice videos !:) Keep up the work , subscribed
Thanks!
solid tutorial
thanks!
Thank you!!!!!
Very welcome!
thanks so much
Hi, i wonder is this use case for autoload:
Let's say we are on open world and we creates monster procedurally and monsters emits damage signal, So because we creates monsters on runtime we cannot connect to player via editor UI, we have to connect via script so this method can be used right?
Depends on the design I guess.. When you're using areas or rays or some-such for collision checks, you can use that to figure out what object you're communicating with (and telling it to receive damage or such). But for entities that don't use any sort of collision check, I suppose an autoload could help for signals, yes. For turn-based games perhaps?
So in the autoload script (aka signal buss) it would make sense to have stuff like:
combo counter
player dead
player health
score
music state
But for things like:
adding an impulse to an object
checking collisions (in order to emit a signal)
it would be better to have them connected by their relevant scripts. eg, if the player hitbox collides with an rigidbody's hurtbox, emit a signal that adds an impulse to the rigidbody. Would there be any drawback to including these sorts of things in the autoload?
I think the main issue with that would be code readability. You want to be able to find things again later if you need to make any changes.
When a hitbox collides with something, it already automatically emits a signal at that specific node, so you can use that to gain any needed info. No point sending one elsewhere for that.
So yeah, autoloads are best for anything you need access to from objects that aren't directly related / that shouldn't have to keep track of which other objects exist or where in the tree they are.
@@iaknihs Thanks for getting back to me. I appreciate it!
For context, I'm trying to make a Touhou 1 style game, where players bounce a ball through collectibles scattered around the stage. So this is a rigidbody2d (ball) colliding with an area2d (hitbox)
Once I got this working, however, I discovered that this mechanic was very unpredictable, making gameplay tedious and frustrating. So now I'm trying to redo it as a boomerang-style mechanic, where the rigidbody ball goes out and comes back to the player position. I can get it out, but I can't get it to return to the player. I was thinking of maybe trying a follow path2d, rather than forces.
Anyway I'm rambling now, but thanks again! have a good one :)
@@midnightkiteflight6333 did you ever finish your touhou 1 style game? If so I would love to play it, I'm a huge touhou fan :D
Nice video! It certainly helps when you need to spawn a node in some far node. I have question tho. Instead of creating signals. Why not store the node ScoreLabel reference in the autoloaded script and then change it from anywhere, like in the player node directly? I'm trying to really avoid hard coding stuff and get node is terrible due to this and signals still require you to mention the method using string. It's a big problem. Change some name anywhere and I'm screwed =/
If you store a reference to the ScoreLabel in the autoload, that's probably fine in this simplified case (only 1 emitter and 1 receiver), but in reality you'll often end up with lots of nodes receiving the same signal and acting on it in different ways (say, lots of enemies being notified that the player has entered a specific area that affects how they should act, or crates being notified that the player is short on ammo and maybe they should drop a bit more of that than usual). On the flipside there are also situations where you might have 1 signal that can be emitted by multiple different nodes (say there are different things that can make the player's coins go up like the player picking them up, a projectile hitting them, depending on the game maybe even an enemy running into them. Now rather than the player emitting a signal of collecting a coin it might make more sense for each coin to emit the same global signal when it gets collected).
As for hardcoding, generally Godot works on the assumption that nodes know their children, but not their parents (call down, signal up). So a parent can call methods on children, but children should stay decoupled and not have to know their parent. So if a parent wants to know what the child is doing, it can subscribe to a signal there. The 'event' autoload is outside of that distinction, but is essentially a sibling to the entire tree. As long as you make sure to keep all global signals in an easy-to-find place you shouldn't have to refactor a lot even if you change something.
Case of doubt, Ctrl + Shift + F (or Cmd + Shift + F) does exist as shortcut in Godot to let you find and replace occurrences of a method/signal name and similar things across all files. Godot 4 has also streamlined signals a bit more so you no longer have to use "strings" but can use callables instead.
@@iaknihs Thank you very much for your detailed response mate ^^
if you were going to eventually be making a shop system and wanted to store your currency value (score) where would be the best place to store it? because I'm assuming on the player wouldn't be the best place. Great tutorial also + 1 sub
If several systems are gonna interact with it (player increases it when interacting with things that give money, shops increase or decrease it, the UI displays it possibly in several places, etc.) I would personally put it into an Autoload specifically for storing game data. (like most stuff you might wanna write to save files later)
Also thanks!
@@iaknihs thanks for the quick reply!
this doesnt help me because my items are in their own scene