I wish I could rattle off a trite list of labels here, but I’ve never found a satisfyingly short list that covered me.
I like political discussions that revolve around how to make the world better. I like learning underlying and/or fundamental truths about the universe we find ourselves in. I like art; as an artist, as an audience member, as a stage hand. I like computers and how they empower us to more freely manipulate information and send it back out into the world.
I like forests.
@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.
@Lmaydev @crittecol I don’t know enough about the internals of other engines, but Godot by default caches the result of draw calls. It’s up to you the dev to signal to the engine that a node has changed and needs to be redrawn. Of course, this is done for you by the engine for existing built in properties, like label text.
All this to say, unless you are changing the contents of your label each frame, it is not getting drawn 60 times per second.
@plixel @Rodeo generally I setup “horizontal” signal connections inside nodes’ _ready() methods, to minimize get_node() calls.
But really, do whatever works for what you’re trying to accomplish. There are too many different ways to accomplish the same “thing” for there to be a real ‘recommended use’ for signals. Technically you don’t even need them, you can always grab a node and call one of its methods. It’s just that in some cases, it’s easier to manage as a signal (especially if you prefer to do things via the Godot editor UI over writing code).
@mathilde qu’est-ce que ça fait du bien de voir une prise de position aussi large et publique dans ce sens