clearly a child node doesn't inherit the class of its parent or anything. It does seem to be...maybe not "inheriting," but affected in some way by the transforms, visibility, and so on of its parent.
This is correct.
If that sort of thing were as far as it went, I think I'd be okay (it seems similar to how "parenting" works in Blender).
For clarity: it is compositional. Each Node has an aggregation (as understood in OOP) of children Nodes. Which creates a tree. And there are things that are propagated through the tree (e.g. visibility and transformations). Which also includes the way some callbacks propagate (which is not a thing in blender), for example Godot will call _ready on the children before calling it on the parents.
It also seems to have some sort of file-system folder sort of thing going on, which I can also understand for purely organizational reasons.
It has nothing to do with the file system.
With that said, you can instantiate scenes in the tree in the editor, and it makes sense for some files to be stored in the same folder as the scene that uses them.
(Like how you can in a script treat the node tree like a file path, sort of.)
I believe you mean the $ syntax, it is syntactic sugar for get_node. It uses a scene node path, so it is effectively a query on the scene tree. And unrelated to the file system.
But then there are some nodes that say they require a certain child and/or parent to function at all. I don't understand at all what's going on here. Do certain nodes just need to talk to other nodes, and have built in "if I have that node as a child, I'm using it" sorts of things going on?
Basically, yes.
Any node can post a warning on their own logic, which might include checking what nodes they have as children. And some nodes care about the children they have because they use them in some special way. Furthermore, they might not be fully functional without them.
Or is there some sort of inherent "this node is MY CHILD/PARENT, and therefore...something!"
I'm not sure what you are imagining here. But I'm going a limb and say yes. Whatever you are thinking is likely possible, and likely already been done.
Some Nodes care about its parent (instead of the parent caring about the children). For example the BoneAttachment must be a child of an Skeleton.
And why would a node require a child to work at all? I'm so confused.
Some Nodes use information from the children. For example, the physic bodies will use the colliders it has as children. And they will warn you if they don't have one, because a physics body cannot get collisions if it does not have colliders, and without collisions a physics body is of little use.
Some Nodes will manipulate the children. For example, the Containers will re-arrange the children Controls. However they don't require them, an empty container is not a warning.
Scenes as a whole seem to just be a root node with some children, so is any parent node basically just a scene (except not officially called one and maybe missing some of the instance-functionality that comes with it)?
Scenes are node (Godot does not have a Scene class).
What will make Godot show a Node as a scene is whatever or not it is saved to a separate file. In other words, a scene file serializes a Node with its children, unless the children are serialized to a different scene file.
And, of course, Godot does not only serialize nodes to scene files, it also loads them and instantiate them.
TL,DR: What do parent nodes get from children, and what do child nodes get from parents? Is it only stuff like transforms, visibility, existing-in-the-scene-tree, etc.? Or is there more? I'd appreciate as complete a list as possible. Thanks so much!
As I mentioned, the Node class has an aggregation of children Nodes.
The SceneTree class has a root Node, and the recursive aggregation of children creates a the tree.
Going further The SceneTree class will call methods on all the nodes on said tree (For example _process).
Beyond that, other classes that inherit from Node might use the children in different ways. For example objects of the Spatial will figure out their global_transform from the transform of their parents, recursively. And more specialized Nodes might use their children or parent relationships in more specialized ways.
If you think about it, your scenes are very specialized Nodes for your game. And you attach a script to the root of your scene that uses its children in very specialized ways (for example, it might play different animations in an AnimationPlayer depending on user input).
I should point out that not all communication between nodes should be done this way.
Note that when you instantiate your scene, you know it has all the Nodes the way you set them in the editor, so it is OK for your code on them being there (unless there is some code that might remove them).
But when you want to communicate from an scene to another, relying on them being couples them (note that it is very easy to break the code by modifying the scenes, i.e. it is fragile), so it might be better to use signals.
Signals, however are one way messages. A node can send information to other nodes using signals, but not get a reply. In fact there might not be nodes listening to the signal.
Thus, when a Node needs information from other nodes, it is better to call methods on them. And how does it find the other nodes? It need to query the scene tree.
- It is convenient to use the children, since that makes it easier to bundle them together in a scene.
- However another option is use a
NodePath property (for an example of this see the RemoteTransform class).
- It is also possible to use node groups. However nothing in Godot use them by default.
The other side of the question is this: If a Node needs information from other Nodes, why make them separate Nodes to begin with? And the answer to that is polymorphism and specialization: The other Nodes can be of different classes, that can be extended independently.
For a classic OO example: A car needs wheels to work, but not to exist. And the wheels can exist without being part of a car. So you make the car have an aggregation of wheels. The wheels are children of the car. Plus you can change the wheels of the car, and create different kinds of specialized wheels without having to redesign the car.
