What is the difference between this two function -
await get_tree().create_timer(dance_time).timeout
and
get_tree().create_timer(dance_time).timeout.connect(dancing_timeout)
Or they both are same?
Timeout await vs connect
BirdaoGwra not looking at docs, if i understand Await
blocks code from executing below the await statement
With .connect
you can delegate the code execution to another outside function/method and continue to execute the script after the statement.
I suggest using .connect
to connect signals like timeout
to methods/functions
It means it works like timer node. Thank you.
BirdaoGwra i do it like this:
Double jump + coyote time
player.gd
var coyote_timer: Timer = Timer.new()
const COYOTE_TIME = 0.15
const DOUBLE_JUMP_TIME = 0.15
var jump_count: int = 0
var MAX_JUMP_COUNT = 2
func _ready() -> void:
coyote_timer.one_shot = true
coyote_timer.wait_time = COYOTE_TIME
add_child(coyote_timer)
func _physics_process(delta: float) -> void:
if Input.is_action_just_pressed("action_jump") and (is_on_floor() || (!coyote_timer.is_stopped() || jump_count < MAX_JUMP_COUNT ) ):
velocity.y = JUMP_VELOCITY
jump_count +=1
var was_on_floor = is_on_floor()
move_and_slide()
if was_on_floor && !is_on_floor():
coyote_timer.start()
if is_on_floor() and jump_count !=0:
jump_count = 0
Now this is the simple one that tracks mouse motion, and after no mouse motion it starts timer then after 1 sec reset. It changes the label.text to show the changes.
@onready var mouse_motion: Label = $Debug/VBoxContainer/MouseMotion
var timer = Timer.new()
func _input(event):
if event is InputEventMouseMotion:
mouse_motion.text = "Mouse_motion = true"
timer.start()
func _ready() -> void:
timer.autostart=false
timer.wait_time = 1.0
timer.timeout.connect(on_timer_timeout)
add_child(timer)
pass
func on_timer_timeout():
mouse_motion.text = "Mouse_motion = false"
You can see i have the outside function that does the change, and all the setting up is done in the _ready() function where you connect signals and add timers to tree
- Edited
BirdaoGwra await
is much harder to debug. Always opt to using regular signal connections if they can do the job. Use awaits only if you 100% know what you're doing. Two typical situations where await
is warranted is waiting for the current frame rendering to finish and custom generator coroutines. Never ever use await
in perpetual callbacks like _process()
I am using this in gun fire and reload. Not await but connect, like I mentioned above. For both player and enemy. Which I am calling in physics_process. I got a bit confused are they both same or different.
- Edited
BirdaoGwra They are not the same. connect
registers a signal callback that gets called when the the signal is emitted. It continues the current execution immediately. On the other had, await
suspends the current execution until the signal is emitted, effectively turning the function into a coroutine. If you don't know what I mean by "coroutine", you shouldn't be using await
at all.
Thank you for your explanation. Now my doubts are clear about await.
BirdaoGwra yeah i don't like using await
either. It can especially problematic if you use it in physics functions too. Stick with signals and connect
.
- Edited
Sometimes await is useful.
tween = create_tween()
tween.tween_property(panel, "modulate:a", 1.0, 1.0).set_trans(Tween.TRANS_EXPO)
await tween.finished
...
# code that needs to wait for Tween to finish before running
This is in the main thread, but not in a callback.
In this case, there's nothing for the user to input while the Tween is running, so the delay doesn't matter.
- Edited
My favorite way of using awaits is for lazy generator coroutines. People are often unaware that await can await for any custom signal, not just built in engine signals. This lets you implement all sorts of generators in an elegant fashion where you can do stuff in a loop that gets suspended until the consumer of the generated data sends a "need more" signal. A while back I posted this simplified example of an orc generator that demonstrates this: https://godotforums.org/d/37689-modular-state-machine/18