godot: add_custom_type() does not register the added type as a class
Documentation Link: Custom Node - Making Plugins
Problem:
add_custom_type("NodeName", "ParentNodeType", preload("script.gd"), preload("icon.png"))
does not register the new NodeName node in the editor as a valid reference-able class name, when implemented as a new node type through the plugin system.
Steps to reproduce: Create a plugin as described in the doc and then try to create in code a new NodeName node in any other script file. The editor throws: “Identifier ‘NodeName’ is not defined in the current scope.”
Expected Behavior:
Work the same way as HTTPRequests node does for example. One can add it manually in the scene tree editor or in code using var x = HTTPRequest.new()
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 3
- Comments: 18 (12 by maintainers)
If you pick randomly any pre-existing node and write into script
var x = RandomNode.new()it will work in 100% of cases. Then how come is it reasonable that a custom node implemented by an add_custom_type func in a plugin script has no such capability, which is directly counter-intuitive to any semblance of consistency?Second of all, class_name produces an entry in the New Node Wizard in the form of “NodeName (script.gd)”. How can it be considered to make any sense that a custom node, which is introduced by a plugin, has its source script specifically mentioned in the New Node Wizard? A user dealing with a tailored plugin designed for a specific functionality only cares about the endpoints which the plugin exposes, not where they originate from. By that idea, it is completely useless and even incorrect to expect plugin devs to use the class_name keyword to implement custom nodes from within a plugin. If the source script reference is absolutely required in the New Node Wizard, in the case of a node implemented by a plugin, it would make the most sense if the (script.gd) reference is replaced by the name of the plugin.
Pinging @reduz & @RandomShaper for sage advice.
Tagging as discussion, since I feel it might be by-design. If you want
class_name-like functionality, useclass_name-s.I’m chalking my previous problem using class_name up to a fluke. It looks like class_name is supported in plugins, and there is actually a special case in the engine code to automatically show/hide the registered classes when you enable/disable the plugin they reside within. So, it seems to me that class_name is in fact a viable replacement for add_custom_type, unless you have a special case that needs more control over when a class gets registered.
In the latest master (but not in 3.1.1) the tooltips in the scene tree show your class_name as well, so that is the same between both methods.
The only other difference I see right now is that the script icons aren’t faded when you use class_name in a plugin. It would be nice to support this for class_name, but only for objects that are defined within an addon (like how there is a also special case for enabling/disabling them).
This should also really be documented on the “Making plugins” page with an alternative example using class_name instead of add_custom_type.
I’ll be switching back to class_name for my plugin, but since these two functions are essentially the same, I’d still support the OP’s request to let add_custom_type() register the class. In the long term though, hopefully we can have a single way to register classes that works across all scripting types.
Also, when you add a class_name defined node from the New Node Wizard, it will automatically attach the relevant script to the node, which it does the same for a node defined in a plugin with add_custom_type.
How come it makes sense that if both of them behave the same way in the scene tree editor, it should not be possible to instance both of them the same way in code?
There should be two ways of adding classes: one for local in-project classes and the other for plugin classes, because the needs are different and it makes no sense to reference the class script file name in the node selection dialogue for plugin classes. I’m just glad that I’m not the only one who sees it this way.
On Mon, 5 Aug 2019 at 21:22, jonri notifications@github.com wrote: