Feature discussion: why is there @onready but no @oninit?

General
1

This comes from a scenario that keeps bugging me: often times after instantiating a scene, I’d want to set it up first with some parameters before adding it to the scene tree. But then I would quickly realize all my pointers to node in this shape @onready var label :=%Label are still uninitialized, causing null pointer error. I’d just have refer to thse nodes using their nodepaths or unique_name. So why did Godot goes with @onready but never had an @oninit?

1 Like
2

For that you have the globals (singletons). They are running before all other nodes. IMHO most of the time onready is the right time to do things. But maybe it’s only my opinion. Could be a good request.

3

@oninit is implicit. If you do var foo = 1 the assignment happens right before _init() is called, just like @onready happens right before _ready().

2 Likes
4

for simple variant yes, but when referring to nodes in a scene tree that fails with sth like “Error at (13, 1): The default value uses “$” which won’t return nodes in the scene tree before “_ready()” is called. Use the “@onready” annotation to solve this. (Warning treated as error.)” In the end this could be solved by simply doing the node assignment in _init(), but that still doesn’t answer why is there @onready but no @oninit. Shouldn’t it be a better replacement?

1 Like
5

No it couldn’t because at the time _init() is called the node is not in the scene tree.

You’re confusing the concepts. @onready isn’t some magical thing that gets nodes. It just tells the engine to postpone doing the assignment until just before _ready() is called.

4 Likes
6

Because weird stuff will happen.

You’re probably used to using constructors, which is technically what _init() is. Except that the Godot engine has a specific creation order, and the fact of the matter is that paths cannot be resolved until the object is added to the tree. That’s why @onready variables cannot be accessed during _ready(), because technically they are determined right as the object enters a tree - at the exact same time _ready() is running.

So @oninit would never work because initialization finishes before the node is added to the tree.

_init() really shouldn’t be used - as convenient as it seems to be, because there are a lot of gotchas that will bite you when you try to do things like update a node’s position in it.

2 Likes