Continuously teleport player in front of another player?

I’m scripting a detain tool for some people. What this tool does traditionally is continuously teleport a player in front of another player for a period of time. The detained player’s collisions are off, and they can be taken wherever the detainer wants them to go. I tried writing a detain tool that focused on welding, but there were a lot of glitches specifically around death that I didn’t think were fixable. I’ve also heard from other sources that teleportation is usually the way that most detain tools are scripted. However, I don’t really know where to start with scripting it.

I tried rescripting my detain tool to use teleportation, and it works fine server side, but replicating this teleportation to clients is pretty much always finnicky. The detained player will rapidly phase through the baseplate before being teleported back to where they’re supposed to be, unless teleportation is strictly done on the client side with no RemoteEvents involved. The smoothest way I could come up with is unanchoring the detained players HRP client side, teleporting them client side so it looks smooth, and then reanchoring them client side. It still looks weird, and I’ve seen better functioning detain tools as well. I’m wondering what the best way to make this teleportation look smoother on all clients is.

Also, how would I go about removing CanCollide from the detained player? I’m pretty sure that the character automatically turns CanCollide on, so I’m wondering how this is done. I’m thinking HumanoidStates, but I don’t know if that’s right or not.

If anyone could help me with either the teleportation or CanCollide issue, that would be great.

Thanks in advance.

1 Like

For the CanCollide issue, you can use a for loop to loop through the characters parts and set all of their parts CanCollide value to false.

You definitely do not want to try and render the actual player’s character in front of the person detaining them. That’ll introduce a range of funny network ownership feedback.

Your safest bet is to just clone the character being detained, make all their components massless, and create a weld constraint of all their pieces to the detainer’s root part. Then, have the player’s camera (who is being detained) follow the cloned character as if it were their own.

2 Likes

Hmm, interesting. So in short, it’ll be a dummy, that looks like a player.

I suggest using a weld, but you need to make sure your welding the tool to the players HumanoidRootPart server side. Welding can bring in some new bugs, but most of the bugs can be fixed by setting the NetworkOwner to the player that is detaining.

Please select this as the solution if it did help you so other users can find this faster.

1 Like

For the CanCollide issue, you can use a for loop to loop through the characters parts and set all of their parts CanCollide value to false.

I was under the impression that you couldn’t change the CanCollide values of the parts of a player’s character. Is this not the case?

Your safest bet is to just clone the character being detained, make all their components massless, and create a weld constraint of all their pieces to the detainer’s root part. Then, have the player’s camera (who is being detained) follow the cloned character as if it were their own.

That’s an interesting solution, I hadn’t thought of that. I think this is what I’m gonna go with unless someone has a solution for welding that I hadn’t thought about. I would have to make sure that if the dummy gets damaged, then the player gets damaged as well, but I think this is something I can deal with.

I suggest using a weld, but you need to make sure your welding the tool to the players HumanoidRootPart server side. Welding can bring in some new bugs, but most of the bugs can be fixed by setting the NetworkOwner to the player that is detaining.

The bugs I were experiencing earlier had to do with death. If one of the players involved in the detaining process died, the other player would die as well. I ended up using Humanoid:SetStateEnabled() to temporarily disable death for the players, but that only worked 80% of the time, with some cases working normally, some causing death of one player for only one client, or some killing both players. Would network ownership presumably solve these issues? If they would, then I would probably go with welding again.

For now, I’m going to select MrNicNac’s post as the solution, but if you know how to fix those death problems I talked about in my previous reply, I would appreciate it if you told me how.

Ah, so the error with both players dying is just due to how welds are setup inside roblox. I suggest removing the reset button in a local script just to prevent the user from resetting. Network ownership can cause the same issues but like I said above, just disable resetting for the user and finding a way to prevent that player from dying (I can’t think of a way right now)

Alright, thanks for your help. I think I’m gonna stick with MrNicNac’s solution for now because I want detained players/detainers to be able to die and welding doesn’t seem to work out too well if I want that behavior.