IndexOutOfRangeException: Index was outside the bounds of the array. DG.Tweening.Core.TweenManager.ReorganizeActiveTweens ()

[zjm249926195]

Sample.txt Hello my old friend, Remember me? The answer should possibly be no. Ok let's get back on track. I've encountered this problem for a couple of times, finally i find a way to reproduce this problem stablity. The Sample.txt is the sample code and I shared my solution in it, it's much better if you have a more official solution, waiting for your reply!

[Demigiant]

Heyyy! Thank you for replicating it! But ouch, are you on the latestest DOTween? v1.2.632? I thought I had gotten rid of it forever with that update. If not, I'm out of a computer until next week but then I'll check this out and sqaush it 🙂

[zjm249926195]

Well the sample code was tested in develop branch and v1.2.335 (my using version). So I download the latest v1.2.632 today and the sample code still reproduces the exception.Hope you could check it out later :P!

[revolt3r]

Having a similar issue on latest version 1.2.632

[Demigiant]

Heyo! I'm taking a little more time to solve this because it's more complicated than I expected. In the meantime, I'd suggest disabling pooling (DOTween already pools its most "heavy" systems even without pooling, which is an extra layer). I hope to have an update within Tuesday

[eintopf]

How is the status here? We have the same issue in our project.

[lcraver]

I'm suddenly having an issue with this as well despite seemingly not changing anything on my end that would cause it.

[Demigiant]

Ouch, super sorry, I had to leave for a while and then postponed this in favor of other features, but now I'll try to get to the bottom of this. For the people that still have this problem, did you disable pooling? And can you confirm that you're on v1.2.632?

[eintopf]

Hey, for us the issue still exists. We disabled pooling (Recycle tweens it is called, right?) and we confirm that it is v1.2.632.

One thing that is also quite weird about it, is that sometimes the whole thing crashes so hard, that you have to restart the editor, because the issue persists beyond the play mode session.

We have it often (tbh I think just in editor?) but it is not really reproducible systematically; it just happens.

(i'd hate such a vague bug description myself, but it is really very mysterious :( ... )

[eintopf]

@Demigiant here is some follow up information.

DG.Tweening.Core.TweenManager.RemoveActiveTween (DG.Tweening.Tween t) (at D:/DG/_Develop/__UNITY3_CLASSES/_Holoville/__DOTween/_DOTween.Assembly/DOTween/Core/TweenManager.cs:1164)
DG.Tweening.Core.TweenManager.Despawn (DG.Tweening.Tween t, System.Boolean modifyActiveLists) (at D:/DG/_Develop/__UNITY3_CLASSES/_Holoville/__DOTween/_DOTween.Assembly/DOTween/Core/TweenManager.cs:236)
DG.Tweening.TweenExtensions.Kill (DG.Tweening.Tween t, System.Boolean complete) (at D:/DG/_Develop/__UNITY3_CLASSES/_Holoville/__DOTween/_DOTween.Assembly/DOTween/TweenExtensions.cs:145)
EconomyStats.OnTransactionAdded (Transaction obj) (at Assets/Scripts/Economy/Stat Providers/EconomyStats.cs:157)
EconomyStats.RequestAutoUpdate (System.Object requestor) (at Assets/Scripts/Economy/Stat Providers/EconomyStats.cs:138)
EconomySumDisplay.OnEnable () (at Assets/Scripts/GUI/EconomySumDisplay.cs:31)

private Tween tween;

    [...]

    private void OnTransactionAdded(Transaction obj)
    {
        tween?.Kill();

When looking at the RemoveActiveTween code the only thing that can give the OutOfRange exception is TweenManager._activeTweens[activeId] = (Tween) null;

So activeId is somehow invalid. A fix would be wrapping the line with some index safety checks, however this probably isn't going to the roots of the probem.

For me it seems / feels like a timing issue when using ?.Kill() in OnEnable and OnDisable. Maybe DOTween is not properly initialized then or don't know.

[eintopf]

@Demigiant I think I solved this issue for us now. But maybe you can add a safeguard for this case.

Our case is the following: We had a ScriptableObject which used DelayedCall . It cached the reference of the resulting tween, to kill it on subsequent calls. When we left playmode the refence (since ScriptableObject) to the tween got never invalidated. On the next run of the playmode tween?.Kill() was called (and tween was not null, but in a state "referencing the old "Play run"").

Note: This only happens when domain reloading is turned of (but since it is a huge time saver it would be a pitty to not have this deactivated).

This was our code:

    private void OnTransactionAdded(Transaction obj)
    {
        tween?.Kill();
        
        if (Time.realtimeSinceStartup - lastUpdateTime < coolDownDelay)
        {
            tween = DOVirtual.DelayedCall(coolDownDelay, () =>
            {
                OnTransactionAdded(obj);
            });
            
            return;
        }

        tween = null;

        UpdateStats();

        lastUpdateTime = Time.realtimeSinceStartup;
    }

[Demigiant]

Ahoy! Could you check if this fixes it? If it doesn't, could you try calling DOTween.Clear(true) at the very beginning of your playmode, so it clears everything left over by the domain not reloading? Let me know, and cheers, Daniele