On namespaces, addon dependencies, and common functionality

[theraot]

I'm aware of the risk of allowing addons to have dependencies. And I don't just mean a matter of trust, but instead that dependencies can grow hard to manage. An scenario I won't rather not have is having two addons that depend on a third addon, but different versions of that third addon.

However, I wish I could author addons that depend on other of my addons. That is because they need similar functionality that I'd wish I didn't duplicate.

---

So, deploying my addons on my projects became an issue. Since I didn't want to duplicate code, instead of them working out of the box, they would fail telling me I need another addon. Which is particularly annoying when the addon is a plugin.

That let me to rethink their design, accept some duplication, and specialize the code when possible. After all, the duplicated code had to be general, and that introduced some unnecessary complexity in the code. Plus, you cannot beat the usability of simply copying a folder.

---

However, there is duplication. So there are classes that exists in different addons, but I don't want conflicts between them. Currently their names are prefixed with the name of the addon. This has let me to a desire for namespaces. I'll be refactoring to use preload so I can leave the classes anonymous.

---

This all, of course, would not be a thing, if this duplicated functionality was part of Godot core. In fact, I believe the back and forth between not duplicating code and duplicating means that what is left would actually be useful.

Here are some of the duplicated things:

• func update_array(current:Array, updated:Array, added:Array = [], removed:Array = []) -> void

  This is a method that takes an array current that will be modified to math the contents of the array updated, and the added and removed arrays will be populated according to the changes made to current. The order of the elements is not guaranteed.

  I use this method in two places:

  • A plugin that does code generation. It has monitors the files of some folders, and generate code based on the list. The gist of it, is that I don't want to remove all the generated code and build it all again every time there is a change, instead I want to work only on what changed.
  • An addon that keeps track of the objects that are between the player character and the camera with the intention of changing their materials. This is based on raycasts, and will be running every frame, and similarly here I want to work only on what changed.

• Promise

  This is a class with completed, succeeded, and failed signals. It has an status property that can take three values: Running, Succeeded, or Failed, once it changed it cannot be changed back. Changing the status it will trigger the appropriate signal, but deferred. The class is RefCounted and will increase its reference count by one when created, and decrease it back when the status changed.

  I use this class in two places:

  • An addon that can play multiple audio streams, and has an API that returns Promise instances that allows to yield on their completion. These can fail if the audio stream is invalid.
  • An addon that handles requests to move a character to a particular location, and again has an API that returns Promise instances. These can fail is the path of the character is obstructed.

  (I have more planned uses for Promise, but this is it so far)

• get_damp_factor(time:float, delta:float)

  This is for frame independent damping. It takes the total time it should take to converge (within a hard coded epsilon), and the elapsed time since the last iteration.

  I use this method in three places:

  • An addon that implements my own take on InterpolatedCamera, except it is frame rate independent and I has predictable convergence time.
  • An addon that implements the opposite of RemoteTransform, it is the opposite in that my code pulls a transform instead of pushing it. And it is frame rate independent and I has predictable convergence time.
  • An addon that implements a character controller, and it uses it for rotations, both facing towards the requested direction and aligning the character with gravity.

• Some Quaternion methods:

  • quaternion_between_vectors: Basically Quaternion(axis, from.signed_angle_to(to, axis)), but can pick the axis if ZERO is provided (which is basically cross, but we also need to handle when that yields ZERO), and the resulting quaternion represents the rotation the short way around.
  • quaternion_from_basis: Basically get_rotation_quaternion, and the resulting Quaternion represents the rotation the short way around.
  • quaternion_scale_rotation: Converts the Quaternion to axis-angle, scales the rotation, wraps it, and converts back.
  • build_transform: Builds a Transform3D from a position Vector3, a Quaternion rotation, and a scale Vector3.
  • build_basis: Builds a Basis from a Quaternion rotation, and a scale Vector3.
  • quaternion_twist: Computes the twist of a Quaternion around an axis.
  • quaternion_swing: Computes the complement of the twist (see swing twist decomposition).
  • alignment_quaternion: Takes two Basis and a Vector3 and returns the rotation that needs to be applied to the first Basis to make the Vector3 on both Basis match.

  All of these methods check for infinite vectors, nans, and check if a vector is approximately zero before normalizing it or projecting on it. The fallback is easy: IDENTITY. Furthermore, they will never result in an infinite Quaternion, Basis, or Tranform3D. I have been incorporating all these checks because - as you would surely know by now - division by zero, unexpected results when normalizing vectors that are almost zero, and some bug with physics sometimes giving nan positions and velocities. I also wrote them aware that a Basis can be zero. Which - by the way - can happens if you are interpolating the scale to a value with different signs.

  By the way, I suppose get_axis is correct for whatever you are doing with animations or whatever it is. But I ended up not using it because it gave me unexpected results.

  I use these methods in a three places:

  • The aforementioned addon that implements my own take on InterpolatedCamera. Although it does not use very listed method.
  • The aforementioned addon that implements the opposite of RemoteTransform. This in particular has multiple modes for handling the rotation.
  • The aforementioned addon that implements a character controller.

I also have methods that handle vectors and have similar checks (against nans, infinity, and also against zero when normalizing or projecting), but I have been able to keep these local, which is why I'm not including them here.

• I also want a couple methods to work with Nodes:

  • A method to find a parent given its class. Similar to find_parent.
  • A method to find a child given its class. Similar to find_node.

  These should be able to handle custom classes. As a result of avoiding duplication, my code for this ended up specializing for the class they search for. The purpose of these methods is to ease connecting references to other Nodes in tool scripts (which are using NodePaths until the fix for Node exports is released) so that I need to do less clicking. In particular when the thing I need to connect is inside of another scene, these can save me the trouble of enabling editable children.

---

To recapitulate:

• A dependency system could be good, it also could be bad. I would suggest limiting it to only addons by the same author to minimize dependency hell. And I suspect that makes it less attractive.
• Namespaces could be useful too. Although, I could be using preload instead of using class_name, and avoid polluting the global namespace that way.
• I have found some methods and classes that might be added to core. But, actually they are not too hard to implement in GDScript. Which is an argument to not have them in core.

Thus, I have nothing. But, still... Would people be interested in any of this? Would it be a good idea to write a proposal for some of these in particular? I don't know.

[Calinou]

A dependency system could be good, it also could be bad. I would suggest limiting it to only addons by the same author to minimize dependency hell. And I suspect that makes it less attractive.

This kind of limitation sounds difficult to enforce but also quite arbitrary. If we introduce any intentional limitation, it would probably be better to limit the maximum depth of the dependency tree to 1 (or 2 for entire projects distributed on the asset library). This means an add-on can depend on another add-on, but you wouldn't be able to have an add-on that depends on an add-on which in turn depends on another add-on.

That said, I think this kind of limitation would mostly be about limiting the engine's implementation complexity. People are already wary about npm-style one-liner dependencies nowdays, and it's not something I see quite as often as before in modern programming languages like Rust (or even JavaScript/TypeScript with Deno – also because Deno comes with a larger standard library).

[donn-xx]

It's an issue I have also run into recently. I am writing two addons in gdscript and one is much easier to use when the other is installed. I am being as careful as I can trying to make them independent, but I can't develop the first without the second.

I am wondering how to release the addon because it will say "For better functionality, please also install XYZ".

I get that Godot is not Python/etc. and it's only as lean as it is because it's cutting a lot of, frankly, quality-of-life functionality. I don't know how to solve the paradox: do we add nice-to-haves (and get bigger) or do we leave the issues to the end-dev and let them reproduce code all over the place?