I have found an interesting issue with my project.
Imagine a bullet hits your character and then get’s destroyed. When it his the player, it calls a function… BackToCheckPoint();
The character have to go back to checkPoint position. So the function BackToCheckPoint(), that was called from the bullet is executing several lines of code.
The problem comes, if there is a “yield” in the function (BackToCheckPoint). If the bullet get’s destroyed, before the yield finishes, the function stops the execution at the yield.
So my question is: If one object calls a function on another object and get destroyed, why does that function is dependable from the object, that is calling it? It is allready called, so it shoud not be watching, what’s happening to the object, that called it…
First, my experience in 4.x is that coroutines are always owned by a particular MonoBehaviour, and will stop executing if that owner is ever destroyed, deactivated, or disabled.
Second, UnityScript handles coroutines such that “they just work”, unlike C# where you explicitly call StartCoroutine. This means you don’t necessarily know which MonoBehaviour ends up owning the coroutine – the caller, or the callee?
Given the problems mentioned above, it looks like the caller ends up owning the coroutine. If the caller is destroyed, the coroutine is destroyed with it.
In C#, you could fix this by having the other behavior call StartCoroutine. In UnityScript, it looks like you’d have to create a “hook” function, such as your CallBackToCheckpoint; because the other behavior calls the coroutine, it ends up owning it.
In either language, it’s also possible to fix this by having a third object own the coroutine.