You can't set node paths in the editor across scenes, and even setting them programmatically with scripts can be tricky. The external node is likely to be in the same scene.This isn't a hard requirement, but for scenes and custom classes it can become difficult to tell if the user-provided dependent node is valid.
The external node can be any instance of a builtin class (e.g.The key here is to have your script "fail safe" and check if the nodepath is unset before trying to do anything with it. The AnimationPlayer and AnimationTree are a good example. The builtin nodes use this trick all over the place. This is admittedly really close to breaking the rules, but it sometimes makes sense to let your user tell the child node where to find a loose dependency. Now to your point: what options do you have for preserving branch independence besides "call down signal up"? Export a NodePath and more importantly if you haven't satisfied this "branch independence" principle despite calling down and signalling up, you may want to re-think your code. If you can get to that end some other way, it's probably fine.
SIGNAL DOWN SOFTWARE
It's not some deep principle of software design, it's a means to an end. We're calling down and signalling up purely to facilitate effective use of godot's scene tree editor. Now, it may not actually do anything substantial, since nothing is controlling it or listening to its signals, but it shouldn't throw any errors or require any particular type of parent in order to function properly. In other words, if you right click on any node and choose "save branch to scene", you should be able to run that scene on its own without getting any errors. Let me propose a different mantra that I think captures this idea better than "call down, signal up":Įvery branch of your scene tree should function independently of its parents.
Their behavior is encapsulated by the set of methods, properties, and signals they expose. Nodes can be instanced anywhere in the scene tree and don't care what their parents or siblings are. Strictly speaking, the idea is to make your scenes behave like nodes. I think it helps to keep in mind why you'd want to "call down, signal up". Not because it's a bad idea, but because it's an incomplete idea. I don't personally think the "call down, signal up" advice is particularly useful. Is there a better method than "call down, signal up" or a better way of organizing things so that signals aren't limited to one-way communication? The game class could navigate down through the interface, through the command console, and through the command handler to tell it to output the response, but that would be disorganized and adding functionality to the game class that should remain within the command handler or the console. Since signals don't use return values like functions, the command console is not unable to respond with "player does not exist". But the command was to teleport to a player that doesn't exist. So if I need to communicate upward, it's only one direction which isn't very helpful.įor example, a a debug console takes a command input and emits a signal to send it to the game class that's listening. Second, signaling up just sends information, it doesn't receive it (like a return value on a function). $Interface/Debug/Console/nnect("teleport_to", self, "_on_CommandHandler_teleport_to")įunc _on_CommandHandler_teleport_to(target_player): And you connect to signals by going down the tree, finding the signal-object, and connecting to it. But I'm not sure how this advice works.įirst of all, signaling up still requires messy node-paths since you have to connect to that signal. The common advice is to "call down, signal up". I always find myself getting into the mess of having long node-paths and such where moving things around starts breaking things.
0 kommentar(er)
