Scoped packages are placed under a deep folder structure and global classes don't register

[razcore-rad]

A bit of background: at GDQuest we're trying to find a solution for dependencies since we have a lot of assets shared between projects, including custom global classes etc.

I think we're kind of stretching the possibilities of the Godot addon-system here, but today I experimented with a few plugins and scoped NPM packages:

• https://www.npmjs.com/package/@razcore-rad/kenny_prototype_material
• https://www.npmjs.com/package/@razcore-rad/colorpicker_presets

They are installed under the @razcore-rad folder in this case and although Godot detects the plugins, I don't think the system was meant to work this way:

❯ tree -L 2 addons/
addons/
└── @razcore-rad
    ├── colorpicker_presets
    └── kenny_prototype_material

They seem to work fine if there are no global classes (class_name) definitions, but in this case kenny_prototype_material should register a resource material. This works if I move the folder one level above:

❯ tree -L 2 addons/
addons/
├── kenny_prototype_material
│   ├── ...
└── @razcore-rad
    └── colorpicker_presets

But not if it's nested under @razcore-rad.

It would be nice to install the project at @razcore-rad.addon_name instead and this should solve the scoped packages problem. What do you think of this case?

[bend-n]

NPM's folder structure is the same:

node_modules
- @scope
  - package

I like this system because it groups up packages in the same scope nicely.
It would be trivial to change the installation directory, but im not sure what it solves, the class registers fine for me. Which godot version are you on? It works fine for me on c64afeb01.

Im not quite sure what your issue is. What makes you think the system isnt meant to work this way?

[razcore-rad]

Hm I see, this might be a problem with Godot. I'm not on the latest commit because we need a stable version in production.

I tried with:

• Godot Engine v4.0.3.rc2.official.2ac4e3bb3
• Godot Engine v4.1.dev2.official.668cf3c66 out of curiosity, but it still doesn't work.

I made a small test project to show the problem better. Both plugins are enabled, but only TopLevel* classes appear in the resource/add node menu, compared to NestedLevel*. In code they all appear to be accessible... that's shown dbg.gd.

This might be a Godot bug, I'm not sure, the plugin system always had inconsistencies... and I have no idea why you can find the KennyPrototypeMaterial3D while using the @razcore-rad/kenny_prototype_material scoped NPM package.

Here's the project I'm working with that doesn't find the Nested* custom node/resource: godot-4-dbg.zip.

The custom TopLevel* node/resource appear in the dialogues only when the plugin is enabled, but the custom classes seems to still be registered since I have access to them in code. This definitely seems like a bug to me.

My understanding was that they should register only if the plugins are enabled. If you know anything or can replicate the above let me know, I'll open a Godot issue and discuss it there.

My initial thought was that the nested structure is quirk and not meant to be used like that in Godot.

[bend-n]

You know, it might be the plugin thing.. I never "enabled" the plugins, as afaik plugin.cfg's and such are completely unnecessary. I think enabling the plugin might be completely deetrimental.

Will try turning on the plugin, see if it works then.

Yep, plugin on => no class, plugin off => class.

Looks like a godot bug.

[razcore-rad]

That's so weird, for me (on v4.0.3.rc2) it's:

• Plugin ON => TopLevel* visible, NestedLevel* not visible
• Plugin OFF => TopLevel* not visible, NestedLevel* not visible

in Create New Node/Resource.

Seems to me the TopLevel* behavior is correct, it's just with the nested directory that's a problem so that's why I was proposing @scope.npm-package as a compromise.

And unfortunately not having the plugin enabled wouldn't be a solution either because some times we do have to run initialization code and do more stuff than just have resources.

Regardless, I'll open an issue in the Godot tracker too.

[bend-n]

Also, could you try this addon, and see if the classes show up?

[razcore-rad]

Yea, it's the same case, I don't see the node in Create New Node

Tried with v4.0.3.rc2. And not being a plugin I can't try to enable it so...

edit: maybe it's a difference with operating systems as well, I'm using Ubuntu 23.04.

[bend-n]

Hmm, actually my addon doesnt work anymore either.
Actually, none of my normal custom classes seem to be showing up in my projects...

[razcore-rad]

I think the nested structure isn't something that the Godot devs thought about and it's just a quirk that it used to work, but maybe they'll work to extend it to function that way at some point. Meanwhile I think the flat addon structure with just one top-level folder is the correct way to go about it until this is solved.

[bend-n]

No, like my non nested classes arent working either.
Moving the addon folder up doesnt help me at all.

[razcore-rad]

Ah well I think that's because you have to make it an actual addon and enable it. I think that's the intended way of how it was working:

• addon ON => access to classes
• addon OFF => no access

But since you don't have a plugin.cfg it's treated as an OFF addon most likely.

[bend-n]

No like all of my classes.

Not in addons/.
Just my res://class.gd isnt showing up.
Also, i havent seen anything in the code about classes being enabled with plugins...

[razcore-rad]

Oh... I have no idea about that one

[bend-n]

The lookup class thing doesnt seem to work very well as a whole, but if the thing doesnt show up, you can always just drag the class.gd file directly into the thing that needs it, be it script or field.

[razcore-rad]

Yea, I'll have to see how that works with resources, I hope it work the same as you mention, then at least it's a workaround, but it's definitely not ideal.

[bend-n]

Also, if you manually move the folder up (if that fixes it for you) you should be able to use it normally, and it wont break when the file moves, because it seems like the class exists, the dialogue is just super broken.

[razcore-rad]

Well, unfortunately the workaround doesn't include resources. So I can't drag this custom_materialg.gd for example on a material slot so that's a no-go.

And the other thing about moving stuff manually... I mean if I start doing that there won't really be a point to use gpm. The whole thing was about automation so... anyway, thanks for looking into it :)

[bend-n]

Changing the file structure is kinda a big breaking change, so i dont really want to do it, but ill see if i can fix the godot bug...

[bend-n]

Okay im fairly sure its related to the cache - can you try a rm -rf .godot? I cant reproduce it anymore having done that.

[razcore-rad]

No... can't reproduce this, still no ActionLabel