By the way, I’m very new to coroutines and I recently learned about WaitForSeconds. Previously, in my mobile project I was using InvokeRepeating to deplete a few stat meters/bars every some specified amount of time (similar to the sims), but I hear people say coroutines are better performant, so, should I change them to coroutines instead? I found this in a forum:
StartCoroutine("Shoot");
IEnumerator Shoot() {
yield return new WaitForSeconds(5f);
while (true) {
// shoot stuff
yield return new WaitForSeconds(2f);
}
}
The only thing is, I also have some code that cancels the invoke and restarts it in case Update() detects the time float gVar has been changed (which is meant to change the time on the fly)… but I guess, in the case that I change to coroutines, it would kind of be best if I capture the data in a float variable which I can then pass to the coroutine? or capture it directly inside the coroutine instead of update? (i’m guessing the second?) Anyway, my only worry is, If I change to coroutines won’t there be a small delay when you change the time on the fly? (like using an special item, which for an amount of time will make your character get hungry more slowly) .
Or should I just leave them as is? I haven’t really profiled them, but they’re just removing 1 from a 100 every X time, then updating a gVar tied to a meter/bar.
Ok, this discussion is now way outside of the scope of this thread. I just posted here to make sure that my coroutine asset wasn’t being misrepresented.
@Alverik If you want me to answer your question in depth then please ask in my coroutine thread. The short answer is that Update gets run every frame, and even an empty update function has a non-zero cost, whereas WaitForSeconds (Unity) or Timing.WaitForSeconds (MEC) won’t call your coroutine at all until the time has passed, so that’s how it’s faster for your case.
Isn’t the following code suppose to throw an error?
void Start () {
this.StartCoroutineAsync(MyCoroutine());
}
IEnumerator MyCoroutine() {
yield return Method();
}
IEnumerator Method() {
yield return Ninja.JumpToUnity;
yield return Ninja.JumpBack;
var x = this.transform; //should throw an error, but it will not, meaning it's back to Unity main thread
}
There isnt any lag on download code previous to this. After the download completion, there is lag on saving the asset to device. Anyway I inserted the above changes on the code, but doesnt seems to show any changes.