Godot documentation has a metric ton of information. Of course that does mean some of pages won't be updated and this sort of confusion can occur. Thankfully, it's open to editing just like everything else.
In Godot 4, functions are first class objects, which means you can store and access them just like you would do to any other variable. On your last example, that means it should also be possible to do `var function_to_call = map_node.wake_node` instead of using Callable. An extra tip: If you find that you're defining functions that each are only used by one signal, you can define a lambda function as an argument for said signal. And you can even emit signals with parameters! # In the script initializing Scout scout_node.death.connect( func (scout, time_of_death): remove_from_nation(scout) log_death(time_of_death) ) def log_death(time_of_death): print("A scout died at %d" % [time_of_death]) # Somewhere else scout.death.emit(scout, Time.get_ticks_msec()) You can pretty much do anything you can imagine, Godot's signals and functions are that powerful.
Since functions and methods are first-class objects it's possible to make it even more concise. signalling_node.connect(signal_name, map_node.wake_node)
Recently spent like three hours doing something very similar and im so glad to see someone sharing the solution and the object page signals info. Great video btw :)
Cool! Some notes: - you don't have to compare booleans to true (e.g. if x == true: is the same as if x:) - Callable(object, "method_name") is equivalent to object.method_name I believe - I think in your final example you _should_ be able to just do signaling_node.signal_name.connect(map_node.wake_node)
So even though I have no clue about Godot it was still an enjoyable watch and I would love to see some videos on the game development side of things again, especially the actual game design side of things and seeing your plans on how the game is going to play
I code in C# in Unity and I had a similar issue that I also solved by looking through the documentation. It's honestly the best way to find better ways to do things in coding and is always helpful.
Thanks for making this! I'm interested in developing strategy games in Godot at some point in the future and I would love to see more videos about your strategy game's programming!
I have plans to! Wish i could make all the videos at once but I've got a lot (increasing amounts) i want to cover so it might take a while before I get through all of it
Honestly, great find from scouring docs, you're already on the right track imo. One handy convention I can suggest is to write permanent documentation comments with a space between the # and the comment. eg -> "# This is for documentation purposes" and for debugging comments to have no space in between them. eg -> "#queue_free()" It's just a nifty way to separating comments you want to keep and comments born out of doing quick and dirty iterations of stuff.
@@overlite_ Double hash is for documentations comments, like Javadoc but for GDScript, and can be used to automatically generate documentation for your project that matches the Godot documentation in style and format. Documentations comments should always have a space after the double-hash. Also, you can use Ctrl+K to quickly comment/uncomment lines of code (with a single hash).
Very elegant solution, I didn't know you could connect signals to other nodes like that. I'm new as well, and I am definitely more comfortable and more organized limiting my signals and accessing a global script for scene interactions. I'm not sure if that has a negative performance impact or if it might be bad practice for another reason, but so far that has been my preferred solution.
Honestly I couldn't say, the only way you'll find out is if you ask someone who knows about it or search up guides/tutorials. It's hard to do that for everything all of the time though
if i were to offer any advice to being successful with a software project it would be to fall in love with reading documentation. it will save you a lot of hours of headaches in the long run. one of the best ways to help you overcome your apprehension is to try implementing a Chip8 emulator. the doc is literally just the specification for the Chip8 hardware and you literally just translate that to the programming language of your choice.
@@VoyivodaFTW1 Thanks for writing this, this is helpful and I'll try to implement that. I've definitely had experiences with "aha" moments and enjoyed that after reading documentation. I'm sure the "fall in love" part of reading documentation will come with time!
personally I like creating signal handlers that do internal dispatch by binding extra parameters when connecting the signal. Ex: some_signal.connect(_some_handler.bind(some_params))
Funnily enough I had to solve a similar problem for a way smaller jam game. There were probably easier, faster ways to solve it, but I'm a sucker for pretty code and since I come from python, where functions are (in theory) first class citizens I figured I could just pass a function to a .connect method. Lo and behold, it did work! I'm just guessing here, but probably object.connect(self.method_name, "signal_name") would work as well, no need to create a reference to a callable (probably) Edit: Yeah, way smarter people in the comments said the exact same thing hahahaha. Not deleting the comment tho, enjoy your engagement!
Algorithm direct me to here and solve the same problem, but I only thought it in my mind. Maybe there is something more deep then just spying my search history...
ugh I am really hating the godot docs. "We don't have to point out this useful feature here, because we pointed it out on a page that isn't linked to here and you would never think to look for" fffffffffff
Wait, you're extending Script? I've never seen that done before. I extend Resource or RefCounted a lot, but what does it mean to extend Script? I thought it was just an internal class. Is there an advantage to extending Script rather than RefCounted?
Im actually not completely sure the exact difference, but (checking the docimentation) as far as I can tell extending script instead of resource means you get some extra functions that might be useful, but honestly i just do it so that i remember that the script is being used as a script only, and not as a resource nor as a node
@@MOtherMetroid docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-connect (from what i showed in the video), the box of code with 4 ways of connecting to things: I've been using option 2, but switched to option 4 as godot will be a bit better at telling me I've made a typo or other mistake (also it might be faster? Unsure)
I don’t think this is as obscure as you made it out to be. It’s in most tutorials about Godot signals and I’ve used it since day one of developing with the engine. Of course it’s a shame it’s not better explained in the signal documentation and that you had to waste so much time figuring it out but I don’t think that’s most people’s experience.
Well I heard somebody say about avoiding spending _too_ much time on polishing and refactoring. You know those half-baked AAA games? Well have you heard of games work on so much it doesn't release? Probably yeah, now that I think about it... ...and you should avoid listening about it because I left my first personal large scale game the moment college started. Doing little is better than nothing.
I don’t think this is as obscure as you made it out to be. It’s in most tutorials about Godot signals and I’ve used it since day one of developing with the engine. Of course it’s a shame it’s not better explained in the signal documentation and that you had to waste so much time figuring it out but I don’t think that’s most people’s experience.
One of my biggest failures in coding is that I rarely look at the documentation so this video has show me what kind of stuff I can miss.
Godot documentation has a metric ton of information. Of course that does mean some of pages won't be updated and this sort of confusion can occur. Thankfully, it's open to editing just like everything else.
In Godot 4, functions are first class objects, which means you can store and access them just like you would do to any other variable. On your last example, that means it should also be possible to do `var function_to_call = map_node.wake_node` instead of using Callable.
An extra tip: If you find that you're defining functions that each are only used by one signal, you can define a lambda function as an argument for said signal. And you can even emit signals with parameters!
# In the script initializing Scout
scout_node.death.connect(
func (scout, time_of_death):
remove_from_nation(scout)
log_death(time_of_death)
)
def log_death(time_of_death):
print("A scout died at %d" % [time_of_death])
# Somewhere else
scout.death.emit(scout, Time.get_ticks_msec())
You can pretty much do anything you can imagine, Godot's signals and functions are that powerful.
Since functions and methods are first-class objects it's possible to make it even more concise.
signalling_node.connect(signal_name, map_node.wake_node)
My type-safe brain aches. But my polymorphic heart is warm.
I just don't use GDScript. C# is not that much more verbose and the syntax looks so much better to me.
Recently spent like three hours doing something very similar and im so glad to see someone sharing the solution and the object page signals info. Great video btw :)
the fact that code is secondary when it comes to such a fundamental feature speaks volumes about Godot and its users
Cool! Some notes:
- you don't have to compare booleans to true (e.g. if x == true: is the same as if x:)
- Callable(object, "method_name") is equivalent to object.method_name I believe
- I think in your final example you _should_ be able to just do
signaling_node.signal_name.connect(map_node.wake_node)
So even though I have no clue about Godot it was still an enjoyable watch and I would love to see some videos on the game development side of things again, especially the actual game design side of things and seeing your plans on how the game is going to play
I code in C# in Unity and I had a similar issue that I also solved by looking through the documentation. It's honestly the best way to find better ways to do things in coding and is always helpful.
Thanks for making this!
I'm interested in developing strategy games in Godot at some point in the future and I would love to see more videos about your strategy game's programming!
I have plans to! Wish i could make all the videos at once but I've got a lot (increasing amounts) i want to cover so it might take a while before I get through all of it
Honestly I thought the solution was going to be the Grouping feature Godot has. This is pretty neat I'll keep this in mind!
5:33 - this method is superior if you're a yanderedev chad who lives off of negative publicity and is still somehow talked about to this very day
Very very very good video talk about how you’re implementing diplomacy and other “civilization” concepts thank youuuuuuuu
this video has helped me not hate switching to godot
Honestly, great find from scouring docs, you're already on the right track imo.
One handy convention I can suggest is to write permanent documentation comments with a space between the # and the comment. eg -> "# This is for documentation purposes"
and for debugging comments to have no space in between them. eg -> "#queue_free()"
It's just a nifty way to separating comments you want to keep and comments born out of doing quick and dirty iterations of stuff.
Im gonna start doing this right now (I've been doing double hashtags for comments single for debugging)
@@overlite_ Double hash is for documentations comments, like Javadoc but for GDScript, and can be used to automatically generate documentation for your project that matches the Godot documentation in style and format. Documentations comments should always have a space after the double-hash. Also, you can use Ctrl+K to quickly comment/uncomment lines of code (with a single hash).
Thanks for pointing us to the object page :p
sometimes its good to take a step back and read on the very basics
good luck with your project^^
Very elegant solution, I didn't know you could connect signals to other nodes like that. I'm new as well, and I am definitely more comfortable and more organized limiting my signals and accessing a global script for scene interactions. I'm not sure if that has a negative performance impact or if it might be bad practice for another reason, but so far that has been my preferred solution.
Honestly I couldn't say, the only way you'll find out is if you ask someone who knows about it or search up guides/tutorials. It's hard to do that for everything all of the time though
As someone who is intimidated by reading documentation, this video helped, ty!
if i were to offer any advice to being successful with a software project it would be to fall in love with reading documentation. it will save you a lot of hours of headaches in the long run. one of the best ways to help you overcome your apprehension is to try implementing a Chip8 emulator. the doc is literally just the specification for the Chip8 hardware and you literally just translate that to the programming language of your choice.
@@VoyivodaFTW1 Thanks for writing this, this is helpful and I'll try to implement that.
I've definitely had experiences with "aha" moments and enjoyed that after reading documentation. I'm sure the "fall in love" part of reading documentation will come with time!
nice, video . to trigger curiosity
This is just how to connect signals before Godot 4. :P But a cool use of it!
personally I like creating signal handlers that do internal dispatch by binding extra parameters when connecting the signal. Ex: some_signal.connect(_some_handler.bind(some_params))
Funnily enough I had to solve a similar problem for a way smaller jam game. There were probably easier, faster ways to solve it, but I'm a sucker for pretty code and since I come from python, where functions are (in theory) first class citizens I figured I could just pass a function to a .connect method. Lo and behold, it did work!
I'm just guessing here, but probably object.connect(self.method_name, "signal_name") would work as well, no need to create a reference to a callable (probably)
Edit: Yeah, way smarter people in the comments said the exact same thing hahahaha. Not deleting the comment tho, enjoy your engagement!
Gonna go read the Object page...
Algorithm direct me to here and solve the same problem, but I only thought it in my mind.
Maybe there is something more deep then just spying my search history...
I also have struggles making a flexible and scalable code.
I am working on a game like Kenshi, just 2D.
It has been... a bumpy road to say the least.
Overlite's Godot Tips
Man I gotta read the docs more
good vid, There's a lot of hidden feature in doc. unfortunately I hate reading.
Isn't this the same as having an abstract method wake_node() with a default implementation that does nothing?
my beloved signal connector node with 4 exports
the signal name, node to connect from, node to connect to and callable name
cute pfp :3
Wow man!!!!
ugh I am really hating the godot docs. "We don't have to point out this useful feature here, because we pointed it out on a page that isn't linked to here and you would never think to look for" fffffffffff
Audio is so quiet wtf
yup lost me in the first 25 seconds.
Wait, you're extending Script? I've never seen that done before. I extend Resource or RefCounted a lot, but what does it mean to extend Script? I thought it was just an internal class. Is there an advantage to extending Script rather than RefCounted?
Im actually not completely sure the exact difference, but (checking the docimentation) as far as I can tell extending script instead of resource means you get some extra functions that might be useful, but honestly i just do it so that i remember that the script is being used as a script only, and not as a resource nor as a node
@@overlite_ Thanks! I love advanced signalling stuff, so really enjoyed the video.
You do realize you shouldn't be using strings with signals right? Signals are themselves objects you can reference as variables.
No joke immediately after making the video i realised this and switched
What does that mean? Did you change any code?
@@MOtherMetroid docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-connect (from what i showed in the video), the box of code with 4 ways of connecting to things: I've been using option 2, but switched to option 4 as godot will be a bit better at telling me I've made a typo or other mistake (also it might be faster? Unsure)
Yeah it'll be better performance then strings, though for most people that's certainly negligible.
I don’t think this is as obscure as you made it out to be. It’s in most tutorials about Godot signals and I’ve used it since day one of developing with the engine.
Of course it’s a shame it’s not better explained in the signal documentation and that you had to waste so much time figuring it out but I don’t think that’s most people’s experience.
nice voice sis
Well I heard somebody say about avoiding spending _too_ much time on polishing and refactoring.
You know those half-baked AAA games? Well have you heard of games work on so much it doesn't release? Probably yeah, now that I think about it...
...and you should avoid listening about it because I left my first personal large scale game the moment college started. Doing little is better than nothing.
WOW. is this legal?
Yes but only if you use this power responsibly (sensible node structuring)
I don’t think this is as obscure as you made it out to be. It’s in most tutorials about Godot signals and I’ve used it since day one of developing with the engine.
Of course it’s a shame it’s not better explained in the signal documentation and that you had to waste so much time figuring it out but I don’t think that’s most people’s experience.