Addons

Using Addons

Addons in Godot are managed in a simple way. They are zip files that are uncompressed usually in the root directory. You can either use the Asset Lib tab or just download a zip and import.

Creating

What's wrong about Godot addon system

First of all, what is good

We all love and hate Godot's addon system. On one side it has many benefits:

• Many plugins available
• Power: you can do many things with plugins
• Flexibility: Being the editor a Godot application itself, plugins can modify its guts
• Same set of skills: Being the editor a Godot application, you use similar skill to create plugins than to make games.
• Simplicity for plugin developer: no installers, no configuration, no... well indeed, from this simplicity for the developer it has become hard for plugin users.

So, lets talk about what can be improved.

File layout and plain file dump installs

Because installing a plugin usually means dumping the zip over the root of your project this often ends up in overwritting user files. There is no standarization so some plugin developers use a zero level layout, while others follow the suggestion of creating addons/myplugin. But even if they follow that suggestion, if users forget to unselect the rest of direactories, they will end up overwritting their README, LICENSE and project.godot files which are files that exist on every project.

Many addon developers explain what users have to activate and deactivate from the zip and where to put it in. Still this is error prone and also many addon developers don't do that.

Two derivated problems also arise:

• Asset developers have to duplicate some stuff in their project root and in assets/myplugin: README, LICENSE... if they want to be present in end projects. Indeed plugin.cfg metadata is quite similar to the one in project.godot. Maintaining duplicated metadata is APITA.
• There is no convention about examples/demos directory, documentation... and other directories that users may want to install along addons directory.

Resource reallocation

Because there is no namespaces, and plugins refer to the root of the project likewise user files, depending on how users install the plugin, it may not work. scripts/classes, scenes... If resources are so dependant on its own location, the paths should be fixed in some way.

This can be softened by using relative paths for plugin components to refer each other. Now this strategy works well with files refered from scripts, but resources are written automatically by Godot using project root relative paths.

Name collisions

Same as path references and file locations, when you drop a plugin in an existing project, if the plugin defines class names, #references... they could collide with the ones in the project or other plugins. Several namespacing proposals try to address that.

git hosting

Because the plugins have to be phisically in the user project directory, developers follow different approaches to manage their repositories. Some create git subtrees of the plugin, others copy the directory.

My opinion is that plugins should be away at least from the repository. Replicating third-party code in a repository is a bad decission. In order not to replicate thirdparty code that could eventually diverge. with a clear automated specification on which are the dependencies and which versions to use.

Plugin identifier names

Plugins do no have a referable name. We have a db number for the asset which is indeed fragile, and hard to refer as dependency.

We also have the reponame (project-user/repo) and repo provider, which could be nicer but will give problems if eventually the project decides to switch platform.

A transition to a Asset Library unique names, could led to a name war and even malicious replacements. Basing the transition on reponames and prioritizing lesser addon numerical ids in case of collision (different projects or even git providers).

Categories

The current plugin categories are quite vage. It is hard to look for comparable plugins or being sure that the plugin you didn't found really does not exists.

Having together plugins for a same purpose could help to compare them. Materials, the behaviour of the player, the behaviour of enemies, the camera, visual effects, audio effects, environment building...

Proposal

• Addon metadata
  • Add a identificator name besides the human readable "title"
  • Improve the category system. Identify more useful categories.
  • Add dependencies to the plugin and to the project which could be different
• Dependencies management
  • Install should be user wide and inactive by default
    • Inactive should mean the project does not even scan them
      • Global project does and makes it unusable when you install big dependencies
  • The plugins should be installed apart from the project, in a user directory
  • Different versions of the same project should install side to side
  • Installation is not activation, activation should be project wise
  • Activated plugins and versions should be part of the project definition
  • Plugins should also have their own dependencies, maybe separated from the plugin project to discard development tooling
  • The project configuration should be able to detect installed and newly available versions, install them, activate them for the project and switch between versions
  • Each version of the addon should be installed
  • Only the directories becoming part of the distribution will be incorporated to the project.
  • I would prefer that those directories would be fully standardized to avoid collisions
    • assets/myplugin (enforce current recommendation)
    • examples/myplugin (optional install not in the current documentation)
    • docs/myplugin (not even mentioned, and i don't know really if required)
• Namespaces
  • Having a different root like res:// for addons and project files would not be necessary if the layout is standardized.
  • Still collisions may raise on classnames, #hashids, globals...
    • Local hashids to refer nodes within an scene not colliding with others
    • Namespaced classnames and globalsa
    • TODO: automatic plugin namespace? alias?