Godot: Using class_name in a newly created script does not register it in the node creation dialog, if under addons/

[Zylann]

Godot 3.1.1
Windows 10 64 bits

I suspect there is a scenario where it doesnt get registered at all. I was writing a new prototype this evening and the script still hasn't registered.

Here is what I remember doing:
1) Create a new project (no new scene)
2) Create a subfolder addons/zylann.scatter/
2) Right-click in the FileSystem dock and choose "New Script" into that folder
3) Write the following (I wrote it by hand so might have had a few errors while doing so, but the end result was the same):

tool
class_name Scatter3D
extends Spatial

var _scenes = []

func _ready():
    # TODO Temporary test
    _scenes.append(load("res://props/placeholder_tree.tscn"))

4) Save the script (still no scene in the project, I don't use the default Ctrl+S, instead I save the script only)
5) Create a new scene, open the node creation dialog, search for Scatter: it's nowhere to be found, despite the class name being recognized by the script editor and saved in project.godot.

Even after restarting the editor, the node can't be found. No particular messages in the console. Did I miss something obvious?

Here is the project, apparently you should be able to see directly what happens, since restart doesnt fix it:
Scatter.zip

Edit:
It would seem any script I create under addons/zylann.scatter/ never get registered, but they do if I they are under the project root Oo
According to TheDuriel it's intented. Registration works in other systems, just not in the node dialog. I guess it's because plugins can be enabled/disabled, so it would make sense for them to no longer clutter the dialogs. However, it's not documented...

[jonri]

@Zylann can you clarify exactly what behavior is intended? In your example project and my own project, I have discovered that the script with class_name gets registered in the node dialog if you enable the plugin and is removed if you disable the plugin. This seems to be the intent of the code here.

To me this says that class_name could be considered a replacement for using add_custom_type() to register your plugin unless you need something beyond enabling/disabling the type with the plugin. If this is officially the case, I think it should be added to the documentation on creating plugins, with the auto-enable/disable feature explicitly mentioned as well.

[Zylann]

I have discovered that the script with class_name gets registered in the node dialog if you enable the plugin and is removed if you disable the plugin

That's what I realized later on, it's only hidden or shown from the dialog, other class_name functionality works (and should). If it's properly shown when the plugin gets enabled, then that issue could be closed, but could be worth documenting that I think.

[Xrayez]

I just stumbled upon this when creating a plugin which exposes a new Resource via class_name, and it doesn't show up in the Create New Resource dialog either.

But I noticed it does show up in dialogs when the script resides directly under addons/my_plugin. Disabling a plugin prevents the class_name scripts to show up in dialogs too.

So, to reproduce the issue, you need to put a script directly under addons folder. Those kind of scripts will never be visible by creation dialogs as it doesn't belong to neither plugin. It creates a problem when I want to create a global script which can be accessible by other plugins, and be exposed to user.

This is another instance of godotengine/godot-proposals#22 @willnationsdev.

[Calinou]

I can confirm this on 3.2 stable.

[willnationsdev]

At the time that script classes were first introduced, I'd heard people wanting to make sure that only active plugins' nodes would actually show up (so that installing a plugin, but keeping it inactive, wouldn't make those nodes appear as options).

However, if people consider that a bug, I can submit a PR to fix it. These 5 lines are the offending code. Simply remove that, and they should show up as normal.

Edit: Since it's merely a half-measure, as it doesn't actually prevent the name from being a script class in the first place, it should probably be classified as a bug. The more proper way of fixing the "problem" that this was solving is to introduce actual namespaces into Godot's scripting API via #21215.

[Calinou]

However, if people consider that a bug, I can submit a PR to fix it. These 5 lines are the offending code. Simply remove that, and they should show up as normal.

Please do, I'd prefer using class_name over the "oldschool" custom type system (although it's not a strict requirement for my use case).

[akien-mga]

Classes registered in a disabled plugin should not be available. If they're currently only unavailable in the Create New Node dialog, but still registered in the global namespace, that's the bug which needs to be solved.

[willnationsdev]

@akien-mga @Calinou

For reference, I'd fixed this issue previously in #32434, but because there was no way to distinguish between addons and plugins, even addons that were not plugins (which have no way of being enabled or disabled) would get excluded from the scan.

Should I just recreate this PR, but set it to enable plugin-less addons' script classes by default? Or do we want some mechanism whereby the plugins tab can actually perceive all "namespaces" of addons in the project and enable users to toggle on/off each addon, regardless of whether it has a plugin or not?

Also, isn't this in some way related to the whole sub-project proposal whereby the addon system would no longer be based on the res://addons/** directories, but rather would detect addons wherever they are in the project based on project.godot files or something? If we hardcode a check that iterates through the res://addons/ directory to find addons, it won't cooperate with any revisions to the addon system that break that assumption.