Jayjader

@Bezier yeah it's good to know about the differences between Object and RefCounted when you're making custom data containers.

Personally, I've been suffixing my custom/"game object" resources with "-Rs", as in I have PlayerRs, FileRs, DownloadRs, etc.

The namespace pollution is definitely part of the trade-off from just preloading wherever you need the class.

@ICastFist also yes, the docs aren't that great at providing info on this in the reference.

There *is* a good page in the manual, however: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html

OP @Bezier you probably want to check this out if you haven't found it already by now, specifically the "Custom variable types" section.

@ICastFist more or less, but you still probably want your Anchor to extend something, be it Object, Node, Node2D, Control, etc.

If your anchors are going to be part of the scene tree, as in you're adding them as node children of (an)other node(s), then you will need to at least extend Node. If you want your anchors to have a position, then Node2D (or 3D depending on how you need it to behave). If your anchors are part of your ui, then Control might directly be the best, and so on.

If your anchors are not going to be part of the tree itself, but just stored and/or passed around by nodes as data, I would encourage you to give this page of the docs a read: https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html

@ICastFist @Bezier I agree with your overall explanation, but I would instead recommend using the class\_name directive instead of adding it as an auto-load.

Auto-load will make it that a single Anchor instance always exists in the root scene, and that Anchor elsewhere in your code will always reference that single(ton) instance.

If you want Anchor to behave like other built-in classes in your scripts and the editor, you need to give it a class\_name and *not* use the same name ("Anchor") for an auto-load.