it breaks the VR module (that roblox provides with their avatar gestures
We’ll fix this.
in the future, will animations still support being played with motor6d rigs
Yeah, we have no plan to stop supporting Moto6D animated rigs.
We’re not dropping support for spawning avatars with Motor6D’s any time soon. In a month or so we’re planning to let you opt-in to spawning with new joints in-experience. Then roughly a couple months later we’ll start looking at making this the default and how easy people are finding the migration.
Are AnimationConstraints set to supercede all that can be done with Motor6Ds? For example, animating parts on assemblies (that arent rigs) would be easiest done with Motor6Ds—is this something that AnimationConstraints could easily fill in for as well?
Hey everyone. Yesterday we added a StarterPlayer.ClassicDeath property that lets you control whether avatars ragdoll when they die without any scripts! We want to enable high-fidely content that mimics the real world and heard setting up ragdolls was a pain. So, today (currently in Studio Beta), you can disable ClassicDeath to have your players ragdoll when they die.
ClassicDeath = true: Avatars will continue to break apart on death, just like they always have.
ClassicDeath = false: Avatars will spawn with Humanoid.BreakJointsOnDeath = false, and will ragdoll when they die.
Note: Since ragdolling requires the new joints, it requires the AvatarJointUpgrade to be active. Otherwise the ClassicDeath property will be hidden and you’ll always break apart on death.
The Future of Avatar Death
The classic death style is extremely important for the feel of many Roblox experiences. It has cultural significance, and we respect that! At the same time, it can look odd on higher fidelity avatars. (Why do you go bald when you die?) We want to respect how all styles of avatars look when they die, and ragdolling does that. It works well on classic bodies, high-fidelity humanoids, and everything in-between.
Classic Death
Ragdoll Death
Our plan is to leave all existing experiences using classic death. We WILL NOT change them automatically! If you want, you can disable ClassicDeath yourself. At some point in the future we will start initializing ClassicDeath = false in newly created experiences so avatars ragdoll there. You will always be able to re-enable ClassicDeath for any experience if you prefer it.
You might notice a slight hitch at the moment of death. It happens because Humanoids transfer physics ownership to the server on death. We do this by default so exploiters can’t manipulate dead body parts. We expect this to look better if/when we have client side prediction and full Server Authority.
What would be the best way to return the character to its-pre ragdoll state? IE if I’m using proxy parts to move the joints to simulate the collision. I’d like to unragdoll the character, and return the transforms to their Original WorldCFrame.
It might depend on your proxy part setup. I can try to give a suggestion if you can explain that more.
In my tests I usually don’t have any proxy parts, so I can just run some code like this and it will restore all the joints to be enabled and kinematically animated. (For example I’d run this when a Humanoid gets up from a fallen down state). Does this work for what you’re trying to do?
for _,joint in character:GetDescendants() do
if joint:IsA("AnimationConstraint") then
joint.IsKinematic = true
joint.Enabled = true
end
end
Getting some really strange results when rotating the attachments. (That’s what we’re supposed to do instead of Motor6D C0s, right?)
Here’s a video of what I’m running into. If you change the orientation of a rig attachment & either 1. add something to the character or 2. change any animationconstraint properties, you start getting some very weird results. Setting the orientation back to (0, 0, 0) doesn’t fix it. Here’s an example video, using the uncopylocked place file (unedited):
Are we able to utilize the ragdoll system on NPCs and not the actual player? So far it doesn’t look like the ragdoll works on NPCs, I am getting errors.
Finally! THANK YOU SO MUCH! We’ve been working on the joint upgrade for our game, and we’re delaying the game’s release slightly because it hasn’t been released in the experiences yet. VERY GOOD NEWS, I LOVE YOUR UPDATE
@Homeomorph I have a question, how do I go about having the CurrentCamera not follow the HumanoidRootPart? It appears that the Root AnimationConstraint in the LowerTorso influences this unwanted movement.
The AJU itself is almost ready to release, but we’re having a discussion about where the ClassicDeath property should live. We’re thinking avatar settings like R6/R15, body scales, whether you break apart on death, walk speed, etc should all be Universe settings you can configure them in one spot and see the effects in all Places in your Universe, rather than properties on StarterPlayer you’d need to edit per place. We’d love feedback on this.
Great work on this update! Personally, I believe keeping the ClassicDeath property on the StarterPlayer per-place settings would offer more flexibility, especially for experiences that include multiple styles of minigames where different death behaviors may be needed.
Also, is a July in-experience release still on track? We’re planning around this awesome update for our upcoming game and want to make sure we’re aligned.
Currently, with Motor6D’s, editing the C0/C1 of one of those joints will directly affect the whole chain. For instance, if you flipped your Root Motor6D to be upside down, all your animations and everything will be upside down.
However, with AnimationConstraints, when you change the Attachments’ CFrames, only the affected joint will change. For instance, if you flipped your Root RigAttachment0’s CFrame to be upside down, the lower torso will be upside down, but the arms and legs will still be animating as if they were oriented the right way up, leading to situations where the animations look off.
I’m currently adjusting RigAttachments’ CFrames to dynamically tilt and adjust the player character when maneuvering over sloped terrain, but because of this discrepency between Motor6D and AnimationConstraint, the arms and legs end up being at very awkward angles compared to how they would still be in the same local rotation when using Motor6Ds.
An example of this is if you had an animation where your character’s arms pointed forwards, they will always point forwards no matter how you would adjust the RootRigAttachments’ CFrames. They wouldn’t point forwards in regards to local space, like they currently do with Motor6Ds.
Sorry about the wall of text. I’m not sure how to properly explain my issue.
Edit:
Here’s a video of the issue I’m having. I’m not sure if it’s because I have IKConstraints that are not enabled, or what, but notice how the arms want to be pulled down? This is with IsKinematic enabled.
!! This will make developing ragdolls so much easier haha. No more funky ragdoll code.