Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(De)serialize inner classes' properties #11658

Open
elenakrittik opened this issue Jan 28, 2025 · 1 comment
Open

(De)serialize inner classes' properties #11658

elenakrittik opened this issue Jan 28, 2025 · 1 comment

Comments

@elenakrittik
Copy link

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:

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.

@dalexeev
Copy link
Member

dalexeev commented Jan 28, 2025

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].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants