Godot: Custom-made resource types cannot be used in export statement

[MutantOctopus]

Operating system or device - Godot version:
Windows 10 - Godot 2.1 Stable

Issue description (what happened, and what was expected):
Created a custom resource type as a plugin and attempted to export(CustomResource), which raises error(17,7): Export hint not a type or resource.

Steps to reproduce:
Create a plugin which defines a custom resource type. add_custom_type like the plugins tutorial shows (Specifically, add_custom_type("Name", "Resource", preload("plugin_source.gd"), preload("icon.png"))). The new type will appear in the "create resource" menu, but attempting to export(CustomResourceName) will raise the error.

Link to minimal example project:
Custom Resource (2.1s).zip

[MutantOctopus]

Offhand, I attempted to make a custom resource in order to create a custom color palette for a practice tetris game. If there's an easier way to make a centralized reference to a set of colors for the I-block, T-block, etc, please tell me.

[bojidar-bg]

Moving to topic:gdscript, since it is only impossible to export it, but it is totally possible to use it in other ways.

[MutantOctopus]

Yeah, after a while I realized I could just export(Resource), but it still seems like it could be prone to flaws.

[ghost]

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

[ghost]

Is this fixed by #16995?

[MutantOctopus]

Sorry for the delay, myself. I can't check whether this was fixed at this exact moment, but I'll take a crack at it first thing in the morning - it seems like the old 2.1 project should be able to be copied over with minimal edits to test it, anyway.

[MutantOctopus]

For the sake of posterity I checked to ensure that the problem wasn't already solved in v3.0.2.stable.official - it's not. Attempting to export(CustomResource) raises an error "Expected a constant expression", and trying to export(Resource) does not put the custom resource in the drop-down menu. However, the custom resource does appear in the "create resource" menu, can be saved, and can be manually slotted in from a saved tres.

I'll be building a version of the editor from the commit of the linked PR soon and replicating my efforts there to see what happens.

[vnen]

Related to #17387.

I don't think this is solved by #16995, since that only touches the editor.

[MutantOctopus]

Yeah, I was thinking the same thing, @vnen. While #16995 gives a (fairly unintuitive) workaround to the problem (via overloading _get_property_list()), it doesn't appear to solve this exact issue as written. Still, it never hurts to check, I'll report back once I have a build ready.

[MutantOctopus]

@Noshyaar - Having built a version of Godot from the master branch (ID'd as v3.1.dev.custom_build.d87307d) I can confirm that this issue does not appear to have a direct solution.

With a custom resource type named Test, attempting to export(Test) yields the error I mentioned earlier: "Expected a constant expression". export(Resource) allows for you to pick New Test from the list, but given that the basis of this issue is that a user should be able to specify a specific resource type for their variable (such as export(Curve) or export(Texture)), I wouldn't call that a solution.

In the process of testing, I think I've found a pretty significant bug. When I create a baseline variable, export(Curve) var test_control = null, I am allowed to select a New Test as well as simply a New Curve. This is definitely problematic, seeing as that Test is defined to only extend Resource and decidedly cannot be used as a Curve.

The "filter with hint_string in _get_property_list()" as mentioned in #16995 is really non-obvious. I basically have no idea what that means. The documentation for _get_property_list() doesn't really tell exactly what the function is doing or how to use it, and it seems like an awfully convoluted way to solve this problem anyhow. When I tried to use _get_property_list() to override the details of a variable and give it a hint string of "Test", nothing changed except that printing every element of get_property_list() (no underscore) added an additional qux entry on the end, without modifying the one that was there.

I'm attaching my test project in full for posterity. The test_scene.tscn file contains a single node, with a script that has a few attempts to export variables in a few different ways. The custom Test resource can be created through the "create resource" dialog in the inspector, and in the master build can be added through the "new resource" dialog on an object, even when the resource in question is not a generic resource (such as the Control Test property on the scene's single node).

Custom Resource (Fix Test) (3.0.2).zip

[MutantOctopus]

In hindsight, since I doubt that it would be easy to make the export statement accept custom resource types normally (as in export(Custom)), maybe a better solution is to have a specific case for export: export(Custom, "ResourceTypeName"), and then have the engine search through custom plugin types which extend Resource or some other Resource type. If it's in the list, limit the drop-down results to that type, and if not, raise a warning in the editor; until there's a type which can fill the slot, make null the only option (because you can't create a new X until you have an X template).

[EmeraldSlash]

It doesn't happen just for custom resource types, it errors for all types. The issue is still happening of course.

[bojidar-bg]

Currently, you cannot export variables of type Node, as it is not a primitive or resource type. Try NodePath or String.

[MutantOctopus]

@EmeraldSlash I think you might be commenting on the wrong issue?

[EmeraldSlash]

@MutantOctopus What do you mean? This is the only issue on this topic I believe, and the only difference between mine and the thread's issue would have been which specific type of objects (custom & built-in) were not allowed. It's also no longer an issue for me because of what bojiday-bg said.

[somnivore]

Games which are data-heavy (such as RPGs) would benefit immensely from better support for user-defined resources; there is a great deal of convenience in being able to see and modify game data in-engine via the FileSystem and Inspector, and being able to create, save and load this data without having to go through a parser. Thanks to the new class_name functionality, it is possible to create a user-defined resource easily from the 'Create New Resource' menu, but exporting these resources is unfortunately still not supported as of f50dd682f6a0f9506daaf16fed06f4bc9efa6599

[williamd1k0]

Sorry for the bump, I just found this issue after commenting about it here: https://github.com/godotengine/godot/issues/3597#issuecomment-425670625

@somnivore Thanks to the new class_name functionality, it is possible to create a user-defined resource easily from the 'Create New Resource' menu, but exporting these resources is unfortunately still not supported as of f50dd68

Yeah, supporting custom resource types in exported variables will greatly improve the custom resource workflow. It would be nice to see this implemented yet for 3.1

[ClementRivaille]

It seems that this behavior is still present in 3.1.1. However, it might get fixed by #26162. I've been running some tests on this branch, and you can use custom resources directly with their classes, using class_name in the resource script.

export(CustomResource) var sample

But there is still one bug mentioned above that can be reproduced. If I write:

export(Curve) var curve

I still get CustomResource (on top of Curve) displayed in the editor's drop-down. Basically, this means that any custom type added will appear on every exported resources. Which at best can be inconvenient, at worst could easily lead to errors.

Anyway, for those who need custom resources, exporting a different type of resource is still the best workaround I've found. Not pretty (especially when writing a plugin), but at least it allows to select the custom resource from the editor (… by exploiting a glitch) without listing all resources.

[Jeto143]

@ClementRivaille Can you elaborate on "exporting a different type of resource is still the best workaround I've found"? Not sure to follow.

Thanks.

[ClementRivaille]

Let's say I want an exported CustomResource property in one of my script. Right now, I can legitimately only do that with:

export(Resource) var custom

And then select CustomResource in the very long list of resources.
But if I write this instead:

export(Curve) var custom

When I try to set it in the editor, I obtain:

Which is incorrect! I should only have Curve in the list! Buuut… it lets me easily select CustomResource, which is what I want.

This is 100% a hack, and not a viable long term solution! It might even stop working once this issue is fixed.
But in the meanwhile, it allows at least to use custom resources and move on. We can even write export(Curve) in the script just to create the resource in the editor, then change it to export(Resource) once it's done (the created resource will still be in the scene, everything works, and the code remains consistent). Not a great solution, but that might do for some projects, until we have a fix.

[Jeto143]

Could this make it to 4.0? This has been asked in 2016, and the amount of thumbs up speaks for itself.

This would be really nice to have, and I doubt it's a massive change to make.

[Calinou]

@Jeto143 Yes, it's planned for 4.0.

Anyway, I'll close this in favor of https://github.com/godotengine/godot-proposals/issues/18, as feature proposals are now tracked in the Godot proposals repository.