Why is infinty tweening within a sequence not allowed?

[kyubuns]

I have written code where the transform appears (Scale = 1) and then keeps moving between 100f and 0f.

var sequence = Tween.Scale(transform, startValue: 0f, endValue: 1f, duration: 0.4f)
    .Chain(
        Sequence.Create(-1)
            .Chain(Tween.LocalPositionX(transform, endValue: 100f, duration: 1f))
            .Chain(Tween.LocalPositionX(transform, endValue: 0f, duration: 5f))
    );

// ~~~

sequence.Stop();

Executing this code will result in the error It's not allowed to have infinite tweens (cycles == -1) in a sequence. If you want the sequence to repeat forever, SetRemainingCycles(-1) on the parent sequence instead. .

The behavior of this code is exactly as I envisioned.
Why is there an error? Is there a correct way to write the supposed?

[KyryloKuzyk]

Hi, thanks for the question!

This was a design decision not to allow infinite tweens inside sequences. In your particular use case it looks reasonable, but there are many other corner cases when an infinite animation inside the sequence would not make sense and will break other things. For example, if infinite tweens were allowed inside sequences:

• All these APIs would return infinite values, which can easily break any user's code that relies on them: sequence.progress/progressTotal/duration/durationTotal.
• Using Sequence.Chain() would not be allowed because the insertion point would be unknown (infinite).
• Using Sequence.Create(cycles: numCycles) or sequence.SetRemainingCycles() would not make sense.

To sum up, all tweens and sequences in PrimeTween should have a defined duration. Infinite animations can only be achieved with -1 cycles, but the duration of one cycle should not be infinite.

As a workaround for your case, you can set some big value to the nested sequence with Sequence.Create(int.MaxValue). Or you can create this infinite sequence from the OnComplete() callback of the scale animation.

[kyubuns]

Thanks for the explanation!
That totally makes sense now.
I think I’ll just go with the int.MaxValue workaround to avoid the issue.