I’m moving a gameObject based on Time.deltaTime. The gameObject is instantiated from a prefab. With some of the instances, at some point of the movement, Time.deltaTime becomes 0, and never changes. Movement is calculated in a Coroutine. There is no point in my code that I alter Time.timeScale:
private IEnumerator move()
{
yield return new WaitForEndOfFrame();
if (Time.deltaTime == 0)
Debug.Log("Zero deltaTime!"); // Set debug point here
float distanceThisFrame = Time.deltaTime * _speed;
_fullLife -= distanceThisFrame;
transform.position += transform.up * distanceThisFrame;
if (_fullLife > 0)
StartCoroutine(moveProjectile());
else
Destroy(gameObject);
}
Values for the Time properties are as in the image link:
I’ll resort to using Time.unscaledDeltaTime, as my timeSCale won’t change. But does anyone know why this could happen intermittently?
I’m on windows 10, running the game from the editor, using Unity 2018.1.0f2 Personal.
Is there a reason you do this in a Coroutine instead of Update? Time.deltaTime will give you the time between frames, i.e time between update iterations. Not sure how that works in a Coroutine.
Im just guessing here but I would not like to use that in a Coroutine, looks odd.
Time.deltaTime definitely works in coroutines - I use it all the time. However, it’s possible that it may not work during a segment of code that is being run at WaitForEndOfFrame(). OP, can you try caching the deltaTime value before that yield instruction, and then using it afterwards?
It may be worth reporting this as a bug to Unity, if that’s what is going on - I would not expect WaitForEndOfFrame to result in a deltaTime of 0.
Side question… are you launching a new thread for every projectile in your game? Threads are not cheap to launch, you may want to look into the concept of a single worker thread with a queue.
Coroutines aren’t threads; the Unity API is single-threaded and can’t be used with threads (aside from the new job system, which has nothing to do with coroutines). Time.deltaTime is just whatever the deltaTime is that frame, it doesn’t matter where you call it. The only time I’ve ever seen deltaTime be 0 is when timeScale is 0.
Hmmm. I wondering if the zero deltaTime is a bit of a red herring.
I put a Debug.Log(Time.deltaTime) before the yield, and it never reported a zero value. But then, neither did the debug after the yield statement. I even put a breakpoint at that line. It was never hit Until, that is, I paused the editor. Then deltaTime became zero, both before and after the yield statement. So, I’m wondering if pausing the editor plays with the time as Unity knows it.
When I posted this thread, my gameObject was stopping when it should have been motoring along. I assumed it could have been caused when setting distanceThisFrame. Looking back, I paused the game to see what was going on, and at that point the breakpoint after the yield would be hit. As it turns out, I’ve played around with the code a bit more, and the movement problem has disappeared.
