I think that’s the same gif.
1 Like
It is, this is the issue.
OK. If (from my understanding) the two players are welded together, then maybe the problem lies with physics itself. It looks like you are literally pushing the player. Maybe solve this by making the CFrame value of the victim player an offset of your players current position. Again, I may have no idea what I’m talking about. I’m just throwing something out there.
1 Like
I actually created a “detain” or handcuff tool for one of the groups I was formerly associated with, or rather was familiar with how it worked. Originally it was a LocalScript HopperBin by Ethancomputermad, all we did was turn it around to be FilteringEnabled.
Essentially, what the tool does is anchor and offset the HumanoidRootPart of the victim about 2.5 studs in front of the handler that’s using the tool. Sometimes, we meet edge cases when people reset or something else unintended happens, though that seems to work alright.
Our model isn’t exactly the best, but you’d definitely want to go for some kind of root part offsetting.
1 Like
Wouldn’t I need to keep the CFrame updated, if so how would I do that?
Try setting the cuffed player to his PlatformStand state. When a player is set to this, they can’t run(or move by itself) in any way and makes all of their body non-collidable except the humanoidrootpart.
if Target then
Using = true
RemoteEvent:FireClient(player,'Use')
local CuffedUser = TargetTorso.Parent
local CuffedUserHumanoid = CuffedUser:WaitForChild("Humanoid")
CuffedUserHumanoid.PlatformStand = true
weld = Instance.new("Weld")
weld.Part0 = PlayerTorso
weld.Part1 = TargetTorso
weld.C0 = CFrame.new(0,0,-3.5)
weld.Parent = PlayerTorso
end
of couse you have to make sure you disable PlatformStand when you let go of the player
1 Like
Maybe when you cuff the person, disable their walking, turn off all their collisions, and change the hip height?
Yea, that what I basically said. Lol
1 Like
Use a loop of some kind. You can either use a while condition do loop or something from the RunService. (BindTo)RenderStep(ped) for the client, Stepped for the server.
2 Likes
I don’t think this way is really efficient. You doing a while loop on the server constantly as long as you holding that player, updating his position every frame. When I look at the gif again, it looks like the player is somewhat getting stopped from colliding with something. To stop all collisions with a player you would set PlatformStand on the user to true. This not only makes every part of the user non-collidable but also stops him from moving on his own and you can still play animations while in this State.
1 Like
I think you’re looking too much into it. Offsetting a HumanoidRootPart is not a complex operation nor is there anything inefficient actually happening here. Inefficient loops are when you run expensive functions very quickly at small intervals.
PlatformStand has no bearing on collisions and animations can be played outside of PlatformStand as well. Player movement is input and can be disabled by sinking input on the client.
Collisions can be nullified using collision groups. PlatformStand basically makes characters “limp” - it was intended for skateboards. It sets the Humanoid to the Freefaling state.
I’m not an expert, but maybe you could try welding all the prisoners limbs?
1 Like
As you said, PlatformStand nullifies player movement and basically makes them “limp” and within the poster thread, it said that he needed the detained player can’t move the holder of the cuff around. When you enable PlatformStand, you will see that all limbs except for the player’s humanoidrootpart become non-collidable(You can test this on your own by simply setting your player’s PlatformStand off and you will see that his legs would feel through the ground). When you weld an unanchored part to another unanchored part(basically two parts that is affected by physical) what’s happening to either part with mess with the other part. The detained player’s legs could possibly be messing with the weld so to make sure that this isn’t the case, you should set any person that is cuffed Humanoid state to PlatformStand. Also, it would be easier if you just enable it instead of setting up collision groups. Also when you set the humanoid to PlatformStandand check its current state(by using the GetHumanoidState function) it would say the state is “PlatformStanding”.
1 Like
That wouldn’t work, it would most likely cause more problems and could fling the welder.
What do you mean? This is always the case. Every part in a humanoid is not collidable by default. The only parts that have collision are the head and the HumanoidRootPart (or Torso?), which are set every frame to CanCollide true on the backend.
The reason why PlatformStand makes characters limp and allows them to clip their legs through the ground is because the Freefall state (which is set by PlatformStand) disables the downcasting done on the backend that makes the characters able to stay on parts, despite having limbs with CanCollide as false. They then rely on the collidability of any parts to not fall through the ground.
The collision of parts has no bearing on welds, only on the physics applied to a part.
Sorry for not responding to that, what I mean as to disable collision is to stop it from colliding with something that would stop the weld from moving which will make the connected welded part stop as well.
Sorry for that as well, what I was saying is also incorrect, you are right about the Freefall state but that is my point. There is some type of force keeping the humanoid on the floor, this is the HipHeight which determines the distance (in studs) off the ground the Humanoid.RootPart should be when the Humanoid is standing. It must be set to 0 to make the Humanoid go into that fall position(which is the reason why it looks like the leg isn’t colliding with the floor anymore) the whole point of me wanting the legs to stop colliding is so there no way for an object to mess with the weld. I suggesting that you use PlatformStand to make sure that there no force that could mess with the humanoid you detaining except for the humanoidRootPart. If we look at the gif again, it seems like the detained player is getting dragged or trying to push something out of the way to continue moving. With this logic, to see if it is because of something messing with the physical of the weld, the op should set the humanoid State to PlatformStanding.
HipHeight isn’t a force. Humanoids are kept above ground using downcasts on the backend and HipHeight is a property that helps developers to modify the position humanoids are to the floor during those downcasts. Outside of that, yes you can be right. I would suggest forcing the Freefall state as opposed to using PlatformStand personally, but whatever floats your boat.
And again, welds don’t have physics applied to them. Physics are only related to BaseParts.
1 Like
Alright, good that we found some common ground. Now all to do is wait to see if this fix the op problem!
When playerA handcuffs playerB, set the network ownership of all of playerB’s character parts to playerA. Then make all of playerB’s parts massless from playerA’s client. When the player is let go / unhandcuffed, setting network ownership of playerB’s character back to playerB should do the trick. It might also be worth setting platformstanding on playerB’s humanoid to true from playerA’s client, while handcuffed, so that playerB’s movement is ignored.
EDIT:
Keep using welds, use these functions & properties:
You might want to use collision groups like people above say, if you do do this it might be better to set the collision group from the client of PlayerA by getting the id of the collision group using this:
and then setting it like a normal property. This way you don’t need to do much else when setting ownership back to PlayerB.
Well not exactly collision groups but enabling platformstand. The body of the humanoid is already non-collidable so using collision groups won’t do anything, enabling platformstand will set the HipHeight to 0 which basically makes everything but the humanoidrootpart non-collidable.
1 Like