godotengine
Add support for global plugins/universal addons
Describe the project you are working on: For this the specific project doesn't matter, what matters is that I'm using the same addon for several of my projects.
Describe the problem or limitation you are having in your project: I see it useful for people (like me) who use a ton of the same addons across different projects because it would speed up things if it auto loaded the addons from some directory i set for the engine (much like you set the engines default project directory)
Describe the feature / enhancement and how it helps to overcome the problem or limitation: It would be a feature that would allow for automatic addon placement in a new project, thus speeding things up for people who use a ton of addons and make a ton of projects.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: The idea is simple, the user can make a Directory that you label as the universal addon directory in the editor settings (much like you set a directory for default project location), so for every new project when it is created the editor will automatically put the addons (or it could ask which addons you want to put from the directory in when the project is created)
the pseudocode would look something like:
- Grab editor setting "Universal addon" (or some such name)
- Gets the new project directory
- (Upon project creation, optional) popup a list of addons from the directory that can be toggled on/off
- (in case of 2 implementation) When ok is pressed copy all of the addons toggled on
- Grabs the addons, places them in the new project directory as an addon
If this enhancement will not be used often, can it be worked around with a few lines of script?: It can be worked around by making a directory where you store addons and you can just copy them over to the project, so it's not that big of a deal, this would just shave off a few steps making this quicker.
Is there a reason why this should be core and not an add-on in the asset library?: Because it's an improvement to the add-on/asset library and one couldn't make an add-on for Godot that would do this (I'm fairly sure atleast)
I guess it has been suggested before.. but a different path to doing so..
From what I've heard (mind you, just rumors), core devs planned a different approach with those plugins to be treated as regular projects (which could be nested), going for the approach inspired by the node-based system.
@akien-mga asking you since you explained it nicely in the closed PR - is @Xrayez right about the approach this should take? I'd love to have this feature and I'll be happy to create a PR, but I'd like it to be mergable. Could it be as simple as treating all projects in HOME/godot/plugins as global plugins, or did you have something else in mind?
so for every new project when it is created the editor will automatically put the addons
What about a way for addons to be used globally, but not installed in each project? For example, with https://github.com/godotengine/godot-git-plugin, it doesn't really have a purpose of being inside the project aside from that being the only supported option. This addon could be deleted from the project and the project would still work fine, so it doesn't need to be copied into the project if there was a system to allow it to exist elsewhere.
could global addons just to be located somewhere, say in some "global plugins dir" then the user could specify what directory to use as global plugins dir and after that when creating or loading a project Godot enables these global plugins?
also maybe there could be some API methods like
set_global_project_dir
enable_global_project_plugin
etc
About UI implementation: It could be a plugins list in Global Settings — Plugins, like we have it in Project Settings — Plugins or implemented as one Plugins List (for both Project and Global plugins), but then it shouldn't be located in Project Settings menu.
I believe the ability to have global plugins would be handy.
But on the other hand, there are several concerns:
-
safety of other projects. for example, if a global plugin can delete the content of projects, then when such a plugin is activated, each open or loaded project will be deleted. in this case, one need to be as careful as possible when using third-party projects that use global plugins.
-
it may increase projects coupling, this can be compared to a singleton pattern, which, if used incorrectly, easily turns into an anti-pattern and only creates more problems.
One benefit of global plugins is, depending on how they were implemented, they could remove the pressure to add nice-to-have plugins into the Godot core.
For other game engines such as Unreal and Unity, many features that would be considered core are actually plugins that are installed and enabled by default. Over the years Blender has transitioned to a similar structure.
If Godot supported the ability for someone to zip a collection of plugins with the Godot executable, that would allow a variety of different Godot installations to choose from, both official and third-party, similar to Linux distros.
That way a beginning developer could download an installation with a hundred enabled plugins while the Godot core remained light and minimal.
That would also give core developers the option to convert some core modules into plugins, which in turn would allow game developers to toggle those modules without compiling a custom executable.
We discussed this yesterday in the Godot proposal meeting. We acknowledge it's a desired feature and could be useful, but at the same time, we're wary about uses of the "global add-ons" feature for add-ons that should clearly be stored within the project. In other words, your project might break if it relies on global add-ons but other people in your team forget to install them. We don't want to require people to scour the Internet manually to find add-ons before they can start working on a project.
To summarize, we think "global add-ons" work best for editor-only features that aren't related to your project, not features that will be exported into the final project.
That would also give core developers the option to convert some core modules into plugins, which in turn would allow game developers to toggle those modules without compiling a custom executable.
Global add-ons aren't a strict requirement for moving core features to add-ons. See godot-interpolatedcamera3d for an example.
If this add-on was to be used as a "global add-on" by someone, this could cause projects to break unexpectedly when switching PCs or working in a team. To give a counterpart to Node.js, it's the same issue as using npm install -g for project-specific dependencies :slightly_smiling_face:
For what it's worth, the Node.js community is attempting to fight this problem by disallowing the use of globally-installed modules in the project itself. It will take a while for them to fully solve this issue, though.
No, but to a large number of users they won't know that the once standard features are now add-ons they have to manually download and enable for each project, which will create some ugly, negative word of mouth that will be hard to fight.
On Fri, Oct 2, 2020 at 3:37 AM Hugo Locurcio [email protected] wrote:
That would also give core developers the option to convert some core modules into plugins, which in turn would allow game developers to toggle those modules without compiling a custom executable.
Global add-ons aren't a strict requirement for moving core features to add-ons.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot-proposals/issues/831#issuecomment-702602267, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBEIS5QRSMM2L7EDH3S7U3SIWGOBANCNFSM4M7Q55OA .
In other words, your project might break if it relies on global add-ons but other people in your team forget to install them. We don't want to require people to scour the Internet manually to find add-ons before they can start working on a project.
I am all in for global add ons, but as seems to be the consensus here, we need to be careful. I've had that exact same experience with PureData back in the day. I even have problems viewing my own old Pure Data projects as I've lost some of the global plugins and can't find them online anymore. :/
Indeed, it would help greatly if "go do that in GDNative" was a better experience! And I agree that it should only be for the "editor plugins". The plugins that have anything to do with your project must be included in your project.
Thoughts about the implementation:
-
Of course, plugins that go into your project should be in
res://addons/. But "editor-only" plugins should definitely not! This way, you don't have to specify specific addons in your .gitignore - this folder is in your project for a reason. And that makes a clear difference between one and the other. -
I would suggest that editor-only plugins are accessed with
addons://, or even better - withaddon://, which is the path to this addon! This would eliminate a few other problems. First, an addon won't have to hard-code its own name in everyload(""), which makes it easier to rename addons (and fork them). If your project is an addon, then this should be as simple as usual with "res://" , but for addons. Second, you could putLICENSEandREADME.mdin your root folder, which is good for Github, and users downloading your addon won't have to worry about checking the files and not installing a very important part of your addon because it would overwrite their own files. Since this addon does not go into your project, it does not have to be inres://uniquenameanymore ! -
Downloaded "non-global" addons should be kept in your "local library". When you start a new project, you can open your "local library" and choose which of your global addons to enable, and which of your non-global addons to install. I would even suggest that the "fourth editor button" should not open the Asset Library, but the list of your local addons instead, and there should be a button to "Download more...". Now it's the opposite way - you go to the online library first, and from there you can go to your "Plugins". This really should be the other way around - with this, you will access your local library more often than the online library.
-
If you update a "non-global" addon in one of your projects, the newer version is kept in your local library. It will not automatically update in all your other projects, but when you do update it, you won't have to download it again.
With this, we wouldn't even need "Favorites" implemented in the Asset Library, because you would simply download them all.
Turns out this issue is already there since long ago: #1205 Redesigning the plugin system is not so simple, so the discussion is ongoing.
(EDIT: this is slightly different, but it's mostly the same general issue)
I would like to add my two cents to this proposal. About dependency issues when working with git, perhaps a link (soft or hard) can be used without copying the data in every project you open. If another user doesnt have the add-on, they can choose to sync their global addon repo with the global addons in the user's project. Anything else would have to managed per team. Then another thing to consider is cross platform support, 'cause git doesn't like Window's soft links, and Linux and Mac OS don't appreciate users making hard links to folders from what I've read.
I made a template project folder with all the globals add-ons, then instead of using the project manager new project, i copy the template folder & change project name in project settings, you can also make a custom project manager.
I was wondering about this earlier, I was thinking perhaps the Project List window could have an AssetLib tab added next to the Templates tab. Templates are cool but I'm not sure how often they're used practically (forgive me if they're actually frequently used!) so it feels like there could be more functionality added there. Also the distinction between assets and templates can be a little unclear (some assets in the AssetLib, for example, don't put anything in the addons folder, and often seem more like templates or examples, but ones you can just drop into an existing project rather than having to create a new one).
Perhaps the Project List could also be a kind of package manager or cache for the AssetLib, with an extra tab next to Templates. You could download assets you frequently use (or add via local repo for tooling you've created), which saves the zip to the Godot config folder, and then have a checklist in that tab that lists your "cached" assets, and allows the New Project dialog to add and extract the selected 'default' assets to new projects. You could then have further fine-grained control over which default/non-default assets you want to include in the New Project dialog with a similar checklist there.
I've never dug into the Project List code before so I'm unsure how feasible it is. I think it'd be a nice addition though. It seems like it would be relatively doable with reuse from the editor AssetLib dock, the Plugins checklist, etc, but I'm not sure how coupled they are to the editor vs the project list.
There ARE addons that need to be in a global folder by their nature. I use these to make the editor align with my workflow (a modified version of the second one): https://github.com/Frontrider/Godot-Component-Browser https://github.com/remorse107/vertexsnap
And they should really not be inside my project, as these are pure editor only plugins.
Not gonna argue that a heightmap terrain might need to be in the project, but a pure editor only plugin that has no right to be accidentally packaged into the app?
I've started to create many sub-projects (sandboxes) for my main Godot project (to speed up development and not to worry about breaking other things in the main project), and I've been recently using symbolic links/junctions on Windows to share addons between them, and so far this kind of approach works fine. But having support for global addons is still must have for editor-only plugins.
Those addons are still versioned in git repository, but files are committed only once rather gazillion of times between projects, and there's no way for those plugins to go out of sync this way.
I really think that the new GDExtension feature must have a way to share code between multiple projects. With C++ modules, you can do this by simply recompiling the engine with the classes you need, and all those classes will be available in all projects statically. This is not currently possible to achieve with GDExtension/GDNative (at least I haven't received response at Godot contributors chat to confirm this), and I wouldn't want to constantly install and/or recompile the sources in order to use new classes for each new project I create, like sandboxes/prototypes.
That said, I really believe that support for global plugins must be implemented for a feature which acts like/mimics the built-in features 4.x (GDExtension). This would increase the adoption rate of GDExtension over C++ modules.
Again, this is must have to implement if GDExtension aims to deprecate/replace C++ modules fully. Otherwise, feel free to ignore what I've said.
To summarize, we think "global add-ons" work best for editor-only features that aren't related to your project, not features that will be exported into the final project.
It's been a year since this comment, did this get implemented?
I find it weird to install a "Command Palette" plugin in my project folder.
It's been a year since this comment, did this get implemented?
No, work hasn't started on this yet.
I find it weird to install a "Command Palette" plugin in my project folder.
Command palette is a built-in feature in Godot 4.0 :slightly_smiling_face:
Reading this thread I'm disoriented. There are 2 different topics being discussed here, which should be 2 different proposals. Both of them good ideas, mind you.
Is this about editor-wide plugins (not in project folder) or about managing plugins (make adding them to projects easier)? The original issue seems to be about latter, but most comments seem to discuss the other. The title is ambiguous.
From op:
It would be a feature that would allow for automatic addon placement in a new project, thus speeding things up for people who use a ton of addons and make a ton of projects.
Reading this thread I'm disoriented. There are 2 different topics being discussed here, which should be 2 different proposals. Both of them good ideas, mind you. Is this about editor-wide plugins (not in project folder) or about managing plugins (make adding them to projects easier)? The original issue seems to be about latter, but most comments seem to discuss the other. The title is ambiguous.
You get this because "automatically adding plugins to a project" covers those domains. A plugin added automatically to the project acts somewhat like a "global editor plugin" with how Godot handles this at the moment.
So when will this be resolved? It's been two and a half years...
There is no ETA for implementing proposals, as contributors work on a best-effort basis. In any case, this will only be tackled after 4.0 is released, since it's in feature freeze now.
One thing not mentioned is that if you're using a plugin in multiple projects, and you are also actively developing said plugin, it is currently very difficult to keep it up to date in all the projects where it is used. In general, a plugin should NOT be in the source tree, especially if version control is used.
Since @Calinou used npm as a (bad and incorrect) example, I will too. When you have a dependency in node.js, you only specify where to get it from in the package.json. It does not become part of the source tree, and if you use Docker than it doesn't even become part of your directory tree.
The way addons are implemented currently is really the worst of all worlds. It's a recipe for tons of code duplication, and versioning nightmare.
When you have a dependency in node.js, you only specify where to get it from in the package.json. It does not become part of the source tree, and if you use Docker than it doesn't even become part of your directory tree.
Once you run npm install, you have the dependency's code sitting in node_modules/. It just happens to be a folder that is usually .gitignore'd, as npm install can essentially recreate the same directory structure (with lockfiles).
Nowadays, there's a strong preference in the Node.js community to declare developer tools dependencies within package.json (such as linters and formatters), instead of using global installation. These tools are then run locally using npm scripts, which use the version exposed in node_modules/.bin first if available. So this is actually the opposite of what's proposed here, technically 🙂
@Calinou
Once you run
npm install, you have the dependency's code sitting innode_modules/.
Unless, as I've mentioned, you're a sane person using Docker, in which it doesn't, it only sits in the transient virtual drive, until such time as you run the build script again. And you really need that extra layer of safety ever since version 6 or 7, where they added non-disablable auto-prune, and actually ended up deleting a package I was developing without asking for confirmation, which only really makes npm a really bad example for anything related to good design past versions 4 or 5 (Although it's a great example as to why open source projects have a non-warranty clause in their license). As it is now, it's only usable in a container or with -g.
By contrast, node.js itself has always checked the entire directory ancestry for any parent with a node_modules folder in it, so you can just as easily put /node_modules (or c:\node_modules) and use it in all of your projects. Which I've actually done. So even -g is not needed.
The fact remains that npm at least auto-pulls dependencies, which Godot doesn't, so even if you accept tips from npm, Godot's current incarnation is still an incomplete system. If you do add a sharable dependency list to a project, there becomes largely zero reason not to de-dup installations, by installing all addons in a common folder, but only activate a selected set. So either way, it's just another point for central installation folder over installing in the project folder.
The one part where I feel there's an issue, is if there are scripts or resources in the addon that might be used at runtime, e.g. scripts for custom controls. The system would need to know that these need to be added to the project. However, I feel like the current way is simply "wrong" in the opposite direction - Instead of including too little, it includes too much. There's no reason why an import script should be packed in your project's runtime. IMO, files actually being added to your project from an addon should be opt-in. As in, by default, the addon only works in the editor, and specific scripts and resources needed at runtime are marked as such by the addon's configuration.
Even better if a different version was applicable for runtime vs edit time, so various features that only make sense in the editor (e.g. Saving whether x and y editing are locked together or set to be separately editable) could be stripped even from custom components, but that's a separate subject.
I made a similar proposal for this problem #6350 (and since mine was a duplication I closed it) My proposal is a little bit different than this one, instead of putting information about the global add-ons in any project file, I propose storing global plugins in the config folder, and storing the addons in the editor-settings.tres
