Why are we storing fireCoroutine only to define it in the if statement?

[Xarce]

We are told to create a coroutine called firingCoroutine and then define it as StartCoroutine(FireContinuesly()); and then stop it with StopCoroutine(firingCoroutine);

My question is why not write FireContinuesly as we did before in the first if statement and then stop it the same way with StopCoroutine(FireContinuesly()); ?

And what exactly activates the firingCoroutine in the first place? We define it in the if statement but that’s not the same as calling it no? And we didn’t write it as

firingCoroutine.StartCoroutine(FireContinuesly()); because that wouldn’t work since it’s not a class with a method to call.

if we only define it in the if statement then it should not work. What am I forgetting?..

[heckadactyl]

Heya,

One reason to use a variable, is so you can keep track of the exact instance of that Coroutine - what if you call the same CoRoutine multiple times but you only want to stop the one you’re tracking? This way you know exactly what you’re starting, and what you’re stopping, it’s just very precise, even more precise than using just the method name.

Same thing could happen for instances of a game object you instantiate, if you just say, destroy all game objects with the name “Enemy”, they’ll all die, but if you keep track of one particular instance, it will only destroy that one you have specified or stored in a variable.

As for the other question - the code does run(!), even though it seems like it’s just being assigned to a variable.

Consider the following code:

public string Message()
{
	Console.Write("This method is called!");
	return "Message";

}

public static void Main()
{
	string message = Message();
}

This will print “This method is called!” to the screen. If we then ask it to print the value of “Message”, it will print “Message” (because that is what the method returns). The hello prints because it runs the method when we return the string. When you assign that value to hello, you have to run the method to get the return data, which in turn, will run the code in that method as well.

[Xarce]

You’re saying the coroutine we defined runs because it is being returned? But it wouldn’t if we just wrote it like that in any other method? Writing code in an if statement counts as returning it to the method itself is what you are saying?

[heckadactyl]

@Xarce

StartCoroutine(FireContinuesly())

Basically what I’m saying is that doing this:

firingCoroutine = StartCoroutine(FireContinuesly());

is having the same effect as:

StartCoroutine(FireContinuesly());

But the added difference is we get to assign that coroutine to a variable (that we created) so we know what is running and can control it / stop it / access that particular instance of it. (Because coroutines can be called multiple times, this lets us stop the same one we started.

The main thing to note here: It’s just a very specific / precise way of handling it. We could technically do what you said and it would work just fine most likely, but it’s always safe to be as precise as possible! This is really just an added layer of defence and helps us with scaling and future-proofing the code.

So basically – it’s not just being ‘defined’, the coroutine is being called & run as well, as per normal - when we hit the fire key. And then stopped when we release it.

[Anthony_Juarez]

It is possible for a method you call to perform other tasks in addition to returning a value. I’ve heard these referred to as “side effects” and generally you want to avoid them when you can because they can cause confusion, as you are seeing. When you do have side effects, it’s important to clearly indicate them in the name of the method if you can. In this case, the name of the method tells you what side effect to expect. Basically StartCoroutine() will start a coroutine for you, using the IEnumerator you specify.

In addition to that, it also returns something. It returns a reference to the coroutine that was started. Whether you choose to assign that to a variable or not is up to you. You can run StartCoroutine on its own, in which case the return reference will be lost. Or you can use the assignment operator ‘=’ to assign that reference to a variable of type Coroutine.

This is similar to how Instantiate works. You can use Instantiate on its own to instantiate a prefab, but if you put it on the right side of the assignment operator, you can assign a reference to the instantiated object, saving it into a variable.

GameObject myInstance = Instantiate(myPrefab);
Instantiate(myPrefab);

Both will create an object. It’s just a matter of whether or not you are doing anything with the returned value, which is entirely optional. Most methods that create something will return a reference to the created object – otherwise you really have no way to work with it afterward.