Add export_resource_uid annotation

[huwpascoe]

Resource UIDs can now be selected from the inspector in the same way a Resource would be selected.

EditorResourcePicker has new path_only property to facilitate the annotation that hides menu items unrelated to UID selection.

Example usage:

@export_resource_uid("ResourceTypeName") var item: String

func load_item() -> ResourceTypeName:
	return load(item)

Closes godotengine/godot-proposals#9216
Closes godotengine/godot-proposals#9552

[tokengamedev]

in my point of view @export_uid makes more sense than @export_resource_uid. This is up to the reviewer to decide, as I am not fully aware of the context.

[huwpascoe]

in my point of view @export_uid makes more sense

I had considered that name, went with the longer one because it gives a "use me sparingly" feeling and I don't know if other uid might be used in future.

[dalexeev]

Note that you could use @export_custom(PROPERTY_HINT_RESOURCE_UID, "Type") instead of @export_resource_uid("Type"). You could also add a test, see export_variable.gd.

[Summersay415]

Can this annotation also be used with String type? I think UIDs as String are more common, and it will be easier to use in code (no need to ResourceUID.get_id_path)

[huwpascoe]

Can this annotation also be used with String type?

My dumb c++ brain shrieks "wasteful!" at an extra string allocation/conversion, but what do the maintainers think? @Calinou @AThousandShips

[AThousandShips]

The allocation isn't necessarily an issue, but if we use a String it'd be very much like the existing path property hints, but simply using an UID instead, but still lacking any UID pairing and updating features like the existing resource system has, which feels half baked, see for example #87418 (comment)

So I'm unsure either way here, having just a convenient way to fetch the path as an UID instead of a file path is useful, but I'm not sure it warrants a whole new property hint

Also we could have this hint support both int and String and just mean "fetch the path, which must be in res:// as an UID"

[huwpascoe]

The allocation isn't necessarily an issue, but if we use a String it'd be very much like the existing path property hints, but simply using an UID instead, but still lacking any UID pairing and updating features like the existing resource system has, which feels half baked, see for example 87418

After reading that issue, it seems UID in general is half-baked? In that thread people are saying "use both" which entirely defeats the purpose of it right? I wanted this feature because @export_file is just a string, that breaks the moment anything is moved. But if UID can't be trusted either then what other options are there...

[AThousandShips]

After reading that issue, it seems UID in general is half-baked? In that thread people are saying "use both" which entirely defeats the purpose of it right?

Not really IMO, UIDs are safe generally, but there are contexts where they might be reset, they shouldn't but they might be, and being able to fall back on the other path is very useful and powerful, it can be trusted generally, but both together is the best

[huwpascoe]

That's good at least.

About making this a "fully baked" solution, it's not possible. Not without rewriting large sections of core/io.

[simo498]

Note that you could use @export_custom(PROPERTY_HINT_RESOURCE_UID, "Type") instead of @export_resource_uid("Type"). You could also add a test, see export_variable.gd.

As i saw the default custom export with the PROPERTY_HINT_RESOURCE_UID does not support creating arrays of UIDs, and it could still be convenient to have a "discoverable" way of doing that, since some hints are a bit hidden by the code suggestion menu

[huwpascoe]

Everything is "uid://" String now to keep things simple.
Array types are supported. (turns out this happens automatically)

This PR is now complete as possible. Would be nice if it can be merged for 4.3.

[AThousandShips]

We're in feature freeze so this might have to wait for 4.4