this breaks the animator script when toggling Enabled
it appears the syntax here is completely wrong
here’s a simple fix:
here’s a simple fix:
6 Likes
One of many horrifying discoveries I made when I was reading the code for this lol. It only passes initially because the LocalScript starts before its children are replicated, so the body is never iterated over.
9 Likes
OH MY GOD I’ve been contemplating for a very long time if I should achieve this myself and they read my mind!!
I hope this wont affect R6 characters
1 Like
I’ve always wonder if something like this would be added natively to the game, and I’m glad it is.
I love the way it looks, with the mostly clean transitions and what not. Although R6 isn’t supported (by what I know), I still can’t wait to see where this will go in other character animation bundles!
1 Like
When will R6 get access to this too?
1 Like
No, it implies that there are no plans for the future at this time
4 Likes
This is totally amazing. Adding better walk animations to R15 is great! But what about R6 humanoids? Will there be any support to it?
This is very cool!!! I hope to see this available across more animation packs in the future! 
1 Like
This update is great and is a time-saver if you ever wanted to make movement like this, people might need to remove some scripts from their game to make it work properly, because developers would make scripts that change the joint’s CFrame to make it change depending on your direction, and if this is going to be implemented in R6, it’ll be very helpful, I’ve wanted to do this kind of thing but got stuck in MoveDirection. I tried telling people on the forums about my issue, but the replies just didn’t have what I needed.
1 Like
nice, a change that’s been overdue for a while, even though i implemented it into my games on my own already, lol
Awesome job! This is basically a big improvement for open-world games or my future projects.
I love this update, better mechanics and actually realistic! Awesome change. Something I’d happily adapt to.
This update basically replaces any sort of custom movement system one in the past had to make on their own (ex. IK or inverse IK I forgot), love it!
Please extend this to the other animation packs, I’m sure many are holding back on commenting, it would be lovely to have it. An use case for me would be I’m making a forced R15 system and I’d like to let my players pick animations provided by Roblox from a catalogue. They’d be using the features provided to get them the most organic experience possible (ex. much better visuals during moving - imitating juking plus feeling more so realistic).
2 Likes
Thanks for your continued detailed feedback!
As mentioned in the announcement, dependency on AutoRotate and RotationType has been removed internally and this change will arrive “very soon”.
As of today, we do not rely on AssembleyLinearVelocity for animation purposes because it is not platform-relative. eg, if you were on-board a fast-moving train running toward the back, it would report that you were running in the opposite direction.
5 Likes
i wish we could have this for r6 too
5 Likes
This actually looks very cool! Now the only way to moon walk is by using the old
Moonwalk potion gear
This will definitely help on making Roblox look more realistic…
It kind of looks like inverse kinematics
Yes, documentation will be forthcoming.
As we are in Beta, the method is not guaranteed to be frozen in place as is.
That said, as the code and default strafing animations objects are publicly available, you can deduce from the current script and from the Animation objects themselves that simply adding LinearVelocity attributes to the Animations will cause them to be stored in the locomotion map for blending consideration. and that strafing will be active if all four quadrants are represented in the map.
There is no requirement on the number of strafing animations utilized.
I actually have a corrective measure in place for this! I query for assemblies near the humanoid’s stage and subtract their velocity from the measurement 
Relevant Code Snippet:
local rootHeight = rootPart.Size.Y / 2
local hipHeight = humanoid.HipHeight
local floorOffset = Vector3.yAxis * (hipHeight + rootHeight)
local floor = rootPart.Position - floorOffset
local parts = workspace:GetPartBoundsInRadius(floor, 1, overlapParams)
local velocity = rootPart.AssemblyLinearVelocity
local compensated = {}
for i, part in parts do
local root = assert(if part:IsA("BasePart")
then part.AssemblyRootPart
else nil)
if not compensated[root] then
velocity -= root:GetVelocityAtPosition(floor)
compensated[root] = true
end
end
3 Likes
I believe they let stringvalues stay to either preserve old behavior / change animations in game by just changing the value(?).
Either ways the animate script was never optimized. An example would be that it loads animations on the “Humanoid” rather the “Animator”. I’ve rewrote the script for my game and I eventually ended up with a perfect working animate script (without major blending support, which will be fixed as this came out).
Roblox (old) animate script #803 LINES OF CODE
VS
My condensed Animation Script #185 LINES OF CODE
(Heavily based off API and legacy Animate script)
Pros and cons
My script does NOT change animation at runtime with values, I’ll be linking it up to attributes.
My script only runs based on events.
Roblox’s Animate script probably can change at runtime, perhaps.
Roblox’s Animate script runs too much, mirroring on “script performance”.
@bloxmaster0808 Would it be possible to address these issues? I sat down and saw it still uses somewhat same behaviour as the last Animate script.