Enforce that custom nodes/resources keep their original type (assigned script) #7905
Labels
Milestone
Comments
|
I think this can be solved at the editor UI level, without adding a new property:
Also the problem is that in godotengine/godot#91341 this is done only for nodes, but resources are also modifiable through the editor, and in general any object can have a script. |
During saving and loading of a scene you lose the information if a node is a custom node or a native node with a script attached. With current loading behavior you will always get a native node with a loose script attached that you can clear. The new property is there to tell that this node was instantiated with this underlying type and that it should be instantiated again with this type during loading, even if
godotengine/godot#82684 did handle nodes and resources alike, because it managed custom types at the Core/Object level. But changes to Core weren't desired so I created this new PR where it's managed on a Scene/Node level, for now. I intend to add this feature to Resource again if this PR gets accepted. |
In my opinion, this should be an internal property or editor metadata, not a documented property. For metadata we use the prefixes List |
I did a quick test to see how this gets stored in a packed scene:
So, I think this might work. The question now is just, what makes more sense for a script resource? An internal property or a metadata? |
|
So, I changed everything to use metadata instead. Works great! It also works with resources now. |
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
Improvement to Godot's custom node and resource type handling.
#7808
Describe the problem or limitation you are having in your project
Currently Godot's custom node/resource types are no different than native nodes/resources with a script attached to them. The problem with that is that plugins exposing custom node types and resources with systems functionality (AI for example) are no different than scripted nodes by the user with game logic. Extending a plugins node to add ones own game logic to it and then clearing the extension to that node in a later stage, also clears its original script, turning it into a naked native node and losing the fundamental logic it was meant to perform.
A similar problem happens with resources. The script of a custom resource type can accidentally be cleared, effectively changing it's underlying type.
A custom node type or resource type, once created, should retain it's baseline type, just like native nodes or resources do. This is an intuitive expectation I believe most users have.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Custom node types will have a faded script icon. This script cannot be cleared.
An additional property "Custom Type Script" will hold it's underlying type (only visible in the inspector with DEBUG_ENABLED). This will be the fallback script in case "Script" is cleared.
When a custom node holds an extension to it's type, it's script icon is shown in full color.
"Script" will hold the extension script as normal.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
An additional property "custom_type_script" has been added next to "script" inside Object. When a custom type object is instantiated, both "custom_type_script" and "script" are set. "custom_type_script" defines the baseline type of this object and will be the fallback in case "script" is cleared by the user. A check is also performed so that "script" must be a valid extension of "custom_type_script". These checks are currently in form of warnings, but can be changed in a later stage to actively prevent setting an incompatible script.
Note for C#: When running a project, there will be several warnings that "Script" was set to null, not respecting the existence of a "custom_type_script" as baseline. This happens during C# domain reload where scripts are detached from all objects and re-attached after reload.
If this enhancement will not be used often, can it be worked around with a few lines of script?
I would say, no.
Is there a reason why this should be core and not an add-on in the asset library?
I believe this needs to be part of Godot's core functionality, to make a clear distinction for the user between different node types:
The text was updated successfully, but these errors were encountered: