Edit: This model is now deprecated. You should use this instead:
With the advent of R15, the popular R6 ragdolls may not be preferable to you. There are some R15 ragdolls in free models right now, but they’re built to work with the no-package. None of those suited my needs, so I developed my own and am giving it to the community. Here are some clips of the ragdoll in action:
As you can see, there are some nice benefits to this particular model:
Original character body is preserved
No flickering on other clients due to replication lag during switching models
Any forces applied to the character at death (e.g. explosion) continue applying to the ragdoll
No need for scripts to make special differentiation between character and ragdoll
Camera follows ragdoll instead of invisible part
Accessories are preserved
Packages are respected, and not overwritten
Compatible with variable character scales
Joints behave in a realistic manner
There are some issues with sockets turning around and some issues with elbows, but those will have to wait for ConeConstraint to be shipped
Edit: To clarify: this does work with FE – wouldn’t be suitable for public release otherwise
@Simbuilder was able to help to an extent, but it looks like depending on your package your character may have slight spasms as you can see in the gifs. As far as I know, it’s impossible to resolve this on our end, and constraints will need to be worked on. In the end, this is ROBLOX, so I’m not sure players will mind.
Oh thank goodness, this might make adding R15 to Super Bomb Survival far easier; I wasn’t looking forward to creating constraints for all the new body parts. Thanks for this!
I’m getting strange behaviour with FilteringEnabled. If another player touches a ragdoll, the ragdoll falls apart. I’m assuming this is due to the first player stealing network ownership.
I tried to force the ownership via SetNetworkOwner, but no dice.
One of the features of the ragdoll is that your camera follows it, rather than the invisible HumanoidRootPart. I didn’t modify the camera at all in case developers were manually changing the camera themselves – instead I destroyed the HumanoidRootPart which automatically focused the camera on the character.The HumanoidRootPart is the root part of the assembly, so it looks like destroying it resets network ownership. I didn’t notice this in my test because I only ran a single client on a test server.
I’ll change it so that CameraSubject is set to the root of the ragdoll instead of deleting HumanoidRootPart and that should resolve the issue. I can make sure CameraSubject still is set to Humanoid before changing it with the ragdoll to avoid conflicts with changes to the camera made by the developer. The HRP could still fall out of the world and cause the same issue though, so I’ll try anchoring it – it shouldn’t affect the ragdoll since they’re not attached. I could also move the HRP to elsewhere in the world so your body isn’t getting propped up against an invisible part. If this causes issues though, I’ll just settle for setting CameraSubject.
Just released a fix. It turns out destroying the HRP wasn’t what caused the network ownership to transfer to the other player – when ROBLOX breaks the joints of the character, they all have their network ownership reset (this probably shouldn’t happen and the client should continue owning their dead, unanchored body until they respawn @Khanovich).
Despite this, I did switch over to modifying CameraSubject instead of destroying the HRP, as that seemed a bit hacky. To resolve the ownership issue, I set the network ownership of the UpperTorso to the character’s player – this worked fine for me in a test server with multiple players, so I’m not sure why you were having trouble. Due to this implementation, the ragdoll now has a server counterpart when previously it was 100% clientside. Another minor addition is that I disable collisions on the HRP to prevent the ragdoll from colliding with it, and anchor it so that it doesn’t fall through the world and get destroyed, breaking scripts that are ill-prepared for limbs falling out of the world.
If an object is Network Ownership Manual, when you break joints, the ownership should immediately be transferred to the newly created assemblies immediately.
If it is a Network Ownership Automatic part, the Humanoid Root Part was the ONLY thing that ever had a Network Ownership set on it. All the other parts are technically “unassigned” as the server never processed them. If you delete the HRP, you have to wait until the server assigns owner to the new root of the character.
It might make sense in the future to extend the automatic ownership transfer for the sake of simulation like we do for Manual parts.
Looks great! My only complaint is that they twitch after they initially fall down(2nd and 3rd gifs). This still is a very useful tool for developers, thank you.
Yeah, as I mentioned at the end of the OP this is an issue with constraints that is likely unavoidable on our end. Perhaps @chefdeletat can shed some light on the issue, or see if there’s anything that can be done to the backend to make sure this doesn’t happen if it’s unavoidable on our end.
You should be able to setup the constraints in a way they don’t twitch. It’s question of making sure there are no over-constrained situation and mass ratios of interacting parts are close to 1. I would have to investigate your model more closely to figure out the problem, but I’m confident you’ll be able to fix it with more tweaks.
Here is the character I’m using. These are ROBLOX packages, so tweaking really isn’t an option:
Manual tweaks not possible; need to be able to dynamically work with all existing and future packages
Unable to unlink limbs’ render model from physics model since MeshPart MeshId is unreadable
Attachment points are strictly defined by the package and should not be changed; changing them would result in weird behavior such as the arm rotating around the center rather than the shoulder
The only variables able to be changed are density and the angles the limbs are able to limited to. I don’t think mass ratio is an issue here since there’s nothing weird about the character’s physics model, so we’re left with changing the angles the limbs rotate. That’s not much to go on.
The ragdoll is in fact overconstrained:
I’m not sure how that’s possible though because those parts are connected with a BallSocket constraint. I thought that disabled the collisions between them? If not, it’s physically impossible for the ragdoll to not be overconstrained because those two parts absolutely have to occupy the same space – that’s just how ROBLOX packages work.
Hi (: thanks for making this awesome script ; I only wanted to say that I made the very first really working R15 ragdolls , but sadly my non-existing coding knowledge didn’t allow me package and custom player size support ):
So I am glad that a real scripter finally made a better script (:
Also i wanted to ask does your script add the constraints after player death or before ? cause mine adds all attachments and constraints on player spawn ; which seemed way more efficient then the classical after death variation ; so simply to prevent lag and player freezing on death
The constraints are added on player death, but there is no difference in performance either way. They are created locally so there’s no latency involved, and the resources required to instantiate them are negligible. Even the lowest-spec machine would not notice a difference between adding on death and on spawn.
