Property initialization from scene file after ready

[qt911025]

Property initialization happens after "init" notification, otherwise "ready" notification if @export annotation added. These are for the init value which is written in script. For value which is set from a scene file, the setting always happens at "init", no matter whether there is an @export.

Consider a scenario that a property has a setter, which needs some data from its scene tree. Setting the property early before the scene tree ready is incorrect. Thus I add is_node_ready() assertion and wait for ready signal, so the setter becomes a coroutine. I don't know if making a setter a coroutine is a recommended way, and this is only for fixing the problem of scene initializing.

[theraot]

You can create a method for your post initialization and call it from _ready. Then your properties setters can decide if they will call that method depending on is_node_ready.

The pattern has an extra wrinkle if you want to support having a node leave the scene tree and reenter: request ready.

So, it ends up like this:

@export var property:String:
    set(mod_value):
        if property == mod_value:
             return

        property = mod_value
        if is_node_ready():
             _update()


func _ready() -> void:
    _update()


func _exit_tree() -> void:
    request_ready()


func _update() -> void:
    # compute here
    pass

Note: this is from one of my answers at stackoverflow: When are @export values set?.

I find that it makes sense to have different _update methods (with different name, of course) for different properties, but also sometimes it makes sense that multiple properties share the same _update method.

I'm not saying that this is ideal, but that this is how I handle it currently. Of course, this pattern highlights a deficiency in the language, so if you have some idea of how to change things for the better, you are welcome to open a proposal.

See also:

• Make lazy loading of nodes easier with a dedicated function or real callables as getters #9935 (there is a variation of the above pattern in comments there)
• Implement onready setters #325 (I imagine this would use an annotation if implemented these days, but I see no discussion about that, it seem priorities are elsewhere)