subsequent tweening of the same property

[debris]

I have the following pieces of code. One of them (A) - DOES NOT work as expected, and the other one (B) - DOES work as expected. I do not understand why.

The only difference between them is calling commands.entity(card).animation() vs commands.animation().

code A

fn on_fix_card_positions(
    _trigger: On<TweenEvent<FixCardPositions>>,
    mut commands: Commands,
    player_cards: Query<(Entity, &Transform), With<PlayerCard>>,
) {

    for (i, (card, transform)) in player_cards.iter().enumerate() {
        let target_translation = Vec3::new(-160. - (i as f32 * 80.), 0., 0.);

        
        commands.entity(card).animation()
            .insert(sequence((
                forward(Duration::from_secs_f32(CARD_ANIMATION_TIME * i as f32)),
                tween(
                    Duration::from_secs_f32(CARD_ANIMATION_TIME),
                    EaseKind::Linear,
                    card.into_target().with(translation(transform.translation, target_translation))
                ),
            )));

code B

fn on_fix_card_positions(
    _trigger: On<TweenEvent<FixCardPositions>>,
    mut commands: Commands,
    player_cards: Query<(Entity, &Transform), With<PlayerCard>>,
) {

    for (i, (card, transform)) in player_cards.iter().enumerate() {
        let target_translation = Vec3::new(-160. - (i as f32 * 80.), 0., 0.);

        commands.animation()
            .insert(sequence((
                forward(Duration::from_secs_f32(CARD_ANIMATION_TIME * i as f32)),
                tween(
                    Duration::from_secs_f32(CARD_ANIMATION_TIME),
                    EaseKind::Linear,
                    card.into_target().with(translation(transform.translation, target_translation))
                ),
            )));

How to reproduce the problem? and what is the problem?

1. I trigger FixCardPositions event for the first time. Everything works as expected. Let's call it Animation 1.
2. Sometime later, long after the animations finished executing, I trigger FixCardPosition event again. Let's call it Animation 2.
3. if code A is executed, some weird glitches appear. Triggering FixCardPosition the 2nd time, sometimes trigger Animation 1 to run again, and then Animation 2. Sometimes the animation does not happen at all. And sometimes the Translation is simply set to Vec3::ZERO.
4. if code B is executed, none of the glitches appear. The animation is always consistent and behaves exactly as I expect.

The only difference between the two is calling commands.entity(card).animation() vs commands.animation(). Am I missing something here? Or using the crate incorrectly? Also, are finished animations ever pruned? It seems like calling commands.animation() pernamently adds child objects to the world

[Rabbival]

Hey there
I'm not home so I'm answering from my mobile device which is... less conenient.
I think issue you're describing as well as the animation entities not despawning can both be solved with the bevy_tween_helpers crate (sounds to me like there are multiple ongoing tweens affecting the same entity)
Also for card mechanics implementation using bevy_tween you might want to look at the bevy_play_card crate

Let me know if it helps
And sorry for the messy answer, I should be back at my computer tomorrow

[debris]

HI @Rabbival , thanks for the reply.

I think issue you're describing as well as the animation entities not despawning can both be solved with the bevy_tween_helpers crate

Thanks! I will look into it. Although, I would prefer to not install another crate, to solve a problem with this one.

sounds to me like there are multiple ongoing tweens affecting the same entity

the tweens already finished their execution, and I believe they should be pruned afterwards, without the need to use another library.

Also for card mechanics implementation using bevy_tween you might want to look at the bevy_play_card crate

I will check it out, thanks

[Multirious]

Implementing despawn system for tweens is simple, here's one such code:

fn despawn_finished(
    mut commands: Commands,
    mut time_runner_ended_reader: MessageReader<TimeRunnerEnded>,
) {
    for t in time_runner_ended_reader.read() {
        commands.entity(t.entity).despawn();
    }
}

Animation entities not despawning is rather by design, for the current moment at least.

rationale

The current design/intend for the bevy_tween crate is that you'll largely uses it for tweens creation, and the crate is designed to be additive, and so tweens are not pruned by default unless specified. This is largely due to the fact that the crate does not currently assume what the user is going to do after the tweens are created.

• Reused using the same components by reactivating the animation?
• Delete and respawn?
• What if the animation components also exists in the same entity it is tweening?
• Or are they planning to use a state machine? Maybe some whole other pattern specific to their game?

Though, I understand that it could be argued that having the tweens pruned by default might be the most intuitive behavior. But I just don't have the data to support it. I have seen some animation library that also just keep the animator that had already been spawned, inside and outside of Bevy, which could argue the opposite. So, it's just not planned at this moment for it to be in the main crate.

bevy_tween_helper, is exactly "what do you want to do after the tweens are spawned?" in a collection. If you feel that it's bloated for having to pull in additional dependencies, that's fine.

imo

I don't think it's the same story as other language like C++, where having additional dependencies is a huge security and maintenance concern. Cargo and Rust does this very well where it's rather not that big of a deal (also cargo-audit), unless having a few extra lines of Cargo.toml causes some mental burden, or that crate is actually too damn big (which I don't think is the case here). It's your preferences! That's alright!

You can commonly see that crates in Rust like separating some parts into crates just for separation of concerns. There's really not much downside for completely moving code from a module into a separate crate as dependency, in fact, sometimes Rust compiles faster that way (Of course not for crate with direct dependency). rand for examples, have rand_core. bevy is just an umbrella for many crates packaged together nicely. bevy_tween has bevy_time_runner inside, and thus, bevy_tween_helper for other optional stuff, just haven't been packaged nicely into the main crate.

[debris]

Thanks! I understand your rationale. Manual despawning using MessageReader works as expected.

But I've noticed another problem here if I want to use On<TimerRunnerEnded> to despawn the tween.

fn despawn_finished_tween(
    ended: On<TimeRunnerEnded>,
    mut commands: Commands,
) {
    commands.entity(ended.entity).try_despawn();
}

causes undefined behaviours. Some animations are cancelled and reset to the starting position, while some others are finished.

I guess it's because of the order of execution of those 2 expressions. commands.trigger is always executed immediately, while messages are processed in the next update.

https://github.com/Multirious/bevy_time_runner/blob/bc301bfaa9f189cd24f6948090b9df1326ae5fd5/src/time_runner.rs#L440-L441

                commands.trigger(event.clone());
                ended_writer.write(event);

[debris]

On the afterthought, a generic:

fn despawn_finished_tween(
    ended: On<TimeRunnerEnded>,
    mut commands: Commands,
) {
    commands.entity(ended.entity).try_despawn();
}

is also not the best approach, because of how animations creation api looks like currently. It works well if we initialize the animation like this:

commands.animation()

but not like this

commands.entity(card).animation()

in the first case TimeRunner is added as the child, in the later, as component.

The easiest solution to this, would be to always add TimeRunner as a child of entity. What do you think about this @Multirious ?