No exact replacement for gdscript @onready ?

[Goldenlion5648]

I wanted to use lua instead of gdscript for this project, and before I was able to do

@onready var tiles_holder: Node3D = $tiles_holder

but since "@ onready" can not be used in lua, the best I was able to do was use get_node inside of _ready

local lua_testing = {
    extends = Node2D,
}
local first_child

function lua_testing:_ready()
    first_child = self:get_node("first")
    print(first_child)
end


return lua_testing

while this works, it is annoying to not be able to set the variable value at the top where I first declare first_child. Is there something I'm missing?

[gilzoide]

Hey @Goldenlion5648, thanks for the question.

Right now, no, there is nothing like @onready in Lua scripts, setting the property in _ready() is the way to go for now.

We could implement something like it in Lua, but the 100% generic version wouldn't look too good. The first thing that comes to my mind would be defining a property wrapper with a function that would return the wanted value:

lua_testing.first_child = onready(function(self) return self:get_node("first") end)

Using _ready() still seems cleaner to me.

Another option would make a version of "onready" that works only for getting nodes, something like this:

lua_testing.first_child = onready_get_node("first")

This looks much nicer and is easy enough to implement.

What do you think?

---

Oh, side note, you should probably use first_child as a property (self.first_child) instead of a top-level local variable:

local lua_testing = {
    extends = Node2D,
}

function lua_testing:_ready()
    -- you don't really need to declare properties in Lua, using them directly is allowed
    -- declare properties is only necessary if you need to export or set some metadata to them (like a default value)
    self.first_child = self:get_node("first")
    print(self.first_child)
end

return lua_testing

A top-level local variable as in your example is shared between all instances of your script. If a second instance sets a value to it the first one would now start using the second instance's child. This is most likely not what you want!

[Goldenlion5648]

Thanks for the advice on where to set the value of first_child!

Yes I think the second option sounds good