Editor Keyword to Filter Nodes in Resource Exports

[hyo-png]

Like this

extends Resource

@export var area_node: NodePath("Node3D")

[AThousandShips]

NodePaths aren't generally supported for resources, they'd only really be useful for accessing data from outside the tree, what would this be used for?

Also for Node you can just use @export_node_path, but again this won't really work generally for non-Node types as they can't process a path to anything

The filter also wouldn't really work generally, as it isn't attached to any one scene, so it can't know what type any specific node is

[AThousandShips]

It wouldn't have that context everywhere though, also what would happen if you assign a path and then load it in a scene with no valid node there, how would that be handled?

Also how and where would this resource be used? How would the path be used? Why would the path be in a resource in the first place?

[hyo-png]

Yeah, that makes sense — it wouldn’t always have the scene context, and if the node didn’t exist when loaded, it’d obviously just be an invalid reference.

What I was thinking though is more about editor convenience — like using a Resource just to store node references or configuration that get resolved later by a scene script.
For example, you might have a data-driven setup where each Resource holds paths to certain nodes (say cameras, markers, or spawn points), and a manager node resolves them when the scene loads.

In that case, I don’t necessarily need it to validate the path at runtime — I just wanted a way for the editor export to filter or suggest the right types (like only showing Node3Ds) when I’m assigning them, to make setup cleaner.

[AThousandShips]

I'd say that's not a good way to handle node paths and data, a resource is designed to be shared so it shouldn't care about where it is, but node paths are entirely about where a resource is, even if it's an absolute path

That data should be on the node instead I'd say, data in resources should be general, that's what they are for

For general use of resources this would be unneeded, and it'd be confusing for people who don't know this or don't realize the path can't be used inside the resource, or won't work if put in the wrong scene, etc.

I'd suggest working out a real world use case for this and evaluate alternatives, it sounds to me like a solution trying to find a problem, or like using the wrong tool for the problem

[hyo-png]

Yeah, I see your point — putting NodePath in a Resource mixes scene-specific data with something meant to be general.
I’m thinking more about a new editor-level keyword that filters nodes in the inspector, like in Node scripts.
For example:
@export var check_points: Array[CheckPointConfig] — the Resource wouldn’t resolve nodes, a scene script would, but the editor would help avoid mistakes when assigning them.

[AThousandShips]

It would just require making the existing annotation work in resource, it doesn't require a new annotation

But what if you have two nodes using the same resource? Would the path be absolute? But how would that work if you have a scene included in another, so if you have the path be Foo/Bar which is relative to the root of your scene Foo, and then you put that scene as an instance in Baz/Bat/Foo2, how would that path even work?

What if you want it to get Foo1/Bar for Foo1 and Foo2/Bar for Foo2

IMO it would be more confusing than helpful, and again it'd be useless in the resource itself, only usable on nodes, so I'd say it makes far more sense as a property on the node

You can still use node paths in the resource, but without editor help, because it'd be wrong most of the time