Plugins cannot register their own ResourceFormatLoader

[Zylann]

Godot 3.0.2 stable

It's currently not possible for a plugin to register a custom ResourceFormatLoader. As a result, GDScript and GDNative plugins are unable to register their own kinds of resources without using the default .tres and .res formats.

I need this for my terrain plugin in order to have more control over the way data gets loaded and saved.

[jkb0o]

It isn't the same, but you can make EditorImportPlugin that hanle custom resource and saves original data in .import folder. I use this approach for handling Spine types (json/skel/atlas) and this works fine. I'm also not sure how ResourceFormatLoader should handle type collisions - json common format for storing different resources for example.

[Zylann]

It's indeed a different thing, it would not solve my use case since it's not something I need at import, but on load and save.

[Zylann]

I also realized that due to this, it's also impossible for a plugin to register its own saving progress. If you use Ctrl+S but your custom resource uses a thread or multiple steps to save, you need a way to notify these steps to the editor with a progress bar. Just having a callback that has to complete immediately only in EditorPlugin is very inconvenient, because you need to search all your custom resources by parsing the scene tree, and freeze the editor to save all of them using the CPU only.

[Zylann]

Some questions about how to expose this functionality:

I had a look at the C++ code and an issue is, ResourceFormatSaver/Loader are bare classes, they don't inherit Reference. They also are also stored in global variables and registered into a singleton on module registration which is also itself not inheriting anything. They are freed in module unregistration.
So I would need to make them inherit Reference, so that we can expose the API to scripts.
An alternative would be to duplicate the current API just so that it can be exposed to scripts, but it sounds quite dirty...

Another thing: should it be something exposed in EditorPlugin? Or somewhere else?
I ask this because I've been using EditorPlugin to also register editor GUIs, and this makes no sense in an exported game (as well as exporting assets of the editors!).
I could probably use Engine.is_editor_hint(), but is EditorPlugin even available in an exported binary? I think that could be another issue to raise.

And yet another thing:
ResourceFormatLoader has functions like get_resource_type returning a String. However that's not enough for a custom resource, since its type is not in the class DB. Would this be a problem?

[rainerdeyke]

Came here to post this as a new issue.

The documentation of ResourceFormatLoader outright states, and I quote, "Extending this class allows you to define your own loader.". However, right now this is only true for Godot modules. It doesn't work for GDScript, and it doesn't even work in GDNative. Until this issue is resolved, perhaps it would be best to make a note in the documentation about this limitation.

[Zylann]

Oh, actually this issue has been solved by #19501, hasn't it?

As the doc says, you can now do this by extending the said class, with the tool keyword, but ALSO you need to give it a class_name so that Godot will be able to register it.
See https://github.com/Zylann/godot_heightmap_plugin/blob/master/addons/zylann.hterrain/hterrain_resource_loader.gd

I don't know about GDNative but I'm sure it worked there before.

[rainerdeyke]

I haven't tested GDScript in depth, but this clearly does not work in GDNative. ResourceLoader::add_custom_loaders() is called just once in Main::start, before any GDNative libraries are loaded, so the custom resource loaders do not exist yet when it is called. And I can't manually register a resource format loader because ResourceLoader::add_resource_format_loader and friends are not exposed to the scripting interface.

[Zylann]

@rainerdeyke either we need to fetch the custom loaders from a lib when it's loaded, or change the time at which add_custom_loaders is called (although it can be tricky since it has to happen very early, before scene resources get loaded), or register GDNative libs earlier so we can load the native scripts when they are needed. This is if you want to use the NativeScript API, that is, the script API. Or, have a GDNative-specific API allowing more direct access to this system (which I thought existed before? But apparently doesnt?)

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

[Zylann]

This was solved already, however there seems to be an issue for GDNative to use the system.