koobas.hobune.stream
Animation error "oldWrappedTime > newWrappedTime"
With one of my animations, I am getting this error on some machines. But others it works fine. When the animations is supposed to fire on the ones that fail I get the message:
"oldWrappedTime > newWrappedTime" in the console.
It says this comes from deep in animation code.
Any ideas what this means or how to fix?
Resolved: It was basically what you said Bunny. But it actually was we changed the animation and the original frame range was outside the range of what was now exported. E.G. anim was frames 23-30 but now the whole animation ends at 20. Since I was using the function to split an animation up, when the frame ranges changed, it screwed things.
Well, there are always things you don't think of :D. You should mark your answer as solution.
I guess this applies to looping animations. When the animation time reaches the end it should start at the beginning. To get a smooth transition it takes the time you are behind the end and adds it to the starting time. When a wrap-around occures the old time should be greater than the new time of course.
I can only imagine two cases where this might not be the case:
The animation is very very short and your frametime is larger than the animation takes
You manipulate the animation time somewhere in some way that when the wrap-around occures you "go back in time".
All just suggestions ;)
I've had this problem and ignored it for a while. Just found a fix for our particular problem, and thought I'd share.
Before firing off any animation make a coroutine to wait for time scale to be reset to 1.0f
void SignalToAnimate() { StartCoroutine("PlayAfterSlowMo"); }
IEnumerator PlayAfterSlowMo()
{
while(Time.timeScale != 1.0f)
{
yield return null;
}
//Play animation
yield return null;
}
I'm using Time.timescale a lot, but I only use it for momentary pauses in our game (for hit connects etc.) So this may not be an ideal work around, but it's good enough for us.
You also need to make sure you're not firing off any animations on the same frame as changing Time.timeScale. I think, anyway.
