-
-
Notifications
You must be signed in to change notification settings - Fork 21.5k
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 support for exporting resource script constants and script classes. #22641
Comments
Related: #6763 |
Just taking a quick look, it seems to me like part of the solution might lie in going to
That would at least make accessing a variant from the |
There's probably also merit in simplifying the GDScriptLanguage's implementation of that method since we don't need to parse the ENTIRE file just to determine what it's class name is. |
CC @vnen |
It's not only about the class name. If you are accessing methods and members of a variable typed with a custom class, the parser checks if those are valid as well, and for that it needs to parse the whole script. For this case it would also need to know if it's a resource. Now about the OP, the problem is making the de/serialization work properly, and expose this to the editor as well. The GDScript part should be only setting the proper hints for that system once it's in place. |
@vnen Ah, that makes more sense. I don't know if that's a significant "problem" per se. In the PR I've linked that closes this, my tests show that I can safely serialize and deserialize both types of resource scripts, all from the Inspector. I can even have a script class's ScriptInstance as a sub resource within a preloaded constant resource script's ScriptInstance. Here's the test I have:
If I try to add the MyResource or SubResource to the node's script properties in the Inspector, there's a bug with a massive list showing that doesn't display a scrollbar, so I can't access them, but if I create them as new resources in the Inspector first, save them (which works), and then drag n' drop them from the FileSystem dock to the Inspector's script properties on the node script, THEN the instances show up properly. If I then edit the There's also a bug here where the scripted resources don't show the right icon (they show a "Node" icon if a custom icon isn't defined and it should be a "Resource" icon) and their typename isn't displayed (probably a factor in the changes my PR made). However, the functionality parts of it are all there, what with de/serialization, safely exporting, and editing the data. So, all of the bugs I've found are related to the Inspector's user interface malfunctioning or it not finding the right class name / icon to display in the UI - none of which actually break the functionality. It's just slightly poorer usability at the moment. |
What I think is that this should be solved in the editor and probably with a new type of |
@vnen What do you mean by "solved in the editor"? And wouldn't you still need to use |
|
Yes please, this will be very useful for a lot of reasons :D |
Would this feature change also have the effect, that you could edit the custom types you drag into the export fields in the inspector, be edited like Built-In types like Textures etc.? |
@Reneator You can already do this, technically. If you create a resource script, then create a resource manually in the Inspector, and then set its |
@willnationsdev Thank you a lot! Was struggling with this! I achieved it by (If somebody else finds this issue while searching for a solution):
|
@Reneator Just to say, the process as it is is very cumbersome. The change proposed by this issue would allow you to directly export the type, without having to manually attach a script to the resource in the Inspector. |
@willnationsdev the steps i did was in a current 3.2 nightly build (from 2 weeks ago). I tested the same in 3.1 and the customResource wouldnt show up in the list of Resources after i defined a class_name. |
@Reneator Oh, maybe. Yeah, that's cool. Didn't know they'd added that. |
Closing in favor of godotengine/godot-proposals#18, as feature proposals are now tracked in the Godot proposals repository. |
Godot version:
3.1 Alpha 1
Issue description:
I would expect the following to work:
I can actually confirm it isn't a constant by creating a derived version of
MyResource
, class naming it asSuperResource
, and then literally re-assigning it, which I really don't think I should be able to do:To ME, this seems like a bug that shouldn't be allowed, and which consequently would allow the export of the type name to work in 3.1.
It also seems like this just flat-out wasn't ever a feature, even in 3.0.
Steps to reproduce:
Recreate the code examples above for Resource-extending scripts.
3.0: create a constant and try to export it. Fails.
3.1: Same as 3.0 + create a class name and try to export it. Fails.
The text was updated successfully, but these errors were encountered: