You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Beware that resource files (.tres/.res) will store the path of the script they use in the file. When loaded, they will fetch and load this script as an extension of their type. This means that trying to assign a subclass, i.e. an inner class of a script (such as using the class keyword in GDScript) won't work. Godot will not serialize the custom properties on the script subclass properly.
This necessitates creating separate files for every data class you use, which is inconvenient.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Do (de)serialize inner classes, allowing them to be saved and used in RPC calls.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
I'm not an expert and i'm not sure how exactly to fix this, but i imagine the first step would be to actually populate .resource_path of inner class objects.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Yes, but it's inconvenient and it's the proposal's full intent to eliminate the need for this workaround.
Is there a reason why this should be core and not an add-on in the asset library?
Godot's (de)serialization mechanism is not extensible, AFAIK.
The text was updated successfully, but these errors were encountered:
I think it doesn't work now because there is no unified type representation (as first class types or at least as strings). In addition to inner classes, there are built-in scripts and scripts created on the fly. I proposed the following version of FQTN (fully qualified type names):
Special types Variant, Nil, void.
Built-in or Variant types (int, Vector2, Array, etc.).
ClassDB types (Object, Node, etc.).
Global script classes. Must be unique for all languages. Namespaces are possible, in which case some separator is used (., :: or something else).
Unnamed script classes in the res:// file system (like "res://script.gd").
Scripts created on the fly (like "gdscript://12345"). The protocol defines the scripting language, followed by the script instance id.
Enumerations, inner classes and structures use .. For example GlobalClass.InnerClass or "res://script.gd".InnerClass.MyEnum.
Parameterized types use []. For example Array[int] or "Dictionary[Node, "gdscript://12345".InnerClass].
Describe the project you are working on
A heavily networked game
Describe the problem or limitation you are having in your project
As noted at the bottom of https://docs.godotengine.org/en/latest/tutorials/scripting/resources.html:
This necessitates creating separate files for every data class you use, which is inconvenient.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Do (de)serialize inner classes, allowing them to be saved and used in RPC calls.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
I'm not an expert and i'm not sure how exactly to fix this, but i imagine the first step would be to actually populate
.resource_path
of inner class objects.If this enhancement will not be used often, can it be worked around with a few lines of script?
Yes, but it's inconvenient and it's the proposal's full intent to eliminate the need for this workaround.
Is there a reason why this should be core and not an add-on in the asset library?
Godot's (de)serialization mechanism is not extensible, AFAIK.
The text was updated successfully, but these errors were encountered: