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