Godot: SubClass as Custom types for export

[LeonardMeagher2]

It'd be nice to be able to export a SubClass as a type of export and if you'd go into it and the exported variables from it would be accessible in the editor.

Related, #3586, is requesting Typed Arrays from gdscript, which I'd also like to see SubClasses show up there.

class a():
    export var b = 0
    func _init(in):
        b = in

export(a) var custom_export
# export(array,a) var custom_export_array

[Zylann]

I agree, I'm currently unable to encapsulate data from an exported variable because I cannot make it a class.
This is what I have, as typical example:

tool
extends Node

const Grid = preload("addons/terrain/array2d.gd")

# Error: export hint is not a type or resource
export(Grid) var save = null

func _ready():
    save = Grid.create(8,5,1)

Godot complains the type is not a resource, but mine actually inherit Resource. And anyways, I don't necessarily want it to be a Resource.
So everywhere in my code, I use an array of arrays with C-like helpers...

[vnen]

There's a bit of a problem here: how will the inspector know how to handle the export? For built-in types there's code to handle each type and for resources there's the ResourceLoader to know which file types can have the resource.

This should work with custom resources made by plugins (maybe it already does, as I haven't tested).

[Zylann]

Well, in my case the problem actually resides in saving, not in displaying the class in the inspector. If the inspector has no editor for that, it should simply ignore it or display nothing (like Dictionaries), thought a bit of reflection could help making a generic editor.
The fact that saved variables must be either an engine type or a resource is weird, there is no in-between, and it impacts the whole codebase behind it.

[vnen]

It's not "weird", it's just the way it was designed. Of course it can be improved and it's mostly matter of how (hence my previous questioning). So far everybody lived with it this way.

I don't like the idea of making export ignore custom types, since it's not what the user would expect and it would be frustrating.

Also, don't think there's a default serialization for generic objects. That's another issue, but it would be required to save any kind of object in a PackedScene resource file.

[bojidar-bg]

Well, we can have subclasses export variables as well, can't we?

[williamd1k0]

@vnen This should work with custom resources made by plugins (maybe it already does, as I haven't tested).

I don't know about plugins but it's not working for simple custom resources.
I'm interested in this feature because of the new class_name keyword.

Now you can create a custom resource and expose it globally but you can't export it by its type, only using the Resource type.

Example

• Creating a custom resource:

extends Resource
class_name CustomResource, "optional-icon.png" # 3.1

export(String) var some_data

---

• Trying to export it (3.1):

extends Node

export(CustomResource) var custom_res

This will show the following error: Parse Error: Expected a constant expression.

---

• Trying to export it pre-loading the script:

extends Node

const CustomResource = preload('res://CustomResource.gd')
export(CustomResource) var custom_res

This will show the following error: Parse Error: Export hint not a resource type.

---

This issue is a bit old but exporting custom resources would be really useful for 3.1.

[twheys]

Would love to see this feature added. I imagine if the exported class is though of as a collection of types the Editor knows how to handle, I don't see why it couldn't behave the same way properties are set on built-in complex types in the Inspector.

For example, a Spatial is shown in the editor as a list of Transform, Matrix, and Visibility, each which can be expanded and have their own set of attributes. I would love to be able to create my own settings like this.

Ultimately, I believe it should be entirely feasible to generalize the Inspector so a tree structure can be used.

[bojidar-bg]

@twheys That would be #4378, since Transform, Matrix, and Visibility are not actual objects.

[Shadowblitz16]

+1
I just ran into this issue.
I think it would also be useful to export specific resources.
it would be really good for data oriented design specifically for non programmers.

[Calinou]

@Shadowblitz16 Please don't bump issues without contributing significant new information; use the :+1: reaction button on the first post instead.

[akien-mga]

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!