Things to check before starting a coroutine?

[wwu39]

Calling coroutine outside of the gameobject sometimes yields ERROR. I met two yet: 1) the monobehaviour is being destroyed; 2) the gameobject is inactive. So what else should I care about before I start a coroutine?

public void StartFindPath(Vector3Int startCoords, Vector3Int endCoords)
    {
        if (this && gameObject.activeInHierarchy) // checking if I can legally start a coroutine
        {
            findingPath = true;
            StartCoroutine(FindPath(startCoords, endCoords));
        }
        else
        {
            onPathfindingFinished?.Invoke(this);
            PathfindingManager.FinishProcessingPath(null);
            findingPath = false;
        }
    }

[dgoyette]

That seems pretty good to me. The other thing you might be concerned with is if the coroutine is already running. If it’s possible for the coroutine to be started/restarted more than once, you might want to make sure you only have it running once. You can avoid that by calling StopCoroutine() before starting the coroutine again. For example:

private Coroutine _countdownCoroutine;
public void BeginCountdown(float time)
{
    if (_countdownCoroutine != null)
    {
        StopCoroutine(_countdownCoroutine);
        _countdownCoroutine = null;
    }
    _countdownCoroutine = StartCoroutine(Countdown(time));
}

There may be cases where having one coroutine running multiple times on the same object is fine, but usually I find I want to interrupt the current routine and start over fresh with the new one.

[Bunny83]

The real question what you want to do otherwise? At the moment you essentially circumvent the issue by not calling StartCoroutine. Though the question is why do you actually call this method in the first place? So there has to be a conceptional issue in your setup when this actually happens. In some rare cases just ignoring such issues may be a solution, especially when you need a quick fix late in development.

However in a proper designed application this should never happen in the first place and ignoring / swallowing such issues blindly could actually hide other deeper issues. Don’t be afraid of errors, they are here to help you.

Though that said we don’t have the full picture of your design, so this may be the right place to check for the state of the object.

[Kurt-Dekker]

@wwu39

Things to check before starting a coroutine?

The main thing to check before calling / making a coroutine is to ask yourself,

“Does this even need to be a coroutine?”

Generally, if your design requires you to call StopCoroutine(), then don’t make it a coroutine.

If you just need something to happen a bit later, this is a more-robust approach:

https://gist.github.com/kurtdekker/0da9a9721c15bd3af1d2ced0a367e24e

If you’re flipping from one value to another, such as fading in, fading out, changing speeds slowly, etc., coroutines are an AWFUL solution to that. Instead use a pattern like this:

Smoothing movement between any two particular values:

https://discussions.unity.com/t/812925/5

You have currentQuantity and desiredQuantity.

• only set desiredQuantity
• the code always moves currentQuantity towards desiredQuantity
• read currentQuantity for the smoothed value

Works for floats, Vectors, Colors, Quaternions, anything continuous or lerp-able.

The code: https://gist.github.com/kurtdekker/fb3c33ec6911a1d9bfcb23e9f62adac4

If you just need cooldown timers for limiting gunfire rates, use a cooldown timer:

Cooldown timers, gun bullet intervals, shot spacing, rate of fire:

https://discussions.unity.com/t/821482/2

GunHeat (gunheat) spawning shooting rate of fire:

https://discussions.unity.com/t/824570/2

Far too often people (including very popular tutorial sites on Youtube) reach for needless coroutines and make a colossal unstable mess of their codebases as a result.

Also: https://discussions.unity.com/t/849607/7

[wwu39]

The design is that pathfinding is performance heavy and I’m splitting the work across frames by using yield return null. If a unit needs a path then it informs PathfindingManager and the manager queue up those requests and executes them one after another. The problem comes when a unit requests a path but die/inactive by the time the manager executes its FindPath. In that case the manager should move on to the next request.

[Kurt-Dekker]

@wwu39

The design is that pathfinding is performance heavy and I’m splitting the work across frames by using yield return null.

That sounds like a very legitimate coroutine use.

The method I would do is to have a single pathfinding manager that the units ask for pathfinding, then they get a callback when the pathing is done.

That way if they have died, the pathing callback just dumps data into a dead object for subsequent consumption during that dead object’s Update() loop… which never happens!

The you can put in an OnDisable() method in each destroy-able object that can call the pathfinding manager and say “hey if you had business for me, forget it, I’m outie…”

Or it could just let the work be done and discard it.

The above lets everybody NOT care about what anybody else is doing. Everybody just knows what to do.