koobas.hobune.stream
animation["name"].time is always zero?
I'm trying to set up the timing of a melee attack so that it calls a damage event at the right moment- but I'm not able to get the current time of the animation clip to work correctly.
From everything I've read, animation["name"].time should return the time in seconds that a clip is currently at- if I just Debug.Log this value, it remains at zero even though the animation is playing.
Anybody have any experience with this, and why time would always be zero?
An extremely simplified version of my code looks something like this:
// note that this code is part of a coroutine that loops repeatedly while the player is attacking-
// so while it looks weird for the debug to be ABOVE the call to animate, rest assured
// that it is actually animating when the Debug.Log is called.
Debug.Log(behaviorController.meshRef.animation["attack2"].time);
if(currentTime < nextAttackTime)
return;
behaviorController.meshRef.animation.CrossFadeQueued("attack2", .4f, QueueMode.PlayNow);
currentTime = Time.time;
nextAttackTime = Time.time + 2f;
Okay due to some confusion on the code I posted- there is an interval check in my code that prevents the animation from queueing every frame. It's part of a much larger logic sequence that I didn't have time to parse out for my post.
The animation is definitely playing, and is not queued every frame- it happens every couple of seconds (roughly the length of the animation)
Thanks for the responses guys- I figured out the problem through trial and error. It turns out, CrossFadeQueued does not seem to update the AnimationState ever, so time is always going to be zero. I tested it out in an isolated environment and only fired CrossFadeQueued once- and time never moved past zero.
So I added a bit more logic to give me the same functionality that I was using CrossFadeQueued for, changed it to CrossFade, and now animation["name"].time correctly outputs the correct timing for the animation.
Did you even read my answer or the docs on CrossFadeQueued carefully? CrossFadeQueued returns the AnimationState it has duplicated. Accessing the original AnimationState would of course give you not the right values.
I'm not resting assured - from the docs:
If queue is QueueMode.PlayNow this animation will start playing immediately on a duplicated animation state
So you are debugging the animation state before it is duplicated. We'd have to see more of the loop to understand what you're trying to do, but certainly that's why your Debug is not showing anything.
Yeah, sorry- that's my fault for not submitting enough code. I was in a bit of a hurry when I posted it- but I've gone through and made some notations.
The problem is that Animation.CrossFadeQueued is a very special function and it shouldn't be called each frame! Unity will actually clone the animation (so there's another copy of the same animation) and save this call internally. When the current animation is finished it will play the clone automatically. It is cloned so that it can crossfade even to itself. Is there any reason why you use CrossFadeQueued?
CrossFadeQueued returns the duplicated AnimationState but as the docs say, be careful, the Animation state will delete itself after the animation has finished.
I would suggest to use AnimationEvents for your "timing".
I don't have much experience with AnimationEvents, I'll defintely give them a good investigation. Thanks for the tip, and the reply.
Looking into AnimationEvents- all of my animation clips are read only. This is a skinned mesh imported via FBX if that matters... Is that normal? All of the examples in the unity docs are animating values such as transforms and public inspector variables... are you sure Animation Events can be applied to a skinned mesh?
An animation is still an animation, no matter what you animate. Actually imported animations also just animate the transforms of the bones, nothing more. The animation has no relation to the skinned mesh. Only the skinnedmesh have the link the the bones so the model gets animated because the bones are animated.
You are right, Unity have problems with imported animations because they are read-only. In our project i wrote a small script that extracts the animations as .anim files so they are seperate animationclips that can even be edited in Unity. But it's easier to add the animationevents via scripting. With AnimationClip.AddEvent you can add events at runtime but have in $$anonymous$$d that AnimationClips are shared between all Animation components so adding an event multiple times will fire it multiple times. $$anonymous$$ake sure you add every event only once game-wide
