
The general guideline is to signal up and call down.

Also, it could be avoided by checking if Node2 was null before calling has_method().Īm I missing something? Areas and timers are basically the only time I use signals, creating custom signals just seems like a long solution to a short problem. The only problem I've had with this is getting a null instance error if I try to call has_method() on a node that's been deleted, but so far that was only because of my own mistakes and is completely avoided by what I would consider good game design. I could navigate the node tree to access the Node2, and use: I could create a signal, navigate the node tree to access the node I want to send a signal to, then connect it, then emit it to call that method. If you're going through the trouble of manually navigating your node tree using get methods, why even bother with signals after that?įor example, I want a method in Node1 to call a method in Node2. So, moving on to connecting signals with code, you still have to reference the node you're trying to communicate with in order to connect. This makes the editor side of things completely useless for procedural generation projects, or even for a system that uses a gun that instances a bullet when fired. To my understanding, connecting signals in the editor is impossible for nodes that aren't added to the node tree until after the game runs. People seem to act like signals are your best friend when it comes to communicating between different nodes and decoupling, but honestly I don't see why. HDRI Haven – CC0-licensed panorama skies.CC0 Textures ⋅ ⋅ Texture Haven – CC0-licensed PBR materials.Godot Shaders – Shaders specifically made for use in Godot Engine.

