I have a coroutine that fires at the initialization of a scene. It is used on 8 different objects that “grow” into existence. The delay between the objects being grown is 0.1 seconds. The coroutine below works fine for objects 1-7, but object 0 (the first one) does not always work.
If I debug at the start and end of the coroutine, it finished 8 times, which is what it should do. However, object 0 stays at Vector3(1,0,1). If I replace the WHILE with the one below, it works. However, I don’t think it is a good idea to compare a float in a while.
while(transform.localScale.y < 1f)
Can anyone tell me why the first WHILE does not work properly at startup? Is there something about Time.deltaTime not working at startup?
Well I can’t fully explain why it would only affect the first one, but I can tell you why it might be doing what it’s doing and why the second while works.
Now what could be happening, is that there is something that is causing a large gap between your frames when your scene first starts, causing a large jump in Time.deltaTime, or that just happens in general (it’s doing it in my very bare scene anyway)
So look at it like this, (values taken from my quick testing of it)
First while,
elapsedTime = 0;
elapsedTime += Time.deltaTime (0.02f);
Second while,
elapsedTime = 0.02f;
elapsedTime += Time.deltaTime (0.02f);
Third while,
elapsedTime = 0.04f;
elapsedTime += Time.deltaTime (0.3649374f);
Fourth while,
elapsedTime = ~0.4f;
Now, that odd jump in between frames, has caused your while to exit, because obviously it’s greater than 0.2f (time + 0.1f) and it’s left your transform whatever the value it was in the third run of the while loop. Hopefully this makes sense?
This was what I was thinking as well. How can I solve this without adding a delay? Is this limited to the edittor only or will it happen in the live version as well eventually?
The only way to find out to be honest is to test it in the editor and a build and compare the values etc. But I will say that it’s not a guarantee, due to the nature of deltaTime and the way the while loop is.
One way you can guarantee it will end as the correct size is to make it the correct size after the while loop is finished, but then you have the problem of it possibly “jumping” to the desired size.
Sooo, the only way I can think of at the moment is, to not be frame time dependant but linear, something like,
for (float y = 0.0f; y <= 1.0f; y += 0.1f)
{
transform.localScale = new Vector3(
transform.localScale.x,
y,
transform.localScale.z);
yield return null;
}
I’m sure there is something better, maybe make it similar to a velocity if you want it with deltaTime and not linear, but I cannot think of a way other than your second while loop.
I suspect that the coroutine starts but when the first frame has finished loading from start() Time.deltaTime is too big and will directly have your while condition fullfilled. (Just for fun try your current code with a time of 1f)
So it won’t start the last scale change since it is already outside of the loop after it has done the first lerp. So to be sure you would need to check if your scale has reached Vector3.one. If not continue the while to reach your desired Scale.
Not tested but your loop should look something like this