Replies: 2 comments 3 replies
-
Converted to a discussion as this doesn't contain the required details |
Beta Was this translation helpful? Give feedback.
3 replies
-
moved to #11636 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Describe the project you are working on
Describe the problem or limitation you are having in your project
GDExtension only allows registering integral constants, which limits the ability to define reusable complex data structures (e.g., arrays or dictionaries) as constants. This restriction complicates workflows and increases boilerplate, as runtime initialization is required for what could otherwise be declared at compile time.
https://github.com/godotengine/godot/blob/b15b24b087e792335d919fd83055f50f276fbe22/core/extension/gdextension_interface.h#L2918-L2935
godot-rust/gdext#1027
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add support for registering fields or functions to represent values that cannot currently be stored as constants, such as arrays or dictionaries. This would allow developers to define reusable configurations or presets in their code without relying on runtime initialization.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
A possible approach could be:
Allow registration of pseudo-constants using new API methods or macros. For instance:
Alternatively, introduce a mechanism like static constants initialized at runtime but treated as constants thereafter.
Enable defining static fields for classes in Rust or GDScript that can be initialized once and shared across instances:
Support defining constant-like methods that return reusable values:
These additions would streamline workflows while preserving compatibility with Godot's internals.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Partially, but workarounds involve runtime initialization, which adds complexity and goes against the intent of using constants for clarity and efficiency. Developers must resort to defining global variables or singleton resources, which are less intuitive and harder to manage.
Is there a reason why this should be core and not an add-on in the asset library?
This enhancement directly involves core functionality of GDExtension and the engine's handling of constants. It cannot be implemented as an add-on since it requires changes to the GDExtension API and how the engine handles constant registration
Beta Was this translation helpful? Give feedback.
All reactions