duplicate(15) error `Condition "!common_parent" is true. Returning: NodePath()` on removed (not free

[molten sun]

Script:

class_name DuplicatingTemplateTest
extends VBoxContainer

#-- private variables:
var _template : Control

#-- _ready:
func _ready() -> void:
    _template = $template
    remove_child(_template)

#-- signal handlers:            func _on_()

func _on_duplicator_pressed() -> void:
    var instance := _template.duplicate()
    add_child(instance)


func _on_template_pressed() -> void:
    print("PRESSED")

if template has no signal or is not removed in _ready(), then the error doesn't appear.

just making the template invisible is a workaround, but iterating/managing children becomes difficult. A way around this would be to make the template internal, but that's not possible from the editor.

Overcame the above issue in ready() with

    remove_child(_template)
    add_child(_template, false, Node.INTERNAL_MODE_BACK)
    _template.visible = false

[zealous tangle]

so your error is on this line:

var instance := _template.duplicate()
add_child(instance)
``` ?

[molten sun]

yes it's exactly the call to duplicate() that produces the error

[zealous tangle]

maybe removing the owner after removing the child?

[molten sun]

ah.. I never tried that

what about the solution above though?

[zealous tangle]

remove_child(_template)
_template.owner = null

...
var instance = _template.duplicate(7)
add_child(instance)

[zealous tangle]

no idea why would you want to add it as an internal node

even that, if is just a single node with certain properties, you can remove that node and make it its own scene, and instance that scene instead

[molten sun]

alas this approach still creates the error

[zealous tangle]

can you paste the traceback, please?

I want to see in source what is causing it

[molten sun]

so it doesn't appear in $VBoxContainer.get_children()

[molten sun]

E 0:00:01:0863 VBoxContainer.gd:18 @ _on_duplicator_pressed(): Condition "!common_parent" is true. Returning: NodePath()
<C++ Source> scene/main/node.cpp:1713 @ get_path_to()
<Stack Trace> VBoxContainer.gd:18 @ _on_duplicator_pressed()

[zealous tangle]

brb

very weird error

[zealous tangle]

ah then it makes sense to have it as internal node

[molten sun]

I know! my reaction too 😉

[molten sun]

that's interesting I also never thought about this

although in my case templates are their own scene

[zealous tangle]

it seems like, somehow, the parent can't determine the parent to the added duplicated child

[zealous tangle]

that simplifies everything then, just having them as packedscenes instead of nodes also can save resources

[zealous tangle]

maybe you can file an issue about that?

[molten sun]

yes. On that topic, I was wondering if it is possible to preload a resource that a NodePath points to (an exported variable)

[molten sun]

I wasn't sure it was a legitimate error, I always think I'm in the wrong first 😉

[zealous tangle]

resources and nodepaths are different things

[zealous tangle]

it is not and error, a maintainer can explain better what is happening and close the issue

but if it is, maybe can solve future related issues

[zealous tangle]

so i'm not totally sure what are you trying to do, instancing under certain path, maybe?

[molten sun]

sure thing, yet I also use the scene_file_path property to Nodes to load() a template. I realized everything was known at compile time, and then wondering if there was a shortcut.

[zealous tangle]

you still want to have nodes in scene to duplicate them

[molten sun]

essentially I want the template to be set as a NodePath in the Editor. I found it better than relying on a predefined name (such as "template") of the node in the scene.

[molten sun]

I just want a template, preferably as a scene - but support simple Control too - and instantiate that. The issue I have with scene instantiation is that signals set in the Editor have to be re-created in code.

and so that creates maintenance issues.

[zealous tangle]

but what is the difference between having it as a PackedScene an directly having it in scene?

[molten sun]

I don't know, I've never thought about it.

[zealous tangle]

personally i found easier having it as a packedscene in a variable

if multiple scenes are needed, you can have multiple variables or an array/dictionary holding them

[molten sun]

so far the issue for me was to keep the template' signal connections defined in the Editor for the instances. I did not manage to do that easily when instantiating the scene.

[zealous tangle]

the templates shares the same signals?

or they will have different signals?

are they going to be emmited to the same method?

[molten sun]

nope I mean the instances of the template shall have the same connections as the template.
Although having multiple templates should remain possible

[molten sun]

yes

essentially the signals are used as an interface

[zealous tangle]

If they all are going to be connected to the same method, using the same signal, you can just do this

var instance = <PackedScene>.instance()
instance.<Signal>.connect(<custom_method>)
add_child(instance)

note that names bound with <> are meant to be replaced with yours

[molten sun]

the goal was to let signal connections be defined in the editor, not to force them through the code.

case in point: not all templates use all signals.

[zealous tangle]

I see, that's why you want them to be nodes in editor

[molten sun]

yes.

I really appreciate that you take the time to understand the situation. Thanks a lot

[zealous tangle]

Hope you can find a solution, I can't think about one at this moment that is not code-wise