Don't forget moving forward: Never move those portals from top level!

Hey everyone!

I know it is explicitly said in the video during this chapter, but don’t be like me and waste a half hour (embarrassing!) by tidying up your hierarchy and eventually put “Portals” under another section like “Environment”. I did this many lectures later during projectiles and such.

Went to show my wife my super cool progress and I wouldn’t load into the new scene.

The worst part is that debugging this can be frustrating because your code execution just STOPs while doing LoadSceneAsync. No error is thrown, it just will not call “FadeIn” or any other code. I had print statements never getting called and was scratching my head.

(perhaps this is explained later and I haven’t finished the whole tutorial but…) Turns out this happens because LoadSceneAsync will delete the previous gameOBject that was the caller to the Coroutine if it is a child of any object. So by deleting the game object, it makes it confusing why your breakpoint doesn’t get hit after that (because it’s dead). Moved those suckers up to the top level like Rick said to do and everything was okay again.

It catches a lot of students. Unity does throw a warning (the yellow messages), but if you’re like me, you’ll have the warnings turned off, because who wants to clutter their console with warning CS0649: Field 'Portal.spawnPoint' is never assigned to, and will always have it's default value null messages? Personally, I would prefer that Unity escalated the warning that Don’t Destroy On Load objects cannot be sub objects to an error, because it really is an error in my opinion.

Wow thanks Brian…I actually clicked on warnings and looked at them. Then I closed them again not seeing anything of interest. Afterall, I was so laser focused on the “Fader” because the screen just stayed black. Little did I know the code was simply not executing at all! lol. So yeah, I can see how that would be very confusing. I believe Rick even mentions it will be addressed later in the lecture, so I will be more patient hah

I found it easier (and safer) to assign every reference type field that is supposed to be assigned via inspector to null or default (which is the same, to be honest). This is enough to make the compiler happy and stop the flood of warnings.