-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
Add GDScript resource export. #62411
Conversation
56f1d67
to
f2ff10f
Compare
If you were attempting to test out just this pull request, then the way to do that would more or less be to confirm whether the GDScript compiler gave you some sort of error when attempting to export a user-defined resource type (whether through static typing or not). I'm not really sure you tested this out correctly. |
f2ff10f
to
6dc84a7
Compare
@vnen I was just getting C# working and made an attempt to export C# types in a GDScript property when I ran into some trouble. I have no way to export a global C# resource property from a GDScript node or resource. I would like clarification on which syntax below should be used. Neither of them are currently supported.
|
41e3b8b
to
1465bd3
Compare
I have made an update to this branch that allows GDScript to use global script classes from other languages (NOT GDScript) for static typing. So you should now be able to add a scripting language using GDExtension or add global script classes to VisualScript, and then use those global script classes as static type hints. Then the GDScript language will accurately perform static type checks, provide autocompletion/intellisense, etc. Exporting ones extending |
1465bd3
to
9b082c8
Compare
9b082c8
to
497d711
Compare
497d711
to
a3ddf3a
Compare
Is this going to make it intp 4.0? |
@Zireael07 Yeah, it should, from what I've heard. There are just some hangups that have to get resolved before it and the sibling PRs can be merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks ok to me on the exported part, the analyzer part I have no idea, would appreciate more eyes there.
@willnationsdev Thanks hugely for the work in this area. We wanted to discuss and implement a cleaner API for you to rely on that would allow better information retrieval regarding to global classes, which is why we did not want to merge this right away. Unfortunately, we did not have the time and resources to work on this, and given the demand there is for this feature, and given these PRs are already very good, it will do as-is and we can discuss cleaning up the global class registration in 4.1. Again, thanks for working on this and apologies for the delay in getting this merged, but circumstances beyond our control made properly reviewing and merging this difficult. |
Tested this PR together with #62413, it seems to work well! One needs to reload the project after defining a new custom resource with @export var some_res: MyCustomRes works fine to export it from GDScript. It's properly filtered in the Inspector, with multi-level inheritance taken into account ( Drag and drop of saved custom resources works from the FileSystem dock: Just some testing fun :)
I didn't test #62417 for now because it looks way hackier and far reaching into core internals and multiple editor components. We do want it to work in the QuickOpen eventually but I suggest focusing on getting #62411 and #62413 merged first, which IMO implement the missing feature in a quite satisfactory way already. |
modules/gdscript/gdscript_parser.cpp
Outdated
@@ -3758,6 +3758,33 @@ bool GDScriptParser::export_annotations(const AnnotationNode *p_annotation, Node | |||
return false; | |||
} | |||
break; | |||
case GDScriptParser::DataType::CLASS: | |||
// can assume type is a global GDScript class. | |||
if (!ClassDB::is_parent_class(export_type.native_type, Resource::get_class_static())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (!ClassDB::is_parent_class(export_type.native_type, Resource::get_class_static())) { | |
if (!ClassDB::is_parent_class(export_type.native_type, SNAME("Resource"))) { |
For consistency with the existing code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can definitely make this change, but it also kinda confuses me why this would be preferable implementation-wise (if addressed, it'd be in a totally different proposal/PR probably).
I get that using the cached StaticCString is better here, but if that's the case, why not arrange things so that get_class()
and get_class_static()
return a StringName
that is likewise constructed from _scs_create(...)
, that way you can get performance benefits of SNAME(...)
built into those methods? That would then allow you to clean up all of these stringly-typed class name references throughout the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just have nitpicks, otherwise looks fine + I trust Akien's testing.
Was it? I didn't think that was the case, even in Godot 3.x. Either way, that was already an issue in 4.0 before I implemented all of my stuff. I'm not entirely sure why it's happening, but I haven't yet had time to diagnose the cause. Perhaps something related to EditorData caching information about script class inheritance. |
Yes, there are some things that don't update and recognize |
a3ddf3a
to
339aba1
Compare
I've made the requested adjustments. Should be good to go for merge at this point afaik. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, and seems to work well.
@vnen might still want to give the analyzer changes a qualified review but that can be done after merge when he's available.
Adds support for GDScript to be able to export user-defined resource types.
Related Issues:
Related PRs:
Sibling PRs:
Considerations:
@export("<typename>")
syntax yet.