Why the is this useful feature animator.ForceStateNormalizedTime Deprecated

So I see is animator.ForceStateNormalizedTime Deprecated

In Depth explaination

Finally discovered something where I can directly control the current state time as I always wanted.

Yes I do know play and crossfade have it where you can start from the time you want.

Problem with this is play() and crossfade() is actually Playing a new state rather than just changing the time back. So I can not use play() or crossfade() with my own custom loop back to frame feature I have made. Because if the loopback event runs at the same frame when the player inputs IE: jump, the current animation running the loop back will over ride the jump animation.

Using animator.ForceStateNormalizedTime solves this issue because its not actually playing a new state but just modifying the current time of the current state so it doesn't override anything.

I would not needed to create my own loopback to frame feature, if unity animator had their loop feature from the old animation system or like any other engine who allows you to set a loop back to frame system.

Thoughts? I also want to know if there is actually any unspoken problems using this.

 

Yeah I support that. I'm doing some distance matching and it is very useful to call ForceStateNormalizedTime to not trigger OnStateEnter behaviour every frame. I'd like to find out if it is ok to stay with ForceStateNormalizedTime or better switch nonetheless.

 

Why is ForceStateNormalizedTime still deprecated. It tells me to use animation.Play or animation.crossFade which do different things such as calling OnStateEnter on those two vs ForceStateNormalizedTime which does not. It maintains the animation state your in.

 

You can set up a parameter to control the normalized time in the state's inspector, but I've never tried it so I don't know if it lets you only set it when needed or if that means you need to update the parameter every frame.

If you want better animation scripting capabilities, you might be interested in my Animancer plugin (link in my signature) which gives you free reign over everything at runtime - time, normalized time, speed, weight, etc.

 

Worth noting that if you link a parameter to normalized time in the inspector, it will mostly work as you expect, however it does NOT seem to respect your blend tree relative timing settings. Not sure if your Animancer plugin has the same issue or not? I'll check it out anyway since using mechanim is kind of a nightmare.

 

There are two different ways Animancer can handle that sort of thing, both of which can be tried out in the Unity Editor with Animancer Lite but require the Pro version to use in a build:

• Make an AnimatorController containing just the blend tree and use an AnimatorControllerState to play it. I expect this would have the same issue as using an AnimatorController normally because everything is handled by the Playables API.
• Make an AnimationMixer at runtime using a script. This doesn't do any automatic timing management for you (such as lining up walk cycles like a Blend Tree does), but you get full access to the sub-states so you're free to control whatever you want. By default setting the Time of the mixer will simply propogate that same value to all its children, but Animancer Pro includes the full source code so you can modify it however you see fit, inherit from it, or implement your own similar class. If you do, I'd love to hear about it because I've never actually used the current behaviour and I'm not sure how useful it actually is.

 

@Mecanim-Dev Can you please chime in on why the Animator.ForceStateNormalizedTime() function has been deprecated?

It cannot be simply replaced by Play or CrossFade in all circumstances because it triggers OnStateExit and OnStateEnter (it causes state reentry when you're simply trying to adjust the playback position of the current state).

Or is there another way to control an AnimationState's position and playback time without causing these callbacks?

 

Hope it helps someone else in the future, but I read on another thread that if you actually use anim.Play(); BUT you set the stateNameHash to 0, then it will affect the CURRENT anim state, rather than calling a new one (so OnStateEnter() will not be called again).

e.g:
anim.Play(0, 0, parentAnimNormalizedTime);

and here's the thread:
https://forum.unity.com/threads/set-the-normalized-time-of-a-mechanim-clip.476388/

 

Oh man, that's huge. The Animator.Play() documentation does mention the 0 for stateNameHash trick but it doesn't mention that it doesn't call OnStateExit/OnStateEnter... Have you actually verified that this works??