Creating an efficient player escort tool

Help and Feedback Scripting Support
#1

A little bit of a foreword: when I say “escort” think of a cop escorting a bound person to his cruiser, that’s what I’m trying to achieve.

So far my strategy is that when the player is hit by the cops tool this code is ran

spawn(function()
    connection = game:GetService("RunService").Stepped:Connect(function()
	    ConfigFolder.Detainee.Value.HumanoidRootPart.Position = tool.Parent.HumanoidRootPart.Position + tool.Parent.HumanoidRootPart.CFrame.LookVector * 5
		ConfigFolder.Detainee.Value.HumanoidRootPart.Orientation = tool.Parent.HumanoidRootPart.Orientation
	end)
end)

-- Connection is disconnected when the tool is unequipped or player is "released"

Which results in an “acceptable” outcome:
https://gyazo.com/04c8a1e7169e46498f4cde056de6e45f

However, this, to me, seems not as optimal as possible. I dislike how choppy the drag is and I’d always like for the player being escorted to stay the same distance from the player escorting them. (Assuming the slow transition like the movement is due to CFrame manipulation)

I was hoping someone had a similar tool that I could read over the code for and see how you achieved such effect (I’d prefer this over just giving a flat out solution being posted because I get exposed to more code) but of course any help is appreciated.

1 Like
#2

Why?

The character in server is delayed by a few milliseconds, which then causes it to look choppy and therefore creates some “lag”.

Apparently, you’ll apply a hacky solution with a cloned character(hiding the main one) that is client-sided, which will make it align perfectly. The target player will receive a similar replication.

3 Likes
#3

Hmm, makes a lot of sense actually.

I’d be stuck how how to “Hide” the main character though. Any nudge in the right direction on that?

#4

transparency and collisiongroups?

#5

I’ll have to read into CollisionGroups, I haven’t ever worked with them!

#6

They’re quite useful. All those doors that go cancollide false but let others in can be fixed. You can set a player to not collide with the door while others still can.

#7

The character appears choppy because PlayerA does not have network ownership of PlayerB. PlayerB is still in control of their own physics and PlayerA can’t influence them. This is the reason why you need the server as a medium ground to “detain” a player and it is also why the “choppy” movement occurs (the server setting a character’s position). There’s a reason why movement is controlled by clients.

Transparency, CollisionGroups, Massless, blah blah blah won’t solve the problem. This is purely on network ownership and the fact that the server is setting positions.

2 Likes
#8

Maybe u can using Weld and weld 2 character?

#9

So then I could possibly use remotes and use the client to update the player being detaineds movement?

Would this then also follow over to the server or would I need to manipulate movement on both server and client to achieve a smooth effect?

#10

You wouldn’t need remotes if you were passing physics ownership to PlayerA, who’s dragging PlayerB. You simply need to set the NetworkOwner of their HumanoidRootPart or all their BasePart descendants to the dragging player and the dragging player will update the position of the dragged from their own client.

Well, remotes would of course be needed to tell the server that a drag needs to start and for security purposes, but that’s about it.