Bug Why is deltaTime != unscaledDeltaTime when timeScale == 1

This can't be right.

Code (CSharp):

1. using UnityEngine;
2.  
3. public class UnscaledTimeTest : MonoBehaviour
4. {
5.     void Awake()
6.     {
7.         Time.timeScale = 1.0f;
8.     }
9.  
10.     void Update()
11.     {
12.         Debug.Log( Time.frameCount + ": " + Time.deltaTime + " == " + Time.unscaledDeltaTime + " => " + Mathf.Approximately( Time.deltaTime, Time.unscaledDeltaTime ) + ". Diff: " + ( Time.deltaTime - Time.unscaledDeltaTime ) + ". Scale: " + Time.timeScale + ".\n" );
13.     }
14. }

Result:
1: 0.01999999 == 4.473793 => False. Diff: -4.453793. Scale: 1.
2: 0.01999999 == 1.638841 => False. Diff: -1.618841. Scale: 1.
3: 0.04363539 == 0.04363539 => True. Diff: 0. Scale: 1.
4: 0.0150625 == 0.0150625 => True. Diff: 0. Scale: 1.
5: 0.0171926 == 0.0171926 => True. Diff: 0. Scale: 1.
... and so on.

Time.unscaledDeltaTime is completely off the first couple of frame, with a new offset at every run. This means that Time.time and Time.unscaledTime are also off.

WTF, Unity 2022.2.14, 2023.2.a15, and probably other versions.

 

It is apparently by design. Bad design. Time.deltaTime is capped to Time.maximumDeltaTime and Time.unscaledDeltaTime is not.
https://forum.unity.com/threads/tim...ime-unscaleddeltatime-time-timescale.1354778/

Why?

 

IDK. To avoid everything getting "kick" on every minor frame drop? And to free me up from damping each dynamic value manually all over the place?

 

If you mean like when you hit play, the first couple of frames are always off because there are some performance spikes due to how environment context needs to swap, Unity undergoes a huge memory load/unload process, and so there is a slight warm up period before things stabilize. That doesn't mean the time is measured wrongly.

On the contrary, the values you're seeing are a compensation because of the dropped frames. This shouldn't be the case in the final build, and besides no one's game should run from the get go, there is always some idle time that allows the spike loads to even out and settle down.

That said, the reason why you're seeing a huge discrepancy between unscaledDeltaTime and deltaTime is because deltaTime is capped by maximumDeltaTime while unscaledDeltaTime is not. This should not affected the recorded passage of time, only the returned value of deltaTime. Which is a good point on why deltaTime should not be used for manual time keeping, but doesn't automatically mean that the underlying time is wrong (edit: well, it actually does dilate time, but you still have the unscaledTime that should reflect the real time properly).

Time Frame Management

Btw, a Unity app can and will time-drift, though this should happen only in rare situations and only slightly. I've tested this claim recently for 6 hours straight of fairly high frame rate (200+). It drifts for a practical zero amount (after the warm up period), if you rely on Time.timeAsDouble. If your frame rate drops below some reasonable amount I suppose it would drift more, but can't say how much. The only way to truly anchor it is to supply an external injector of fixed time, from local or internet clock.

 

No, I mean why is Time.unscaledDeltaTime not affected by Time.maximumDeltaTime like Time.deltaTime is? Not the other way around. The naming is illogical.

 

I don't know. Probably because they added capping as an afterthought, and it made sense for it to only affect the scaled portion of the timing logic. Can't find any further info on that decision. Maybe that's how you can still tap into uncapped deltaTime, that's why they didn't want to taint it?

Frankly I have never used the time scaling the way it is. I've always made my own, because I then get to properly differentiate between various states and things like what's GUI and what's game world. It's fairly simple and much more powerful to have your own time-keeping class in one place, and progressively add layers of logic to it while retaining the maximum control.

edit:
Now you've just highlighted why it's smarter to measure time intervals with unscaledDeltaTime, instead of potentially using the capped one. If you could only confirm if the discrepancy between Time.time and Time.unscaledTime is the same, because that would be weird but actually good. It's better to have this discrepancy than for these values to pretend to be the same.

 

You should NEVER expect this to work, ever ever ever. Except maybe with zero, and even then...

Floating (float) point imprecision:

Never test floating point (float) quantities for equality / inequality. Here's why:

https://starmanta.gitbooks.io/unitytipsredux/content/floating-point.html

https://forum.unity.com/threads/debug-log-2000-0f-000-1f-is-200.1153397/#post-7399994

https://forum.unity.com/threads/why-doesnt-this-code-work.1120498/#post-7208431

"Think of [floating point] as JPEG of numbers." - orionsyndrome on the Unity3D Forums

That's a pretty scathing indictment of an engine used around the world by millions.

A more constructive way to think about it is "What problem are you trying to solve and could it be solved by a better route than the approach you have selected?"

 

That's not the actual problem. It took me some time to parse this through, a legit issue is this

Diff: -1.618841

which comes as a result of this

Code (csharp):

1. Time.deltaTime - Time.unscaledDeltaTime

Indeed if timeScale is 1f, this shouldn't be the case, leading us to the rabbit hole of double-standards and capping one value but not capping the other. Honestly, it's a bit weird if you ask me, but can be worked around.

 

Exact same reason. In case you need time-scale something with time passed not in game, but in real world. GUI interactions as example. If it should take 0.25s to change button state, slowing it down each "long frame" doesn't make sense.
After all, it is named unscaled.

 

Your argument is not entirely valid. If it's unscaled that doesn't mean it should be uncapped. And hard-limiting a value is not the same thing as scaling it, so the scaling part is pretty much a red-herring, this is about something else.

It makes sense to check whether the two cumulative values of Time.time and Time.unscaledTime do reflect on these differences of getting capped by maximumDeltaTime, and I'm still waiting for @cecarlsen to come back with an answer.

If not, I'm going to check this for myself at some point. It's very weird this capping thing. At the very least the naming is illogical (should be intactDeltaTime for example), but after some thinking this is also very dangerous actually. I'm really not sure what prompted them to even consider such a move, Unity has an incredible track record making very bad decisions in the name of apparent yet short-sighted "user friendliness". I have to dig further.

 

Preliminarily, I can only tell that maximumDeltaTime is there only so that the physics doesn't explode on long frame hitches. And maximumDeltaTime is enforced to always be as large as fixedDeltaTime.

It's very convoluted, and after reading the docs a couple of times now, I can't really tell why they precipitate the FixedUpdate issues onto deltaTime other than to make things even more complicated.

 

If it were me and I was concerned about this (I'm not... but if I was).

I'd start running this in builds to see if the behaviour occurs there as well. Often times editor behaves very different from builds. This way I can rule out if this really is going to impact me in the end.

...

As for the asking why... welp... we'll have to sit back and wait to see if Unity themselves answers the question. Otherwise it's only guessing. And personally I find @Elhimp's suggestion of "it's called unscaled" a reasonable guess. I could see myself, or devs I know, make that semantical reach when coming up with names for things. Is it semantically perfect? Nope... but most names aren't.

 

Red herring.

If you look at the actual numbers in their output, you'll see they are off by far more than floating point imprecision could account for.

And if you read the source code in the OP, you'll see they're already using Mathf.Approximately to perform the comparison. Choosing to write "==" in the debug message does seem like a suboptimal text choice (I might have written ~= instead), but that's just text, not functionality.

And in fact, I think this is one of the rare cases where using == is probably perfectly fine, because one variable is presumably being set directly from the other (and the scale value of 1 can be represented exactly as a float). That is, I expect

x * 1f == x

will be true, despite floating point imprecision.

Oh come on. They're not saying the engine as a whole is bad, they're saying this particular decision is bad. Unity includes many bad decisions, including several that have been admitted by Unity's developers (in hindsight) to have been bad--which is perfectly ordinary for a piece of software as large and complex as Unity. This claim is not in any way extraordinary.

And even if someone wanted to say that Unity is bad overall, replying "if it's so bad, why do so many people use it?" is not a good rebuttal. Lots of bad things are widely-used for a variety of reasons, such as lack of information, lack of alternatives, and inertia.

I think this can at least be criticized for the name choice. The name "unscaledDeltaTime" implies that the only difference from deltaTime is scaling. If they wanted it to conceptually represent real elapsed time with no processing, they should've named it something like realDeltaTime or deltaWallTime. (Admittedly, this distinction might not have been clear at the time if maximumDeltaTime was added to the engine later on; I haven't checked if that's the case.)

I'm unsure whether unscaled-and-uncapped or unscaled-but-capped was the better feature to provide. UI animations seem like they'd probably rather use capped deltas, for roughly the same reason you want gameplay code to use them. If you want to peek outside the abstractions of the engine to see the real time, you shouldn't use either; you should use Time.realtimeSinceStartup (or System.DateTime, or some other time library), because Time.unscaledDeltaTime gives the time between the starts of frames, not the real time now.

 

To be honest I am failing to see the problem with this entire thing and also failing to see the core, why would anyone keep time like this themselves. But it's a nice occasion to throw shade on engineers who decided to help to make an actual game instead of catering to semantic BS. Of course I can be persuaded otherwise if anyone tells me why do we want to keep time ourselves instead of relying on the fricking engine we're using and actually keeps tabs on everything properly, while we're only dabbing into scripting.

 

I don't understand what you mean by "keep time like this themselves" or who is doing that.

 

I do see that the name could be more informative. Having one called "unscaled" is arbitrarily specific about what isn't happening to the value, which does indeed imply potentially misleading details.

Personally I'd call it "raw", but also I can see why "unscaled" could have been a perfectly decent name two decades ago when it was first named. And, again personally, I don't think it's a big deal since it's covered in the docs, which I would read if the details mattered.

 

@Antistone
@Lurking-Ninja
@Kurt-Dekker
You all seem to be majorly confused. I don't know if my posts are invisible, but let me try this again.

I was of the same mind set as you, however after half a day of digging through this I'm now positive that you underestimate the implications. I already explained to Kurt it's not about the floating point. Yes, it's a red herring after red herring, but the real issue is delta time being capped.

It has nothing to do with scaling per se. It has to do with the fact that one value is artificially limited, while the other is left intact, leading to some pretty major discrepancies, if your game has hitches for whatever reason. This is pretty major because although it shouldn't normally occur, it can be induced.

The system is tweaked so that deltaTime must be <= maximumDeltaTime. That's all there is to it. Now the implications:

Given that default maximumDeltaTime is sufficiently big, most people don't realize this. However, it can never be smaller than fixedDeltaTime. If I was a (cheating) speedrunner I would exploit this knowledge big time. You can accrue major differences between Time.time and Time.unscaledTime if you encumber the game's framerate to the point where deltaTime consistently goes above maximumDeltaTime.

The easiest way to do this is to artificially inject a low enough value to maximumDeltaTime, and then introduce some heavy load to CPU. This would effectively dilate time, which is crazy.

That means if a game doesn't test for this extensively, it has a potentially catastrophic misalignment of internal time if it relies on both Time.deltaTime and Time.unscaledDeltaTime (and potentially Time.time and Time.unscaledTime as well).

Also if the framerate falls below 1 / fixedDeltaTime (50 Hz by default) it faces potentially undesirable time dilation. In my opinion, this maximumDeltaTime is a PR stunt, there only to make Unity look good, with less stuttering when throttling, and not because it was smart or safe to do it like this.

It is the low frequency of occurrence in everyday development that makes this seem like it's not a big deal, but it's a major vulnerability in time keeping.

I am still to actually come up with some evidence, but if Time.time actually accumulates a capped deltaTime (and it probably does), then this is a huge issue and a vulnerability, because there is no other way to keep time.

Not speaking on behalf of the OP, but I am not catering to semantic BS, can you actually read the docs and think this through?

This isn't great news. I've had cheaters in my projects before, and it's not fun business. According to my client, it was entirely on me that people knew how to use memory hacks with their phones. And it was a sports arcade game, not some scientific endeavor.

Um, now you lost me. Literally everyone?

Every time you rely on Time.deltaTime, whether you accumulate it or not, you're keeping time on your end.

Because if you think about it, you're accumulating it either through a variable, or through some motion step / animation step. Something always moves according to deltaTime, so we all keep time on the C# end, all the time. If the time drifts, either your values are off and/or the movement is off. It will always manifest somehow.

I'm intrigued how would you design a cooldown timer if not by tracking deltaTime? Through Time.time or Time.timeAsDouble? Both of which are already accumulations on the C++ side. And how would you animate this cooldown on a frame-by-frame basis? This is a pretty deep topic, I'm not sure if you all perfectly understand how deeply this goes.

And if deltaTime isn't reliably consistent with the passage of real time (and can be intentionally throttled by encumbering the rendering for example), how would you keep time then?

Recently I have debunked this idea that you cannot time-keep on the C# side, by effectively comparing the Unity's own value (of Time.timeAsDouble) with whatever gets accumulated on the C# side (also a double). (Except at the very start) The two values are identical, and I've run this for 6 hours straight at one point, while also watching Youtube in the background.

However, the idea that deltaTime is artificially capped, while unscaledDeltaTime is not, is something else entirely. It is literally dangerous to rely on both, and quite unsafe to rely on the former.

 

@angrypenguin That's actually on-topic as far as OP is concerned, but if I'm correct, that's a red herring too. The main issue is that the unscaledDeltaTime doesn't behave the same under some specific conditions, which aren't so exceptional that they need not be taken into account. You can read more in the above post, also there is a link to docs in post #4.

This is not about:
- noob problems with tracking time
- floating point imprecision
- tracking time through single-precision float
- how things are named and similar semantics
- superstitious conspiracies

It's about a deliberate design choice that has some severe implications on how time is effectively measured and its propagation onto everything that is made with Unity. I believe this elephant in the room at least prompts some discussion.

Namely, should people be aware of this and outright set maximumDeltaTime to infinity in cases where time dilation is out of question?

I would remind everyone that some of the major weaknesses, such as backdoors, and buffer overruns, for example in operating systems, were commonly introduced as features and solutions, only to be repurposed into exploits because of their poor design.

So the blank belief that because "Unity is very popular it cannot make major mistakes in such common areas" is not how these things work actually. This is exactly how major mistakes work. And I have a little lamp going on in my head, I've read the docs 5 times now.

 

???
Then WTF is this? You all should really read the docs before you start to talk down on the engineers. I'm personally pretty tired to read the end of times and how incapable of the engineers at unity are (they are plenty capable) in every single complaint thread. For every small BS story you can read here. Huge issue. Sure...

 

What about it? It doesn't contradict anything I've said. Have you actually read what I wrote?
I'm also not spelling doom for any engineers, I'm not OP, don't mix OP with what I'm saying. I am not even having a complaint, but you have to stop assuming, because there is a legit issue with how this is implemented.

 

You said:

And there is another way to keep time. You have a pair of scaled time (capped and exposed to timeScale) and a pair of unscaled one. You keep time however you want. But my original question was: why on earth would you like to mix and match? And then why are you rush to the forums to bad mouth people, who provided a thorough API? I still don't get it, what the goal of the OP is... and you didn't really explained it either, you sad dangerous and vulnerable.

WTF this even mean? You should always scale with

deltaTime

so you will be framerate-independent. If it drifts, it drifts together, that's the fricking point of this whole

deltaTime

exercise. It is not there for funsies. So, again, why would this be dangerous and what are those manifestations you're talking about but failing to describe properly?

What the heck? How do you go from uncapped time to buffer overflow?

 

Let's not go into arguing, please.

@Lurking-Ninja
Look, while you're here, try to answer this one basic question:

In your opinion, if timeScale was exactly 1 (without ever changing), should Time.unscaledTime return exactly the same value as Time.time at all times? Just yes or no, and why (if that's not too much to ask).

 

Dude... again. RTFM. And my answer is no.

https://docs.unity3d.com/ScriptReference/Time-unscaledTime.html

The whole capped deltaTime is about not jumping too far in any event of slow downs (when deltaTime would go out of control and too big hickups would show up). I don't see what it has to do with real time.

 

I see no reason to be this angry at me, please calm yourself down. You haven't even read my post properly. Which is evident by your other claims. I've described everything in excruciating detail. If you happen to answer the question above, we can proceed with the discussion.

I was at first just as dismissive as all of you are. But then I've noticed that there is something wrong here after all.

 

Sure, please start to psychoanalyze me instead of come up a single reasoning behind your statements. You're wrong. In this too.

 

Am I? What exactly did I do to you to prompt this behavior?
Am I "wrong on the internet"?

 

You're wrong, I'm not angry, I'm just disappointed. You throw around big words with deep implications (no other way to keep real time, buffer overflow, vulnerabilities, do you remember?) and when you're called out you hang onto a 'WTF'? Really? Okay then.
And that 'WTF' was because you're seemingly don't get the most basic rule of deltaTime and what it is for.

 

People regularly use both scaled and unscaled concepts. Having one artificially capped to produce time dilation seems wrong, especially if it occurs under specific circumstances so that it's difficult to test for or even detect until it's too late.

I've meticulously described exactly why it is dangerous, fully assuming that people ordinarily lean onto both concepts, which is the sole purpose of having both readily available. It is dangerous because by introducing such subtle but chronic discrepancies you basically passively push everyone to run into exploitable behaviors in their designs. It's a systemic issue, due to a "fix" for a thing that was never broken.

As if devs couldn't introduce such a fix for themselves. At the very least, a proper design would be to introduce clampedDeltaTime, not modifying the existing one. As one example.

And here I claim again that this design is due to Unity wanting to look smoother at all costs, by upgrading an age old design, without thinking through the implications of such a change.

And that's why buffer overflow served as a good analogy. You're incredibly annoying with how many times you've said WTF and how you're twisting my words to make me look like I'm out of place. Especially after not being able to quote a single thing that made you so angry. It's not my problem you're easily irritated.

 

@Lurking-Ninja
When and if you can calm down, you can try and reread post #19 again. Whether you agree with my analysis is one thing, but acting like I had just slapped your sister is another. There is no need for arguing. This will perhaps serve forever as a heads up, as a docs distiller, or as a debunking thread, for many. Who knows?

I've made sure to describe what exactly can go wrong with this design. And I'm actually fairly positive that this vulnerability is already out there, in countless games. Now, you can argue that with many games it's not that important, and you would be right, I agree completely.

But this still prompts a huge amount of awareness surrounding this issue for some projects. By this point, a question literally begs to be asked: why the hell would anyone think this was a good idea, to modify the behavior of something as fundamental as deltaTime? To cap one value, but not the other.

Coming from a company that doesn't want to fix certain bugs in fears of introducing a "breaking behavior"? As a long-time software engineer I claim this change is more substantial than any other "breaking behavior" that I've seen denied so far.

 

Bye. Ignore-list is cozy. I tried.
You have no idea what you're talking about. Just because you declare something vulnerability or dangerous it won't be really. And you failed to demonstrate either of those spectacularly. You also seemingly don't get it that nothing has really changed, no "fixing of issue" happened here.
What OP was talking about is the scene initialization. They probably have a metric ton of awakes and whatnot things to run in the beginning of the scene which triggers the

maximumDeltaTime

feature so the game won't freeze in place forever (which basically means physics and garbage collection will try to not run that much if the frame is running out of time and obviously capping deltaTime). And basically that's it. But sure, it's the end of Unity, they aren't capable of designing an API and why they would call something

deltaTime

to make sure from beginner to pro everyone knows how to deal with the best path when it comes to achieve the illusion of framerate independence. I'm pretty sure you would have done a better job at it. Bye.

 

This is true, partially. However for faux motion and animation that is actually a desired behavior. I don't want the system to swallow my time. I want it to sync with the passage of time. The real reason is not merely "jumping too far", the real reason is literally because the underlying physics would extrapolate the wrong forces, and things would explode all over the place. This is why maximumDeltaTime is not allowed to go below fixedDeltaTime, as physics would become time dilated.

With this in mind, this makes the change rather specific. It's really aimed exclusively at physics users, however it affects everyone. Let's say I find this suboptimal, with how huge sweeping changes are introduced in the core API with so little foresight. Is it okay to have a civilized argument, even if it ends up with a disagreement, without resorting to verbal violence and calling the other person a charlatan?

 

I don't know what you think the red herring is, because that's exactly what I was talking about. It is called "unscaled", but that is not the only thing that sets it apart from its counterpart. I've no idea where anything you're saying after that even comes from?

 

Do you see me talking about OPs problem? I mean sure, he raised it, but I'm not specifically talking about the problem OP was having.

And btw what you're saying is literally the same thing I said to OP in post #4. It's right there! It's crazy that you're now telling me the same thing, like I'm the one who needs tutoring.

Sigh. Okay, see this here

Code (csharp):

1. var scaledValue = scale * value;

This is scaling
This here

Code (csharp):

1. var limitedValue = Min(limit, value);

This is not scaling, it's limiting.

Sure if it's covered by docs after having to sift through 6 pages of API docs and a master page that had to include an unprompted diagram to explain why things are as complicated, then I guess it's okay if something is not only unscaled but also unlimited. Call me nitpicky.

I'm clearly the only one who minds when unwarranted API changes roll below my feet, and likely an idiot for wanting to discover the reasons and implications behind such a sweeping and frankly mindboggling decision to make issues with time-keeping more complicated than they ever needed to be. Don't mind me, I'll be in the corner, playing with my Flat Earth model.

 

I never actually said it's the end of Unity, and you're conflating the sentiment the OP was having with my posts. You're literally angry at him, but are talking to me.

And while we're at it, yes I would've made a better job at it. As already mentioned, I would introduce clampedDeltaTime. Or even better: I would recommend the following upgrade in the docs

Voila! Is that so hard that it is unfathomable? You think Unity's doing something magical instead?
I can't really understand the hard feelings and lack of emotional restraint.

 

You quoted me, but you don't seem to be responding to anything I said.

It's right there in the page for Time.time and Time.maximumDeltaTime. Granted, it's not on the page for Time.deltaTime itself, so I pressed the feedback button and said so.

And, that's about the extent to which I care about this, until such a time as I'm doing something where it matters. That said, if at some point I do really care about people potentially hacking my game or deliberately inducing time dilation then chances are the client side isn't where it needs to be addressed in the first place.

 

So, instead of doing bunch of operations every time I need clamped

deltaTime

obviously I'm gonna do some static class to cache this value. Not a big fan of statics, but if it isn't case for one, I'm not sure what is. Then I'm gonna name it something like

Time

and value gonna be

deltaTime

...
Which is exactly what Unity already did for me. Voila my

new Vector3(0.0f, 0.0f, -1.0f)

 

Granted, the limit is pretty much haphazardly added to the codebase. No particular reason to change the behavior of deltaTime whatsoever. Thank you, that was the whole point.

Nobody asked for it. Nobody was asked about it.

You see, Unity has been struggling with deltaTime for a long time. And, to put this as simple as possible, I find this measure a bit too drastic in their attempt to sort out namecalling in the industry.

Fixing Time.deltaTime in Unity 2020.2 for smoother gameplay: What did it take?

Here I'm just trying to learn more about it. Nothing else.

That's a fair point! I have nothing against you not caring about this at all. But maybe I have some concerns about this that are actually grounded in some prior experience. I have my reasons, for one, I tend to enjoy knowing and understanding a system if I am to claim that I'm its power user.

But speaking of caring, now I'm not sure if I'm allowed to actually form my own educated opinions on this topic, because that's somehow interpreted as trash-talking Unity engineers. So should I care more about their feelings or mine? How did this topic suddenly become a topic on caring, instead of thinking rationally.

Again I'm just trying to learn more about it. Nothing else.

 

Sure, that's one way of looking at it. There are others, somewhat more profound reasons, I am aware of it.

I agree it cannot be addressed as naively as I would like it to be.

I was hoping someone would address the actual reason: again, it's likely because of how physics would stutter because it would extrapolate the forces ever so slightly wrong for most people.

I wish we could all agree that this was a gratuitous and impactful change to how deltaTime works, introduced just because. Time-keeping? It's never going to be a problem for anyone. Or confusing. Ever. Add the big-ass diagram so that they can navigate the Time class properly.

I bet there are zounds of feedback request over that piece of documentation, heck we've had a couple only from this thread alone.

 

Further, the implications of time's handling mechanics affects all of us, in everything we do, and every one of our players, if it involves input, rendering, animation, physics or audio generation. So it's perfectly reasonable to seek a masterful level of insight into how time's managed, mechanised and reported by each and every part of Unity these touch for the purposes of creating idealised experiences.

 

@angrypenguin Btw this was a question for you (well not specifically aimed at you personally, but I tried to address all of you), but you haven't responded

 

But it isn't gratuitous. I'm not even sure that it's a change? Many moons ago when I wrote my own stuff in C++, I'm pretty sure my Time class worked exactly the same as this one, including that cap on time.

Having uncapped time deltas is just asking for trouble. For instance, when you're debugging something in your IDE and then resume, you really don't want the next frame to have a delta of 3 minutes. So you pick a number big enough that it's unlikely to impact typical working behaviour (i.e. at least twice as big as your slowest acceptable frame rate) and small enough to not cause trouble (i.e. probably less than a second).

And typically in a public forum that would be respected.

My answer is no, that should not be a recommended solution, for reasons already covered.

 

Your specific use-case was nothing you couldn't solve by yourself, in your project, exactly like you said you would solve it. And also as a reply to @Elhimp the way this is solved is by writing a simple MyTime wrapper class, to be used throughout the project. No repeats, single point of responsibility, exactly the same static experience as with the API Time class itself.

Let me bore you first with my background. I know you're all experts, but I'll keep it short.

I hail from a time where the only GUI for Unity was IMGUI and random solutions on the Asset Store. We used to walk on long uphill snowy trails and fight with wolves on the way to our studios. Seriously, nGui (what is today's UnityEngine.UI package) was very early in development as a 3rd party asset at the time. It would take a year before that solution would hit the market. I was tasked with writing a complete GUI system for both mouse/keyboard and multitouch devices in under a month, and as someone who already had a decade of experience with complex UI systems, I pulled that off, all while still learning Unity and C#.

One of the things I did very early on, was to separate timing concerns, for a fully-animated project that consisted of real-time gameplay, slow-motion gameplay, in-game HUD, and pausable game menus, as well as music and sfx on top of that.

I'm nowhere near the supposed Einsteins of Unity, but if there was a browser where you could type in "show me the people who need to be shown how to reason about time in games" I like to believe I'd be somewhere among the last pages.

That said, I believe I'm capable of understanding what it's all about.

The issue I'm having with this is exactly that you're claiming that there was no change. Yes there was a change. maximumDeltaTime was supposed to be exclusively a physics thing, relevant only for the actual fixed frame computation, which should be a separate thing altogether. Or at least that's what the docs were saying at the time. But now we're limiting deltaTime as well?

Point being: Let me sanitize my delta, Update loop is my jurisdiction, if I want it capped I'll cap it myself, thank you very much.

But don't take my word on it, surely I got things wrong and backwards, so let's rewind time shall we?
I'm a user since 3.x, but let's start from 5.5 for brevity.

[link]

No word on it getting applied to deltaTime. In Time and Framerate Management for Unity 5.5, the only maximum that is mentioned is the Maximum Allowed Timestep, which is a property in the Physics (or Time) panel.

I can hear you saying "that was ages ago" so let's hastily move forward in time

[link]

Did you notice any change here? Let's also check Time and Framerate Management for Unity 2019.1.
It is identical to 5.5.

Let's move forward in time. This time things will change.

[link]

Whoa, this is crazy right? No? All of a sudden we got this mention of deltaTime being affected by maximumDeltaTime, for the first time ever? Let's also check Time and Framerate Management. Oh it specifically explains that Maximum Allowed Timestep IS the same thing as the maximumDeltaTime value.

And it took Unity how many years to implement / acknowledge this? Let's see, Unity 1.0 got released in June 2005 and 2019.4 got released in June 2020. So, um, for fifteen years nobody thought it was wise to actually explain that deltaTime, specifically, would be hard-limited in contexts outside of physics? Funny considering that pretty much everything in a modern game engine revolves around the notion of time.

Fast forward to present day explanation

Spoiler

Both these values are subjective measures of time elapsed within your app or game. This means they take into account any scaling of time that you apply. So for example, you could set the Time.timeScale to 0.1 for a slow-motion effect (which indicates 10% of normal playback speed). In this situation the value reported by Time.time increases at 10% the rate of “real” time. After 10 seconds, the value of Time.time would have increased by 1. In addition to slowing down or speeding up time in your app, you can set Time.timeScale to zero to pause your game, in which case the Update method is still called, but Time.time does not increase at all, and Time.deltaTime is zero.

These values are also clamped by the value of the Time.maximumDeltaTime property. This means the length of any pauses or variations in frame rate reported by these properties will never exceed maximumDeltaTime. For example, if a delay of one second occurs, but the maximumDeltaTime is set to the default value of 0.333, Time.time would only increase by 0.333, and Time.deltaTime would equal 0.333, despite more time having actually elapsed in the real world.

The unscaled versions of each of these properties (Time.unscaledTime and Time.unscaledDeltaTime) ignore these subjective variations and limitations, and report the actual time elapsed in both cases. This is useful for anything that should respond at a fixed speed even when the game is playing in slow-motion. An example of this is UI interaction animation.

[link]

All of a sudden there is no mention of physics. maximumDeltaTime is instead used to directly clamp deltaTime.

So let's double check this, because I might be crazy and getting confused over this big time, so what exactly is (or was) Maximum Allowed Timestep?

So I searched for some thorough explanations. Here's one from 2015, by Eric5h5

Is it the same as maximumDeltaTime, hm? Should it also affect deltaTime, hm?

Let's try again, this time we have to work with an article without a timestamp, but it's likely written before 2020.
Understanding FixedUpdate, FixedTimeStep and Maximum Allowed Timestep in Unity, by Lidia Martinez

Try to find any relationship between maximumDeltaTime and deltaTime in this article. (hint: there is none.)

Here's another classic explanation from Bunny83 in 2015

Although this explains how exactly a FixedUpdate calls sync with the Update calls over time, it fails to explain or even mention why would reducing deltaTime help with any such issue.

Elsewhere I've managed to find people complaining (without answers ofc) that deltaTime seems to be capped at a specific value (which from everything said so far looks like 1/3rd but it varies depending on their settings probably), as early as 2014, but much more often after 2020.

So to try and get this over with, and hopefully to make it less fueled with fanaticism, I'll compromise by saying that I was apparently very lucky for always making my own custom MyTime wrappers for the production code, as this is likely the main reason why I have never stumbled on this issue of having the deltaTime limited (except when a delta should be capped, with motion in the 2nd order and accumulation of forces involved, where this makes sense).

While I'm sure nobody likes teleporting characters, the aim of any time-based software is to be as stable as possible, not to actively pretend that the stability was always there and that hitches do not exist. As I said a couple of times already, let me be the boss of whatever feels right for my game. Not all of us grind our processors to halt with incessant garbage collection. Call it what you want, but imposing the clipped time on all users, without disclosing it timely and properly, definitely goes in my book of the most horrendous design choices made by Unity.

Given that this limitation wasn't even documented for such a long time, and that seemingly nobody cared to ever even mention such a relationship, nowhere, not even once, is literally mind-boggling to me, and another reason to be even more mindful of deltaTime in the future.

And then most of you gaslighting me how it was always like this, when in reality, it was officially described as such since October 2020. This was only 2.5 years ago. Unlike most of you I haven't really developed a habit of checking the well-established and omnipresent API every year... Especially not something as staple as Time.