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?

    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

    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

    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.

    • xyz replied to this.

      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.

      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.

      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.

      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