Isn’t this already a thing? You could just make your animation not affect certain Motor6Ds/Bones. Then when playing the animation, you can set the weight of it, so it gives it like a mixed/added feel to it. I don’t know if this and additive animations are the same thing, but this is what I do to replicate a half version of it.
So cool to bad I don’t know how to code that good
You should make a feature request because I doubt that Roblox will even read your request here. But yeah, that would be a nice addition to the engine.
It’s not really true additive animation since it still blends the animations together instead of adding onto the previous transform of the animation, but since that’s your intended use case there’s no complaints there.
You can do this by using different priorities on the animations as well as authoring the higher priority animation only animate certain limbs.
Amazing! Quick question though, is the issue of AnimationTrack.Looped not replicating fixed? I haven’t tested it myself but since that post seems to remain with no solution gives me the sense that no.
But can a staff member confirm is fixed please?
Fantastic! I look forward to using this once I need to, which is inevitable. It’s always nice to see functionality expanded upon.
May I mention, you can easily implement the cleaning process with the Animator.AnimationPlayed
event.
Animator.AnimationPlayed:Connect(function(animationTrack)
animationTrack.Ended:Connect(function()
animationTrack:Destroy()
end)
end)
Nice one! Now I ran into an issue with .Stopped before, now I can delete my old whacky solution.
I have once tried this event before, but it does not work. It`s grateful to see the progress of animation controlletion. Great Work Roblox!
I always enjoy seeing improvements to the animation system.
Are there any plans to allow for scaling of animation positions, during runtime, or during the track loading?
No. Animation blending and animation addition are not the same thing.
That is not additive animation, that is simply blending.
The two animations will only blend together if they have the same priority. What you want to do can easily be done with animation priorities.
The default “hold tool” animation is an example of this.
Does this fire inbetween loops if a track is looped? or just on non-looped tracks? Please update w/ information
What? I thought task.wait() was better to use than wait(). Why is it a code smell?
Generally when it comes to detecting animations, it’s because waiting is inaccurate if Client has a different fps which makes task.wait() go after even if the animation is still playing in slower playback.
also as they’ve mentioned
task.wait() isn’t always a solution but it doesn’t mean task.wait() is a bad practice to use
Does it fire if AnimationTrack is not looped and finishes on its own: yes, it should.
If you don’t delete the track does it fire again if track is stopped again: yes, it should (you’d have to also “play” it again).
If you test & find it doesn’t behave like this, let me know (reply on thread with code/details on what you’re observing).
Does it fire inbetween loops if track is looped: no.
This fires when the animation track is completely done affecting the world.
- The track is non-looped, it completes playing and stops of its own accord (and is done with any fade out effect).
- The track is stopped ‘manually’ with a call to “Stop” (whether looped or non looped), and completes its fade out.
Please let me know if you observe something different from this (reply to thread with code/examples, highlight expected vs actual behavior).
Task.wait() is code smell, which means you should always use the alternative. If you check whether the track has stopped playing, do task.wait() until the fade out is complete, when you could also use this new method, using task.wait() becomes bad practice.