i’ve created a UI scene with an @onready var which is a reference to a grandchild node. The UI root node is receiving a signal before the @onready var has been initialized. Side note: is this behavior intended or a bug?
Anyway, i’ve worked around the problem this way (update_shield is the signal callback):
func update_shield(max_value, value):
while not shield_bar:
print('waiting for shield bar')
await get_tree().create_timer(.1).timeout
print('found shield bar')
shield_bar.max_value = max_value
shield_bar.value = value
Like expected, the console gives me this at the start:
waiting for shield bar
found shield bar
Obviously, this doesn’t seem to be a clean approch, so my question is: is there something like this pseudocode
await self.is_ready
i could use to solve the problem in a cleaner way?
Thanks in advance for your time.
Regards,
Normen
PS: thanks for maintaining and supporting this great game engine!
Thanks for your input, @zdrmlpzdrmlp. But this would mean i had to prefix every emit() like this if there’s a chance that the receiving node is not ready, doesn’t it? Shouldn’t there be a cleaner solution to this?
i dont know how you made it so that the signal has to be emit in quick manner before the whole nodes is parented in the tree. if it’s to tell update shield from main core game to the UI node, usually it needs to read from save file, get the variable, then emit the signal to update the UIs, it’s definitely not when the main core game _ready, emit_signal to update UI
curious where do you emit the update UI signal
Main
-- ...
-- Player
-- ...
-- CanvasLayer
---- UI
The signal that’s being received by UI is emitted in Player._ready() so it seems pretty clear that there’s no guarantee that the UI node is ready. My fault was to expect that signals will only be dispatched to nodes that are ready, i guess.