Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Voting for the Unity Awards are OPEN! We’re looking to celebrate creators across games, industry, film, and many more categories. Cast your vote now for all categories
    Dismiss Notice
  3. Dismiss Notice

Time.deltaTime is 0 when TimeScale is 1?

Discussion in 'Scripting' started by Mr-Men, May 22, 2018.

  1. Mr-Men

    Mr-Men

    Joined:
    Feb 18, 2014
    Posts:
    16
    Hi,

    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:


    Code (CSharp):
    1.     private IEnumerator move()
    2.     {
    3.         yield return new WaitForEndOfFrame();
    4.  
    5.         if (Time.deltaTime == 0)
    6.             Debug.Log("Zero deltaTime!");  // Set debug point here
    7.  
    8.         float distanceThisFrame = Time.deltaTime * _speed;
    9.         _fullLife -= distanceThisFrame;
    10.         transform.position += transform.up * distanceThisFrame;
    11.  
    12.         if (_fullLife > 0)
    13.             StartCoroutine(moveProjectile());
    14.         else
    15.             Destroy(gameObject);
    16.     }
    17.  
    Values for the Time properties are as in the image link:
    Capture.PNG

    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.
     
    Last edited: May 22, 2018
  2. mrCharli3

    mrCharli3

    Joined:
    Mar 22, 2017
    Posts:
    956
    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.
     
  3. StarManta

    StarManta

    Joined:
    Oct 23, 2006
    Posts:
    8,738
    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.
     
    mrCharli3 likes this.
  4. newjerseyrunner

    newjerseyrunner

    Joined:
    Jul 20, 2017
    Posts:
    966
    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.
     
  5. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,399
    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.

    --Eric
     
    newjerseyrunner likes this.
  6. Mr-Men

    Mr-Men

    Joined:
    Feb 18, 2014
    Posts:
    16
    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.