This is great, but I recommend people write their signals in code, the editor sometimes will hiccup and unsubscribe your subscriptions...if they're written in code this doesn't happen.
It does appear this is the case, however, there's always an explanation. I've had dozens of different situations where I was able to hunt down a reason for it happening. It's still advantageous to do things in code when you are prototyping, because the most common ways to have signal connection issues is when you are moving things around in the scene tree after connecting them, or making a lot of changes at once without testing, or adding a scene to another scene, making it local and adjusting things in its subtree. Most of my issues have been with custom signals as defined in a script becoming disconnected. This one happens very easily. If your scene gets saved somehow with an error in a script that contains the signal...suddenly all those connections can be completely gone. Similarly, if you are using the @tool annotation, you can be in the middle of an edit to the script and pause too long...If you have something happening in _process or _physics_process or _input etc... anything that you could accidentally trigger execution in your tool script with, it can recognize your script has an "error" in it and fail to compile, resulting in any signals you connected in the node tab simply being gone. When you fix that error, the signal is back, but the connections will still be gone. So, to sum up folks: Do what @scotmcpherson is suggesting to avoid all these pitfalls and more happening to you and making your life suck.
If there was no eventBus, then everyone would be defining signals everwhere. This could lead to confusion as to where the signals come from. But with eventBus, all the signals are in eventBus, and can be viewed and managed is it the correct way to understand?
This is great, but I recommend people write their signals in code, the editor sometimes will hiccup and unsubscribe your subscriptions...if they're written in code this doesn't happen.
It does appear this is the case, however, there's always an explanation. I've had dozens of different situations where I was able to hunt down a reason for it happening. It's still advantageous to do things in code when you are prototyping, because the most common ways to have signal connection issues is when you are moving things around in the scene tree after connecting them, or making a lot of changes at once without testing, or adding a scene to another scene, making it local and adjusting things in its subtree. Most of my issues have been with custom signals as defined in a script becoming disconnected. This one happens very easily. If your scene gets saved somehow with an error in a script that contains the signal...suddenly all those connections can be completely gone. Similarly, if you are using the @tool annotation, you can be in the middle of an edit to the script and pause too long...If you have something happening in _process or _physics_process or _input etc... anything that you could accidentally trigger execution in your tool script with, it can recognize your script has an "error" in it and fail to compile, resulting in any signals you connected in the node tab simply being gone. When you fix that error, the signal is back, but the connections will still be gone.
So, to sum up folks: Do what @scotmcpherson is suggesting to avoid all these pitfalls and more happening to you and making your life suck.
The event bus... 🎉. Now i see the signals as a variable+ at least in the way they are written
THANK YOU, I could not understand why my signal arguments weren't going through. This had exactly the answers I was looking for.
Just so someone says it; i really appreciate you doing this in 4k. Also great tutorials.
Great explanation! I also love the cklicking of you keyboard, it is so satisfying😫
You have the best tutorials I ever seen
Great job sir!
I recognize that wizard
🤫
"That's 10, but okay" 😂
The player_ref thing 😮
Same reaction 😅
it would be great if you make tutorial how to make breakable objects, for example, when window hit by a bullet
If there was no eventBus, then everyone would be defining signals everwhere.
This could lead to confusion as to where the signals come from.
But with eventBus, all the signals are in eventBus, and can be viewed and managed
is it the correct way to understand?
what the signal??