Hello all! I'm trying to control some soldiers using coroutines. Right now, they have basic coroutines: Walk, Shoot or Reload. In short, if I have a target, I should shoot until run out of bullets and reload. Keep doing this until I don't have a target anymore. If I don't have a target, walk forward until I have a new target. Both soldiers spawn apart, and walk towards the center, when they "see" each other, they acquire their target and should stop walking and start other coroutine, in this case, shoot. Video below: The coroutine is below: Code (CSharp): private IEnumerator WalkForward() { // Determine any number or variables to be adjusted Debug.Log("Walking"); myAnimator.SetFloat("Stance", 0); myAnimator.SetFloat("Speed", 1); // Determine how to exit conditions if (myTarget) { Debug.Log("Acknowledge I shouldn't walk anymore"); walking = false; } // The repeat block if (walking) yield return new WaitForSeconds(0.1f); else // The exit block { Debug.Log("Quitting walk"); myAnimator.SetFloat("Speed", 0); // Gradually reduce the speed to quit myAnimator.SetFloat("Speed", myAnimator.GetFloat("Speed") - Time.deltaTime / 10); onCoroutine = false; yield break; } } As you can see, it never quits walking. On the console, the log "Acknowledge I shouldn't walk anymore" is never shown, and of course, it will always have the walking = true, not quitting the coroutine. My real question is: What is expected to return, when I write if(GameObject)? In my point of view, it will be false as long as it is null, and when that game object is referenced, it will be true as long as the game object is not null. Am I missing something here?
Your entire coroutine exits within either the same frame you started it, or else 0.1f seconds after you started it (if walking is true). There is no loop. You probably don't want coroutines at all to actively process stuff: either be in the walking state, or be in the shooting state, so more like finite state machine really. Trigger and stop animations when that state changes.
Hummmm... I was sure that starting a coroutine was like instantiating another instance of an FixedUpdate, where you decide the delay in the WaitForSeconds. After your explanation, even the name makes more sense now: It is a block, which will routinely be read, every WaitForSeconds time. Is it right to assumption that coroutines will be better used only on a time based check, rather than, as you said, actively processing stuff? An example: Let all the changes on my animator on the Update block, and check changes (Like if my target has moved away) in a coroutine? And if the target moved, I got all the controllers on the Update block to chase the enemy? Another example: Flashing colors on the screen (Like a police car blue and red light) and when the police is gone, the coroutine stop?
Coroutines are completely optional. You never have to use them. They are a handy construct that makes certain classes of problems easier to solve, such as just doing something later. They are frequently used inappropriately and cause great difficulty in tutorial projects. Coroutines in a nutshell: https://forum.unity.com/threads/des...en-restarting-the-scene.1044247/#post-6758470 https://forum.unity.com/threads/proper-way-to-stop-coroutine.704210/#post-4707821 Note how coroutines are "pumped" by Unity right after Update(): https://docs.unity3d.com/Manual/ExecutionOrder.html No magic in Unity, just software doing one thing after the other.