Exported Nodes from a Custom Resource do not get accessed correctly

[JHDev2006]

Godot version

4.1-stable / 4.1.1-stable (most likely over versions aswell)

System information

Godot v4.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU (NVIDIA; 31.0.15.3141) - 12th Gen Intel(R) Core(TM) i7-12700H (20 Threads)

Issue description

When making a custom resource, and having an exported var of type Node, when filling out the value in the editor with any node, they are not correctly accessed.

For example (this uses an array of exported var nodes):

extends Node

@export var nodes: TESTING1
func _ready() -> void:
	for i in nodes.nodes_to_delete:
		await get_tree().create_timer(1).timeout
		print(str(i) + "is Deleted!")
		i.queue_free()

class_name TESTING1
extends Resource

@export var nodes_to_delete: Array[Node]

What happens, is that there is no crash, however when they are freed, they are not actually freed. However when printing the reference: (Node#01823918) it will say that it is a "Freed Object" and then will crash when being accessed again.

Steps to reproduce

Simply run the project, and notice how the 2 sprite 2D's do not get deleted after 1 second each, and will then crash when trying to free them again.

Minimal reproduction project

weird bug.zip

[JHDev2006]

Found out that the bug is just to do with exported nodes in resources, not just custom resources with arrays, updated.

[odecay]

Running into the same bug, version 4.1.1 mono. On linux.

[NancokPS2]

I've had a similar issue, idk if it could be related. Explained in steps so it's hopefully clearer

• Create MyResource (extends from Resource) with @export var nodeHere:Node
• Create MyNode class (extends from Node) with @export resourceHere:MyResource
• Add a MyNode to the tree from the editor and add a new MyResource in it's resourceHere property
• Attempt to set MyNode.resourceHere.nodeHere to another node already existing in the same tree, from the editor.
• During runtime, nodeHere will point to an orphan that is otherwise identical to the real thing (their debugger IDs will still be different).

Basically setting a Node reference in an export from a Resource does not actually set the right node, somehow.

[JHDev2006]

you explained it way better than i could, but thats essentially what the bug is! glad to know im not the only one

[YuriSizov]

Without looking at the engine code for now, I'd wager that the issue is rather simple and is an inherent limitation of this feature. Exported nodes is a syntactic sugar for exporting NodePaths. And NodePaths only make sense relative to another node in the scene tree. Resources are not in the scene tree, so they cannot resolve a NodePath, which means they cannot correctly get a reference to a node.

We likely should warn and prevent this use case, as it just doesn't make sense in practice.

[JHDev2006]

yea, i see what you mean. for the project that i wanted to use this in, i ended up just using the nodepath instead. Glad to know that its not meant to be used that way!

[JHDev2006]

Just been thinking about it some more, but I think the best idea ATM is to do a feature request, for this issue.

The way I think it should work is that it should get the node at ready, relative to where the node which has the resource is. Don't know how hard that would be to implement but that's how I figure it should work. Pretty sure something similar is already implemented for exporting nodepaths

[YuriSizov]

@JHDev2006 Resources don't exist in the scene tree, and they don't have a ready state. Multiple nodes can share the same resource too, as well as non-node objects, or other resources. This is not something the engine can handle, as many very specific assumptions would need to be made. You should handle it in your project instead.

[NancokPS2]

@JHDev2006 Resources don't exist in the scene tree, and they don't have a ready state. Multiple nodes can share the same resource too, as well as non-node objects, or other resources. This is not something the engine can handle, as many very specific assumptions would need to be made. You should handle it in your project instead.

So just to confirm, this means that a Resource should not be allowed to @export a node, right?
I know it would be more effort than it's worth atm. But ideally, there is no reason for them to allow nodes right?

[AThousandShips]

For the exporting of Node properties from resources, see also:

• NavigationAgent2D has no parent, if called from Resource #81224

[akien-mga]

For the record, to clarify that this is not a supported use case, this was made an error in GDScript in 4.2: #82843.

[jrockett6]

Does it make sense for this access (as a nodepath) to work for builtin resources?

I currently have a setup like:

Level extends Node

@export var waves: Array<Wave>

Wave extends Resource

@export var spawn_points: Array<Node3D>
@export var other_thing: int

but the spawn points can not be assigned via the nice node assignment interface.