godotengine / godotengine/godot
Node 'is_node_ready()' function and 'ready' signal do not function as expected with coroutines
- Dominant language
- C++
- Stars
- 117k
- Forks
- 26.8k
- PR merge metrics
- PR metrics pending
Description
### Tested versions
v4.2.2.stable.official [15073afe3]
### System information
Godot v4.2.2.stable - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce RTX 4070 Laptop GPU (NVIDIA; 31.0.15.3210) - 13th Gen Intel(R) Core(TM) i7-13700HX (24 Threads)
### Issue description
When waiting for a node to be ready, the 'ready' signal will fire before the _ready() function finishing, if it is a coroutine. Same issue is present when we check if a node is ready via is_node_ready.
In my opinion (and what I would expect would be the case), nodes should not emit 'ready' until the whole _ready() function runs - even with coroutines - and a node's "is_node_ready" call should return false until the ready call finishes (even with the coroutines). According to the [docs](https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-private-method-ready), this seems to be the intended behavior (see 'ready' signal description).
Not 100% sure if this is intended behavior, but if it isn't, it would be nice to get a fix, and if it is, then I think the docs for the 'ready' signal and 'is_node_ready' function should clarify that.
### Steps to reproduce
Here is some simple sample code you can throw in any file and run:
```
extends Node
class CustomNode:
extends Node
func _ready():
print("CustomNode ready start")
await get_tree().create_timer(1).timeout
print("CustomNode ready end")
func _init():
ready.connect(_on_ready)
func _on_ready():
print("CustomNode onready")
func _ready():
var custom_node = CustomNode.new()
add_child(custom_node)
```
Notice that "CustomNode ready end!" prints _after_ "CustomNode onready."
### Minimal reproduction project (MRP)
see sample code - not necessary to attach an entire project, just create a new one and throw the above in an autoload script
Contributor guide
Assessment
This issue has not been assessed yet.