Shouldn't add_child() set the owner?

[SilencedPerson]

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?

[Mickeon]

I feel like if it did mimic the owner of the Node it is being added to...

I suppose that ideally you'd want more control on what the owner actually is.

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 owner is not the Node that added them, which may not actually be desirable.
On the other hand, packing this Node's very parent and leaving those generated Nodes inside may also not be desirable, and highly unexpected.

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 owner to null and let the script decide what else to do with the added children.

[SilencedPerson]

So, once more, I suppose the most neutral option is to default the owner to null and let the script decide what else to do with the added children.

That is the current behavior. My logic is that if you need to add node to a scene, the child mimics the node it is added to.
Here is an example: Player emits signal to spawn bullet, Game is connected to this signal and adds child to the World.

Current Behavior:

Game
┖ World (owner = Game)
.....┖ Player (owner = Game)
.....┖ BulletInScene (owner = Game)
.....┖ BulletAddedThroughCode (owner = null)

owner of the bullet added through code is null.

After Change:

Game
┖ World (owner = Game)
.....┖ Player (owner = Game)
.....┖ BulletInScene (owner = Game)
.....┖ BulletAddedThroughCode (owner = Game)

owner of the bullet added through code is Game because the parent (World) is also owned by Game.

Scenes constructed by editor are setup like this, scenes constructed by code should be same. If you need to explicitly override the owner , you will have to do it manually.

Note: Multiline code block doesn't seem to work here.

[azur-wolve]

After looking at your hierarchy structure, are you not sure that the owner of Player, BulletScene and BulletCode isn't World instead?
Also there's a distinction if they're Scenes or Nodes.

[SilencedPerson]

Give it a try in the editor. I am 100% correct. You are thinking of a parent. Owner is root of a scene.

[azur-wolve]

Ah now I get it.
By owner, its meaning is the owner of the data on memory (I guess)

[SilencedPerson]

I am referring to this owner.

[Zireael07]

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...

[SilencedPerson]

Best solution would probably be to add separate function:
node.add_owned_child(child)
That way both behaviors are preserved and there is no need for special argument.

[qt911025]

Best solution would probably be to add separate function: node.add_owned_child(child) That way both behaviors are preserved and there is no need for special argument.

owner in many case is not just a node's parent node, so I suggest just adding a parameter, like:
func add_child(node: Node, force_readable_name: bool = false, internal: InternalMode = 0, owner: Node = null) -> void

[Mickeon]

There's suggestions out there for adding more parameters in add_child out there.

The pros and cons always boil down to:

• Saves only one line of code (added_node.owner = this_node)
• Makes the method's signature and the surrounding code harder to read (which is something Godot & GDScript try to avoid like the plague).

[qt911025]

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
"child_entered_tree" signal callback or corresponding notification can only detect direct child's entering, so I do the connecting in the adding child's lifecycle hook.
However, the owner getting is different in many situations. There is about 3 situations:

Scene Loading

Owner is set in the scene file, so when initializing the scene, every node can get its owner early at _enter_tree(). It can't be done in script implementation because _enter_tree just happened after parent node's add_child(), and set_owner() can't set to a node that isn't its ancestor.
In tool mode, owner is set internally after a asynchronous loop. If setting owner manually right after add_child(), it's synchronously but still happens after adding node's _ready().

So owner's accessibility in scene loading is:

	can get owner
_enter_tree	yes
_ready	yes
After a frame	yes
_exit_tree	yes

Adding new node or modifying tree

Owner's accessibility in dynamically adding is:

	can get owner
_enter_tree	no
_ready	no
After a frame	yes
_exit_tree	yes

Switching current editing scene

So 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 EditorInterface.get_edited_scene_root(), but what is owner for?