Allow addons to be distributed in packaged form

[Hapenia-Lans]

Describe the project you are working on

Describe the problem or limitation you are having in your project

Currently, Godot’s plugin system is working by including the plugin source code directly into the actual project. This method is very simple and straightforward, but it also brings many problems:

1. The plugin’s namespace pollutes the project’s namespace, because class_name works at the project level;
2. This working method actually requires plugins to open their source code. Allowing closed-source/commercial plugins to enter has a positive impact on promoting the improvement of the Godot ecosystem;
3. Manually installing plugins is a bit cumbersome, because current plugins are distributed in source code form, and installing them into a project requires copying the folder in the source code to the project.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Perhaps we should provide a way to package plugins as a single file (maybe xxx.gdplugin ?) that can be placed directly in the res://addons/ to take effect.

Plugins only expose plugin.gd to the project space, and public classes can be manually added to plugin.gd through const SomeClass = preload("...").

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

To prevent breaking changes, we can support two sets of systems at the same time: the current method of embedding plugin source code and plugin packages. Furthermore, this plugin package format may be able to unify GDExtension and regular Addons, by releasing different plugin packages for different platforms of GDExtension, or by placing dynamic link libraries for multiple platforms in the plugin package.

Developing plugins is also very simple: we can improve the existing plugin development method, create res://addons/some_plugin/plugin.cfg in a regular project, and fill in the required fields. The fields that can be thought of include:

• name: display name of the plugin;
• id: unique id to identify the plugin;
• description: describes the plugin;
• version: plugin's version.
• author: plugin author;
• godot_version: compatible godot version;
• godot_type: Stable or C#;
• platform: target platform, plugin packages can be for all platforms (such as plugins written in pure GDScript), or for a single platform (compiled for a specific platform of GDExtension)
• require_restart: whether enabling/disabling the plugin requires restarting the editor, which is necessary for GDExtension because of its current working method.
• dependencies: plugins can depends on other plugins to work, use id to require other plugin, when install, godot will checks all dependencies, if missing one of these, will popup an error.

Not all of these fields are required (to be compatible with the old plugin system), only when the developer needs to package the plugin.

In the plugin project, plugin:// will be used to represent the internal path of the plugin, and res:// will be used to represent the path of the project where the plugin is deployed. For the plugin project under development, it is its own deployment environment, so we only need to redirect plugin:// to res://addons/some_plugin/ through simple string splicing.

It's a very drafty idea of mine, feel free to comment below. I am not a native English speaker. Please forgive me for some grammatical mistakes 🙏🏼

If this enhancement will not be used often, can it be worked around with a few lines of script?

Is there a reason why this should be core and not an add-on in the asset library?

[Calinou]

2. This working method actually requires plugins to open their source code. Allowing closed-source/commercial plugins to enter has a positive impact on promoting the improvement of the Godot ecosystem;

This is actually not the case. You don't have to attach an open source license to the plugin, and you could use an obfuscator for the plugin's source code if you really wanted to.

That said, I wouldn't encourage the distribution of plugins without source code, as this makes fixing them yourself pretty much impossible if issues occur. See the Blender or even WordPress community where distributing plugins without source code (i.e. in obfuscated form) is heavily frowned upon.

[Hapenia-Lans]

That said, I wouldn't encourage the distribution of plugins without source code, as this makes fixing them yourself pretty much impossible if issues occur

For opensource plugins, you can just fork the plugin project if there are something you need to change. Or you can also include the source code like what we do now, which depends on your decision. For closed-source plugins, modifying the source code locally then packaging and distributing it is illegal.

[Calinou]

For closed-source plugins, modifying the source code locally then packaging and distributing it is illegal.

This is not necessarily the case. There are proprietary licenses that allow licensed users to make changes to the source code and distribute the resulting source code and binaries. This is what Unreal Engine 4/5 do, for instance. When you license a custom engine (or even Unity's source code), this is also what you get in exchange 🙂

[me2beats]

See also #142

[sandmuel]

Godot does already have a way of opening .ZIPs, these packaged plugins could simply be .ZIPs with a different file extension, such as .gdp, this would allow people to access the source, while having all the benefits of a single file (easier sharing, better organization, etc.)

[AnidemDex]

Never tried, but maybe packing the plugin in a pck file and using that in the editor plugin would work? I'll try on my end when i got time, maybe that way can help "hiding" the files and using less files to be distributed?

[sandmuel]

Never tried, but maybe packing the plugin in a pck file and using that in the editor plugin would work? I'll try on my end when i got time, maybe that way can help "hiding" the files and using less files to be distributed?

Do let me know if this works! :)