I can see how this is somewhat confusing

And I wouldn’t claim I have gotten every nuance of this Matrioshka maze of IEnumerators and CoRoutines.

Having the potential for two opposing Coroutines running at the same time is definitely something that needs addressing, but I’m not sure if there can’t be a slightly less complicated cure (that doesn’t also contain unnecessary code duplication like we had before this lesson’s refactoring)…

I mostly avoided running into the issue (and perhaps also what is going to be addressed in the next lesson) by having added some protection against running back into the portal before the fade was finished.

    private IEnumerator Transition()
        // Protect against mistakes setting up the scene
        if (targetSceneIndex < 0)
            Debug.LogError($"{name} ({GetInstanceID()}) - Target scene was not configured on portal {name}");
            yield break;

        transform.parent = null;    // Make sure the portal is in the hierarchy's top level so DDOL works correctly.
        GetComponent<BoxCollider>().enabled = false;
        Fader fader = FindObjectOfType<Fader>();


So I turn off the originating portal’s collider and render it inactive that way…

I did manage to spam movement to run into the target scene’s portal though, which left me sitting up a group of tree (which wouldn’t have been so bad if one had some way to jump off them back onto the NavMesh)…

As for the video, I think what the lesson could use would be some wrapping up which would iterate through the flow of execution between FadeIn(), FadeRoutine(), and Fade() one more time…

Privacy & Terms