@export_uid

[huwpascoe]

Thread to discuss the continuation of godotengine/godot#91815

[simo498]

@huwpascoe didn't you make a gdscript plugin for handling this?

[huwpascoe]

I did, yes.
https://github.com/huwpascoe/godot_resource_path
https://godotengine.org/asset-library/asset/3291

People are asking for it to become an engine feature.

• move
• find references
• replace references
• fast thumbnail previews

The plugin only supports move operation, and this only works fully when 4.4 adds the new .uid tracking.

To make it a full feature and work efficiently, needs core changes probably.

[simo498]

yes, it might be a starting point to make a full implementation in C++ into the engine, it should have been a core feature since the first versions

[caimantilla]

Thought it over a little more now, and I don't think that @export_uid should be a thing at all; rather, a dedicated type should be implemented, similar to NodePath, with an optional annotation named @export_node_path for type restriction, just as is the case with @export_node_path. This type could then support dependency management in the editor, and have convenient methods for loading the resource that's being pointed to.

A simple name like ResourcePath should do. It should be possible to cast freely between ResourcePath and String, or perhaps even Resource as well, along with convenient methods like ResourcePath::load and ResourcePath::exists. Furthermore, the ResourceLoader and ResourceSaver APIs should be updated to take ResourcePath as their arguments. Support for casting between ResourcePath and String should avoid compatibility breakage. The same applies for ProjectSettings. As an aside, this would make the project settings more convenient to adjust, as far as resource paths go.

[simo498]

Doesn't gdscript support generics? The type should be something like ResourceReference<T> (or whatever its name will actually be)

[caimantilla]

Doesn't gdscript support generics? The type should be something like ResourceReference<T> (or whatever its name will actually be)

Sort of, to a limited degree. It wouldn't make much sense, however; enforcing the type of something that isn't even loaded seems impossible, so it would still only be relevant to the editor, and perhaps restrict type while loading... but this anyhow isn't too useful because the return types of each method, as seen with TypedArray and TypedDictionary, are themselves stuck with what their binding defines.
So, in the end, this is basically something that's only relevant to the editor, as the user would still have to cast the type of the loaded resource.

[simo498]

I don't know if it might be useful for C# programming, we could enforce the load function to return the actual type and avoid bad type casting, like

T load()

I'm not very informed about the Godot language, isn't it possible to return something like this in gdscript?

Another option might be to separate the two implementations for strongly and non-strongly typed. For instance:

template<class T>
class ResourceReference<T> {
    UID uid; //or string path;
    T* load();
    //...
}
// or even 
// class ResourceReferenceT<T>

class ResourceReference : public ResourceReferenceT<Resource> { 
    Resource* load();
}

[huwpascoe]

This type could then support dependency management in the editor

The same implementation would be needed to make dependencies work, so either way is fine I guess?

As an aside, this would make the project settings more convenient to adjust, as far as resource paths go.

Please could you elaborate on this part? If a new type were to be accepted by core-team, it better have some obvious advantages