Rigid constraint actually works perfectly. Only issue is this sadly 
https://gyazo.com/61cf9d64770bc1545f1f1798aaa59b66
For some very odd reason the rigid constraint makes the other player die but only on the client?
I just tried it again and for some reason it now kills both on the server. Probably going to go back to align position.
If you haven’t already done so, parent the RigidConstraint to the player being carried, not the player doing the carrying. Or if it was already set up this way, try doing the opposite to see if that resolves the issue.
Moreover, make sure you’re instancing the RigidConstraint from a server script. If you only create the constraint on a local script it is bound to cause irregularities between players.
RigidConstraints are fairly new so this could possibly be a studio bug.
1 Like
This is also an issue with weld constraints and welds. It’s not exclusive to rigid constraints which is why I am using align positions in the first place.
I think I can stop the delay by setting the network owner of the carried character to the carrying player. But whenever I set the network owner it immediately sets itself back
I’ve quickly coded a rigid system similar to yours and have encountered the exact same issue as you. The issue is persistent regardless of the constraint’s parent, this seems to be a bug.
Another post on the forum found the same issue when working with welds:
The same post mentioned the possibility of using prismatic constraints instead, so I will look into that quickly.
However, if that doesn’t work, the best recourse would be to find ways to minimize the delay in the align position constraint.
1 Like
I’ve just finished testing prismatics and they do indeed solve the issue. However, there is a catch.
Prismatics are physics based so you will need to make the carried player massless and uncollideable. You will also need to enable limits on the prismatic constraint and set the limit to something low so that it doesn’t slide off.
So, prismatics work!
1 Like
I already actually have the player massless and uncollideable when carried. Let me try this out real quick I will get back to you! Appreciate the help a ton!
1 Like
Works perfect (almost) and fixes the death problem.
Only 2 small issues however.
-
On the client of the player being carried they dont play any animations.
-
when the carrying player rotates it takes time to adjust.
https://gyazo.com/7c19dc863dbba301ecdde6080ffa139f
examples of both issues.
1 Like
Animations aren’t my strong suit, but I know that it is best to use animator instead of humanoid to load shared animations. Try loading the animations onto Player.Character.Humanoid.Animator, further example Animator:LoadAnimation(Animation).
As for the adjustment time, try changing the restitution of the constraint. Restitution simply put is the elasticity of the constraint. I’m not sure whether or not more or less restitution would be better in this case, so test both (0 and 1 restitution).
If the orientation is still delayed, try incorporating an align orientation constraint into the code with rigidity enabled. This should alleviate most of the delay but having multiple constraints on the same object can be potentially burdensome to the physics engine.
1 Like
I already do Animator for animations.
Restitution does the same whether its 0 or 1.
I tried adding the align orientation and this happened. .
https://gyazo.com/8227029504753ae7894209b5434abcee
it behaved normally for a little bit (and didn’t fix the rotation issue.) then did the thing in the gyazo I sent.
This is the code:
local weld = Instance.new("PrismaticConstraint")
local weld2 = Instance.new("AlignOrientation")
weld.Name = "carryweld"
weld.Parent = char
weld2.Name = "carryweld2"
weld2.Parent = char
weld.Attachment0 = victim.HumanoidRootPart.RootAttachment
weld.LimitsEnabled = true
weld.UpperLimit = 0
weld.Restitution = 0
weld.LowerLimit = 0
weld.Size = 0
victim.HumanoidRootPart.CFrame = plr.Character.HumanoidRootPart.CFrame
weld.Attachment1 = char.HumanoidRootPart.RootAttachment
weld2.Attachment0 = victim.HumanoidRootPart.RootAttachment
weld2.RigidityEnabled = true
weld2.Attachment1 = char.HumanoidRootPart.RootAttachment
valstorage.carryparent.Value = char
valstorage.carried.Value = true
1 Like
Try using OneAttachment Alignment Mode instead for the orientation constraint. Clone the attachment on the players shoulder and set Attachment0 to that.
1 Like
https://gyazo.com/3af296cbc41a13093ee630478970db15
It forces the orientation of the wrong character.
I’ve even tried swapping attachment0 and attachment1 but nothing happened. Also tried switching the parent.
Try toggling PrimaryAxisOnly and/or ReactionaryTorqueEnabled on the orientation constraint.
1 Like
Tried that. Does nothing or breaks it again like the gif before
Would a bodygyro be a good option? Or do you need to constantly update that. I’ve never used bodygyros before.
Is the other player parented directly to your character or are his body parts in a folder? Because if they’re parented directly then that could be the reason why it keeps dying.
1 Like
I see. I’ve had the same issue with AlignPosition lagging behind and I had a fix for it, but I don’t have access to my computer right now. I will check out my code when I can and get back to you.
1 Like
Using the AlignPosition method, try setting the character that is being picked up’s HumanoidRootPart’s network owner to the player that is picking up the character (if you are using the HumanoidRootPart in the AlignPosition.) That worked for me.
1 Like
It doesn’t let set the network owner. It just immediately sets it back for some reason.
I think this is because the client still has control of the character. Try setting the picked up character’s Humanoid’s PlatformStand property to true before setting the network owner.
1 Like