Cannot nest Custom Types from Plugins

XCompWiz commented 2 years ago

Godot version

3.4 stable

System information

Windows 10

Issue description

Background

I'm trying to refactor some of my code to a plugin. I dislike the way the _global_script_classes is maintained. Bundling that into project.godot means that I have to commit that file whenever I add a new class_name, and the file doesn't always get updated immediately. (As an aside, can I disable that list, or simply not commit that block?) It might also not be beneficial for all the scripts to be loaded globally if not in use.

I also wish to maintain my addon as a submodule which is included across multiple projects, so updates to the module resulting in changes to the project.godot file can be a bit messy.

Thus for my add-on I don't want to touch that list, if possible. I'd like to add the nodes to the add menu using add_custom_type.

Issue

If I use add_custom_type to add a type where the base is a custom type I added a few lines prior, the type does not get added to the tree at all. I'd expect it to appear as a hierarchy, as with native types and normal class_name classes.

Steps to reproduce

    add_custom_type(
        "BehaviorNode",
        "Node",
        preload('res://addons/behavior-trees/bt_base.gd'),
        preload('res://addons/behavior-trees/action_icon.png')
    )

    add_custom_type(
        "BehaviorAction",
        "BehaviorNode",
        preload('res://addons/behavior-trees/action.gd'),
        preload('res://addons/behavior-trees/action_icon.png')
    )

BehaviorAction does not appear in the Add tree.

Minimal reproduction project

No response

Calinou commented 2 years ago

add_custom_type() is considered a legacy approach since Godot 3.1, with class_name being recommended instead. It's not currently planned to remove add_custom_type() in Godot 4.0, but it may still be removed in the long run (maybe in Godot 5.0).

(As an aside, can I disable that list, or simply not commit that block?) It might also not be beneficial for all the scripts to be loaded globally if not in use.

No, but there are plans to move it to a separate file (which could be stored in project-specific metadata and therefore wouldn't be committed to version control).

XCompWiz commented 2 years ago

Understood! Thank you for the fast turnaround and information.

No, but there are plans to move it to a separate file (which could be stored in project-specific metadata and therefore wouldn't be committed to version control).

Can I assist with those plans at all? I'd be very happy to see that happen.

Calinou commented 2 years ago

Can I assist with those plans at all? I'd be very happy to see that happen.

Work on this hasn't started yet, but it may be implemented by either https://github.com/godotengine/godot/pull/48201 or https://github.com/godotengine/godot/pull/44879 already.

cc @willnationsdev

willnationsdev commented 2 years ago

No, migration of this data to a dedicated metadata file has not been done in either of those PRs. I believe the saving and loading of "custom types" is done in EditorData while the saving and loading of global script class information is handled in ScriptServer. As mentioned, CustomTypes are a legacy feature that just manually appends additional TreeItems to the Tree of classes in the CreateDialog and nothing more (the class isn't globally recognized as a type, doesn't exist at runtime, and has no "reflection" support, etc.). Global script classes are much more involved, even though both types of data are currently stored in the project.godot file.

You are welcome to add a PR to my branch to include that feature for 4.0 if you'd like. Not sure what the dev team would want the metadata file to look like though (where it goes, what it's called, formatted the same(?), etc.).

XCompWiz commented 2 years ago

If that information can be provided or referenced (where and how the file should work) I can certainly take a crack at it. 😁

willnationsdev commented 2 years ago

@XCompWiz I don't think any decisions regarding it have been made yet. My guess would be some C++ Resource type defined in the core alongside ScriptServer, and then ScriptServer saves to it / loads from it. As long as the corresponding logic in ScriptServer is adapted to match the file location / file format, then the implementation may not matter much, but idk if the conventions for such things have changed at all since I first came along. Maybe take a peek at the files saved to the new hidden godot directory and see what all files / formats are being stored there as inspiration.

godotengine / godot