await not moving on when tween is done

[chancemcdonaldsims]

Tested versions

development branch of 4.3

System information

Windows 11 custom build of 4.3 with production=yes

Issue description

when using "await tween.finished" it never moves on when finished is emitted.

Steps to reproduce

try to await on a completion of a tween

Minimal reproduction project (MRP)

#this doesn't work
await _player_controller.get_tree().create_tween().tween_property(attacking_creature, "global_position", end_position, .5).finished

#this works.
_player_controller.get_tree().create_tween().tween_property(attacking_creature, "global_position", end_position, .5).finished.connect(
            func():
                print("bang")

                _player_controller.create_tween().tween_property(attacking_creature, "global_position", start_position, .5).finished.connect(
                func():
                    print("finjished")
                )
        )

[adamscott]

@chancemcdonaldsims For the next time, please note that we ask for a "minimal reproduction project", not a code snippet.

[chancemcdonaldsims]

honestly this is a an bug that should be detected by automated testing. It is very hard to use an engine where basic functionality breaks often. I reported that basic functionality is broken don't ask for more of my time with creating an empty project with one script and one line of code added to demonstrate that a feature is broken. I provided enough information to convey what is broken. I think W4 got 14 million in funding why not put 1 person on automated testing.....

[Calinou]

@chancemcdonaldsims I have to remind you that we have a Code of Conduct. Please stay constructive.

Note that the code sample you posted doesn't work on its own, as it depends on various properties that are not present in the code sample (_player_controller, attacking_creature, start_position, end_position). This is why we ask for a complete minimal reproduction project that can be run on its own, as it greatly speeds up troubleshooting.

[MrRevington]

ftr this works quickly tested on my machine with v4.3.rc1.official [e343dbbcc] on windows 11, but i don't have n MRP sorry.

var end_position : Vector2 = Vector2.ZERO
var start_position : Vector2 = Vector2.ZERO

func _ready() -> void:
    start_position = global_position
    end_position = global_position * 2

    print("tween start")
    await get_tree().create_tween().tween_property(self, "global_position", end_position, 5).finished
    print("tween end")

[chancemcdonaldsims]

@Calinou I am going to have to remind you of the Code of Conduct and assume that I have positive intent. Telling people that are helping identity issues with your YOUR PRODUCT aren't filling out bug reports correctly doesn't not make people happy. Do what you want I don't intend on using Godot further.

[huwpascoe]

honestly this is a an bug that should be detected by automated testing.

Godot does have automated testing, it's part of the build process?

I provided enough information to convey what is broken.

The snippet provided falls just short of "enough" and recreating the issue then becomes guesswork, like with Mr.Revington's example where the bug couldn't be reproduced. And if the bug can't be reproduced, it'll never be fixed and your time will only have been wasted further.

Telling people that are helping identity issues with your YOUR PRODUCT aren't filling out bug reports correctly doesn't not make people happy

They could've worded it more politely perhaps.

Do what you want I don't intend on using Godot further.

May you find a better suited product.

[chancemcdonaldsims]

@huwpascoe automated testing is clearly not testing basic functionality well enough to find major errors. This is a common problem with Godot that I have faced over the years. Even math libraries I have issues with. C# support is a joke at times. I ran into an issue that persisted over several minor versions of Godot where setting parameters on animation tree wasn't possible in C# because the bindings were not correct. Calling get and set was trying to set properties on the Node and not in the parameters. Resulted in weird errors that cost me hours of my life. Worked fine in gdscript but not C#. Was eventually fixed but required moving large sections of code to gdscript and eventually the entire project.

Godot is the best open source game engine however it isn't good enough or bug free enough to consider for any major project. I have had major issues with rendering and shadows and often changes that improve 3D rendering tend to break VR support. Better testing could probably help with bugs and new "features" breaking other parts of the engine but honestly one major issue with all open source game engine is that developers and the community seem to care more about pronouns then game engine quality.

Yes I know all software has bugs but open source game engines are fairly bad with fixing and preventing them. You would think that a model that allowed 1000s of contributors to work on a large project would invest more resources is verifying quality of contributions and impact on engine like .... extensive automated testing

[huwpascoe]

I understand your frustration, and anyone else experiencing the same simple problem: why can't it just work?! It takes so much more effort than should be necessary to affect a positive change. It's enough to drive some people crazy. We sure do live in a society.

Maybe I'm just getting old, but I don't have the same expectations of projects like this that I once did. There's a number of issues that I've come across, some I've reported, others I've just made my own fix and not bothered to share, and not out of malice, lack of energy (chronic illness is a b*tch). And if I do report, I like to make the MRP fun to test 'cause it takes some of the mental load away for the contributers.

What I do like about Godot is it's genuinely, slowly, getting better, and the community is despite having the usual problems, is generally positive and listens. Companies like Unity or Microsoft, you have an issue, a bot says "thank you for your feedback" and the only community responder deliberately misunderstands the topic so they can give a completely unrelated answer. I'm quite glad to be able to get an answer for any issue, even if it's not the answer hoped for.

[akien-mga]

This has veered into full off-topic and ranting, so I'll have to step in and lock this discussion as it's not productive on a bug report. I also note that the OP was reminded of the code of conduct already and doubled down on unproductive ranting.

For the record, Godot is a project run by volunteers and a handful of paid developers. With such limited resources, it's expected that users find and report bugs. There is some automated testing, but like all things it's a work in progress and doesn't catch all issues.

Like in all community driven open source projects, users are prosumers and can choose to participate in the testing effort by reporting bugs with clear reproduction steps. They don't have to do this if they don't want to, but that doesn't make it less of a reality of open source development. Whether or not one does the effort to participate in the open source workflow, it doesn't give people the right to act entitled and bossy when they use an open source product for free.

As for the actual bug being reported, it's probably still worth looking into. But this needs to be tracked in another bug report with a proper reproduction project so that the bug can be confirmed, and then fixed.