That’s huge, thank you. After flip if everything goes well maybe consider posting to the threads I linked earlier with more specific numbers / details, lots of people have been waiting on improvements to this limit.
Could you address this bug? Place file is attached.
UPDATE: New features changes related to the “10 new animations per 10 seconds cap”.
- Successfully loaded animations no longer count against the cap.
- The cap has been roughly doubled in size.
Thankyou for your feedback!
We are addressing this issue.
For some reason this feature has stopped working in my studio and I’ve changed nothing that would disable it. Any reason why it wouldn’t be working?
I think this looks great but i can’t stop thinking if this feature will be default like Pivot. I still think it was unnecessary and useless update and some people liked it but thats not the case now. As an Animator i think this will save me from coding a character to play different movement animation whenever a player moves to another direction.
Shift-Lock might be a problem and i wish it was suitable for the R6 but R15 would be more suited for this update.
Due to its new system there will be/might be a lot of bugs and integrating this feature into old/previous updated games can be exhausting but I’ll give it a shot.
I wish I could use this future but because it is a beta feature and I have not been accepted I am afraid it will be a while before I will.
Oh, my bad. I did not really understand what that part meant until now. Thank you.
My game won’t save the UseStrafingAnimations state.
General improvements for the most flexibility
The most effective way to improve this feature would be to include animation options within the humanoid or rather have an additional instance like the “Humanoid” but called “Animation Controller”.
There are other ways you could add these features in but this is the most logical way I could think of it.
The options within the controller would be as follows:
-
Animation List
[Walk]
[Run]
[Jump]
[Create new +] -
Blend Options
[Linear]
[Sine]
[bounce]
More…
These “Animation Lists” would have options to add your own animation ID’s which would let you be able to choose what animation plays when you press whatever key, In this case people can create as many custom characters as they want and play any animation they want on them. When you create a new animation action you should be able to select or input the key you want to use and then the animation ID and the blend type.
The “Blend Options” would determine the blending type between each animation, you should be able to set these for each animation you create.
Having this visually as an instance like a humanoid would be incredible and easy to manage.
The main goal of this feature is to allow players to easily configure the animations they want for their character, the default character could have their own defaults already built in.
Additionally you could include the camera rotation options whether the player wants it locked or not etc…
This would be an incredible improvement with tons of ease of use! for anyone.
If you want to create your own custom movement you can always do that too!
Over the years I’ve been on Roblox one of the main difficulties is to create an animation system that is different from the “defaults” and lets the player have easy control over their character, whatever it is, R15 R6 or Custom, this feature would allow you to create mostly anything, its not perfect, there would be some flaws in my idea but its a good start.
Any edits to the Idea will be added below:
Thank you!
Same, cant get it to save at all
I really like how the legs and body move with this feature enabled, but is it intentional that the character looks at the ground while running?
It’s less noticeable when walking, but still present:
Sometimes the head also jitters side to side in a very strange way:
Bit hard to see in this gif, but if you walk forward and look at your character’s face you can see what I mean.
This is probably due to animation blend dithering.
@BloxMachina this issue still exists, despite being reported ~2 months ago. Should I file a bug report instead of bringing it up here as this is no longer a beta feature?
Thanks for your feedback!
What’s likely happening here is simply poor communication on our part. The UseStrafingAnimations property is only relevant server-side, and is not replicated to clients…
There’s a good chance that strafing is actually active in your game but the property shows up as “Off” in the client view.
You might want to check the value by switching to server view.
We’re looking at ways to make this less confusing.
What are you talking about? Why should we check strafing on the server if the result is visible on the client? The feature just doesn’t work right UseStrafingAnimations not working
Since UseStrafingAnimations is not scriptable if it doesn’t save when ticked in Studio there’s no way to enable it.
appreciate the script however I’ve been stuck on an issue and wondering if someone can assist:
I’ve been trying to change some variables to accomodate my current place’s walkspeed ranges as the current script doesn’t act how I want it to
local baseRunSpeed = 16 / 1.25
local baseWalkSpeed = 8 / 1.25
I’ve altered the above and come up with buggy results, where walk animation is seen however when sprinting, the body becomes stiff (t-pose like)
I really want to change it because when my character is normal walking I don’t want the head tilted at all like it is in the running animation, however when actually running I am totally fine with it
here are my ranges of walkspeed for more context:
anything less than 14 or = should trigger walking anim
maximum walking-walkspeed: 14
anything greater than 14 should trigger running anim
running walkspeed maximum: 22
When you publish a place file with Players.UseStrafingAnimations set to true and then play that game, do you get strafing behavior when shift lock is set? What about when you bring the game back into studio?
As mentioned before, the client version of the property current does not reflect the server version of the property, however this should have no impact on gameplay. We are looking into changing this behavior.