Shouldn't add_child() set the owner? #4047
Replies: 3 comments 8 replies
-
I suppose that ideally you'd want more control on what the The proposed default may not work well with, for example, a scripted Node that generates more Nodes at runtime. In this case, if you need to pack this Node, the generated Nodes would not be packed along with it, because the It's also worth noting that Nodes have no idea they're being packed and saved. It's mostly up to however this is accomplished. All each Node has to do is essentially minding their own children's business. Having themselves set their own owner to something way higher in the hierarchy would somewhat break that. So, once more, I suppose the most neutral option is to default the |
Beta Was this translation helpful? Give feedback.
-
The problem is, owner does some things under the hood (including showing the node in editor scene tree and saving it to disk). I have several games where the level is procedurally constructed. With the proposed default, I would have to queue_free() a ton of nodes before doing the generation, because all the previously created nodes would be saved by the editor. Either the default should be overriddable somehow to preserve the current status quo, or the show in tree/save behavior should be somehow decoupled from owner... |
Beta Was this translation helpful? Give feedback.
-
I did some test for mechanics of Godot (only about tool mode and editor manipulating), and found some inconvenience in isolated owner setting. Consider a node connecting and disconnecting a function to a signal of its owner, this node listens to owner's data changing event, and usually not the direct child of its owner. Connections done in the owner node's Scene LoadingOwner is set in the scene file, so when initializing the scene, every node can get its owner early at So owner's accessibility in scene loading is:
Adding new node or modifying treeOwner's accessibility in dynamically adding is:
Switching current editing sceneSo I just add a connection after a frame, and disconnect in exiting tree(this is necessary to avoid redundant connecting when modifying tree structure). Switching editing session just remove the entire tree from Editor's sub-view's root, so there is not a node initializing procedure, only _enter_tree and _exit_tree are called. So the only alternative is calling a deferred callable in _enter_tree to connect, and disconnecting in _exit_tree. It functions buggy, because the asynchronous frame is lazy, the frame only refresh when you focus the scene canvas view or the scene tree dock(or other docks), so if you just open a scene, then open another without any editing, the previous scene will not call the deferred connection and executes _exit_tree, causing a null disconnecting. Of course I can use |
Beta Was this translation helpful? Give feedback.
-
I feel like if it did mimic the owner of the node it is being added to, it would severely streamline saving packed scenes through code and uphold the logical structure of the scenes made in the editor.
Is there any reason why that is not a case?
Beta Was this translation helpful? Give feedback.
All reactions