get_child error when duplicating .GLB model nodes with animations

[retexcraft]

Tested versions

reproducible in 4.3 stable
not reproducible in 4.2 stable
not tested in other builds

System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1070 (NVIDIA; 31.0.15.5161) - Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz (8 Threads)

Issue description

when attempting to duplicate() a GLB node with animations under its animation player it is unable to understand the children and produces this error

E 0:00:00:0862   node_3d.gd:5 @ _ready(): Index p_index = 1 is out of bounds ((int)data.children_cache.size() = 1).
  <C++ Source>   scene/main/node.cpp:1688 @ get_child()
  <Stack Trace>  node_3d.gd:5 @ _ready()

that also causes the next error in the debugger

E 0:00:00:0863   node_3d.gd:5 @ _ready(): Child node disappeared while duplicating.
  <C++ Error>    Parameter "copy_child" is null.
  <C++ Source>   scene/main/node.cpp:2926 @ _duplicate_properties()
  <Stack Trace>  node_3d.gd:5 @ _ready()

Steps to reproduce

import a .GLB model with a animation into a scene and call the duplicate function on it

Minimal reproduction project (MRP)

glb-duplicate-test.zip

[matheusmdx]

Bisecting points to #91677 as the culprit, @KoBeWi

This looks not related to animation, but a problem with internal nodes, while duplicating this part discards the Skeleton3D internal node for the new node:

godot/scene/main/node.cpp

Lines 2715 to 2722 in 61598c5

	for (List<const Node *>::Element *N = node_tree.front(); N; N = N->next()) {
	for (int i = 0; i < N->get()->get_child_count(); ++i) {
	Node *descendant = N->get()->get_child(i);
	if (!descendant->get_owner()) {
	continue; // Internal nodes or nodes added by scripts.
	}

Which results in a difference in child count here, p_original has two childs (the internal bone node and the cube) while p_copy has one (the cube):

godot/scene/main/node.cpp

Lines 2954 to 2958 in 61598c5

	for (int i = 0; i < p_original->get_child_count(); i++) {
	Node *copy_child = p_copy->get_child(i);
	ERR_FAIL_NULL_MSG(copy_child, "Child node disappeared while duplicating.");
	_duplicate_properties(p_root, p_original->get_child(i), copy_child, p_flags);
	}

Commenting line 2720 preserves the internal node and stop the error but probably is not the correct fix, but at least give some idea what's going on

[KoBeWi]

Bisecting points to #91677 as the culprit

#91677 only added a null check. The MRP crashes otherwise.

[matheusmdx]

Bisecting points to #91677 as the culprit

#91677 only added a null check. The MRP crashes otherwise.

[RebelliousX]

I am having a similar issue which is driving me nuts. It happens only when I do CTRL+D for a specific node.

That node2d has a notification to listen to transform position change notification in editor mode (position change in grid cell size 64 pixels). And when that happens, I call a function to do somethings like delete children and recreate them based on some other calculations where the node2d moved in the scene relative to other objects.

I tried setting owner to EditorInterface.get_edited_scene_root() but it complains that it is null during the editor startup with hundreds or thousands of repeated errors matching the number of objects I have. And the added child is stuck at position (0, 0) even when I specifically set its global position prior adding it.

I tried call_deffered when adding child, calling deferred the function from notification that respond to position changes. Same thing.

Edit: The custom node2d I have works fine in editor or in game. It is just this error message. I probably should ignore it, but I am the type that these things can bother me 😖

Running 4.4 beta 2.

Does #89442 fix the issue? and if yes, will it be merged any time soon? it has been almost a year.

[matheusmdx]

Does #89442 fix the issue?

The error looks the same from the issue, so probably yes.

will it be merged any time soon?

For now the pr don't have any specific date to be merged, is marked to be merged at some point in the 4.4 cycle. What you can do while the pr isn't merged is compile from source cherry-picking the cited pr on top, so you can have a binary with this fix applied.

[RebelliousX]

@matheusmdx Thanks. I was able to work around the issue. I don't get that error anymore.

Before, I had an empty Node2D inside the game object scene, I used it to add children into it in editor mode (tool keyword).
And in the script to handle changes to suit my needs, I had to queue_free() these objects and recreate them again with
different properties and positions.

I was thinking it is a nice way to organize everything instead of seeing all these children created and appear in scene tree
if I set the owner. But that caused the problem, at least part of it.
 
So, two things caused the problem, at least for me:

• Having an empty Node2D in the game object scene, and
• queue_free all children inside that Node2D indiscriminately.

What I had to do, I compared the type of each child object added to the main game object scene (not the sub-Node2D)
with the ones I am sure I added. And I tested and did some debug prints to verify the number of objects freed is exactly
the number added.

func remove_existing_shaft_pieces() -> void:
	# using the following method of removing the children will throw error
	# in the debug output about child disappearing ( lol ) while being duplicated
	# ----------
	#for child in $ShaftParts.get_children(true):
		#child.queue_free()
	# ----------
	
	# But, doing it this way, does not!
	for child in get_children(true):
		if (child is GameObject):
			var object_type: Constants.ObjectType = child.get_object_type()
			if (object_type == Constants.ObjectType.ELEVATOR_BIG or 
					object_type == Constants.ObjectType.ELEVATOR_SMALL):
				child.queue_free()
				#print("queue_free() shaft piece..")
	return

[wagnerfs]

I remember I had to compile from source and rollback the changes from 4.2 to 4.3, but I feel like the main problem is the whole owner, when you manually create nodes (or duplicate I believe) you have to manually set the owner for subsequent duplications to work without failing I think.