Equivalent for await $SomeTimer.timeout?

[WHMHammer]

I am following the Godot "Your first 2D game" tutorial. Part of the logic is to wait for a timer to timeout to proceed to the next step. Below are the GDScript codes:

func show_game_over():
    show_message("Game Over")
    # Wait until the MessageTimer has counted down.
    await $MessageTimer.timeout

    $Message.text = "Dodge the\nCreeps!"
    $Message.show()
    # Make a one-shot timer and wait for it to finish.
    await get_tree().create_timer(1.0).timeout
    $StartButton.show()

However, I did not find any equivalent function in the godot-rust Timer documentation. I also checked the example codes in this repo, which does not have this wait for timeout logic at all. The same issue exists on SceneTreeTimer.

What are the equivalents for await $SomeTimer.timeout in godot-rust? Thanks!

[Bromeon]

This is not possible at the moment. It would need async support, which is unfortunately quite a pain in Rust.

gdnative supports it though, it looks like this:
https://godot-rust.github.io/book/gdnative/recipes/async-tokio.html

So maybe we can reuse prior art here, but it's not a priority at the moment.

[jrockett6]

@WHMHammer If you don't mind defining an extra #[func] that handles the awaited logic you can do this as a workaround for this particular case:

fn show_game_over(&self) {
    ...
    let mut timer = self.base.get_tree().unwrap().create_timer(1.0).unwrap();
    timer.connect("timeout".into(), self.base.callable("show_start_button"));
}

#[func]
fn show_start_button(&self) {
    self.get_node_as::<Button>("StartButton").show()
}

[Bromeon]

@jrockett6 that's actually a great idea. And in other news, I added Callable::from_fn() a few weeks ago, so you don't even need a #[func] but could technically pass any closure.

It's a bit more manual at the moment (you only get a variant slice), so #[func] might be easier, but eventually from_fn() should also support such signatures.

[WHMHammer]

@jrockett6 @Bromeon I created additional Timers in Godot editor and set their timeout handlers to the logics after the delays. Thank you for your alternative solutions though!

[musjj]

Shouldn't this stay open until we have proper async support?

[Bromeon]

@musjj There's #640 as well. But we haven't decided yet if we want to implement it.