OnStop callback request

[donafudo]

Sorry if the text is difficult to understand as I am using a translator.

Thank you for your wonderful library. Very comfortable to use!

By the way, is there an OnStop() callback?
In my project, I am managing TimeScale for enemy animations, UI animations, etc. separately.
So I have the following extension method to change the TimeScale dynamically.

    public static Tween UpdateTimeScale(this Tween tween, TimeScaleObject timeScaleObject)
    {
        tween.timeScale = timeScaleObject.TimeScale;
        
        Action<float> onTimeScaleChanged = (newTimeScale) => tween.timeScale = newTimeScale;
        timeScaleObject.OnTimeScaleChanged += onTimeScaleChanged;
        
        tween.OnComplete(() =>
        {
            timeScaleObject.OnTimeScaleChanged -= onTimeScaleChanged;
        });
        return tween;
    }

However, Tween.OnComplete only works when the tween completes automatically or when Complete() is called, so if you use Tween.Stop() to stop it, the OnTimeScaleChanged event will remain registered. Therefore, a Tween.OnStop() callback corresponding to Tween.Stop() is required.

It would also be useful to be able to register more than one function in a callback, such as OnComplete, since there are times when you want to use each callback in the FollowTimeScale extension and in the project code.

[KyryloKuzyk]

Hey! I hope you're enjoying PrimeTween :)

There is no OnStop() callback for simplicity reasons. tween.Stop() is a user action, so the user can just execute any arbitrary code they want before calling tween.Stop().

I understand the need for your specific use case, but I'm afraid you're using PrimeTween in a very inefficient way. You allocate GC memory at least four times in your code snippet: 1 - tween is captured in a closure by the onTimeScaleChanged delegate; 2 - tween.OnComplete() captures the timeScaleObject; 3 - every time you subscribe or unsubscribe to OnTimeScaleChanged event. This can trump the performance of your project very quickly.

For example, this simple alternative implementation of TimeScaleObject addresses the missing OnStop() method, while also drastically improving performance:

public class TimeScaleObject {
    const int initialCapacity = 20;
    readonly List<Tween> tweens = new List<Tween>(initialCapacity);

    /// Add tweens to the TimeScaleObject to control their timeScale together
    public void AddTween(Tween tween) {
        for (int i = 0; i < tweens.Count; i++) {
            if (!tweens[i].isAlive) {
                // replace the first encountered 'dead' tween with a new one
                tweens[i] = tween;
                return;
            }
        }
        tweens.Add(tween);
    }

    /// Apply timeScale to all added tweens at once
    public void SetTimeScale(float timeScale) {
        for (int i = tweens.Count - 1; i >= 0; i--) {
            if (tweens[i].isAlive) {
                tweens[i].timeScale = timeScale;
            } else {
                // remove all 'dead' tweens
                tweens.RemoveAt(i);
            }
        }
    }
}

[KyryloKuzyk]

Also, the OnComplete() call is ignored when the tween's target is destroyed (or the scene unloads). So, in general, you should not rely on OnComplete() for important things like unsubscribing from an event.
For a similar reason, there is no OnTargetDestroyed() callback in PrimeTween. Please read more about it here: #4

[donafudo]

Wow, you are right.
I guess I was thinking too narrowly by trying to make TimeScaleObject a pure class that does not depend on other libraries.
I would like to incorporate the method you have presented into my project.

It was my impression that you were not aggressive in introducing callback functions. Is that because you think it is likely to be used inefficiently, as in this case, and performance would be lost?

Anyway thanks for your support.

[KyryloKuzyk]

I guess I was thinking too narrowly by trying to make TimeScaleObject a pure class that does not depend on other libraries.

Decoupling is good unless it makes things more complicated than they need to be :)

It was my impression that you were not aggressive in introducing callback functions. Is that because you think it is likely to be used inefficiently, as in this case, and performance would be lost?

Yeah, I have nothing against callback functions when they add value. For example, OnComplete() is necessary because the user doesn't know when the animation will be finished.
But in the case of OnStop(), the user always knows the exact moment it happens: it happens when the user calls tween.Stop(). So instead of using OnStop() it's much simpler to do this:

// this introduces complexity and indirection   
tween.OnStop(() => print("animation stopped"));
  
// this is much easier to read and maintain
tween.Stop();
print("animation stopped");

[donafudo]

In some of the use cases I had in mind, it was sufficient to do the processing together with the call to Stop().
Thank you.