PivotTo() doesn't always work

Help and Feedback Scripting Support
#1

In my game, I notice that on rare occasion a player might not get teleported like they should. I never get an error or warning and the code never yields, the player just doesn’t move. Maybe setting the hrp CFrame would be better?

local character =  (player.Character or player.CharacterAdded:Wait())
character:PivotTo(destroyerSpawn.CFrame)
#2

Are there any other details in this script?

#3

Make sure that character parent isn’t nil before teleporting

#5

Yes, for models that are moving you should use directly the PrimaryPart of the model over Pivot().

PivotTo() also has a bug that sometimes it can trigger the Humanoid:MoveTo() method.

local function bring(player: Player, otherPlayer: Player)
	if not directors[player.UserId] then return end
	if not sanityChecks.target(player, otherPlayer) then return end
	if not limiter:isOver("bring", player) then return end

	local character = player.Character
	local otherCharacter = otherPlayer.Character

	if character and otherCharacter and character ~= otherCharacter then
		otherCharacter:PivotTo(character:GetPivot()); print("bring")
	end
end

→ video of the bug in action:

1 Like
#6

I VERY highly doubt that… I think the issue is other parts of the scrpt.

#7

The code in the post is the quite literally the code used. the print only prints once per click, and there’s no loop nowhere at all, and the client side is just a FireServer. edit: The problem is not my code.

You might think the issue could be Iris internal, but again, there’s a cooldown in the server-side of 1s.

image

#8

I don’t know what you’re talking about, but how would you possibly know what he’s doing. How do you know the code is what is being ran?

#9

I might have confused you. My post isn’t his code, it’s directly from my place. The reason I shared is because OP thinks PivotTo() “doesn’t always work,” so to add on to that I shared my case with PivotTo() as well, because this could catch the attention of a staff member.

#10

OK. I think the issue isn’t PivotTo(). I think it’s likely that the player is being moved too close to a part and the character’s default scripts are moving the character similarly to what would happen with Humanoid:MoveTo(). I use PivotTo() a lot and in every case I use it, it behaves exactly as setting the CFrame would.

#11

That could be the case yeah. But it doesn’t remove the fact that something really is happening, so either Roblox should fix their PlayerModule or check if anything is going on with the physics replication and PivotTo()

Either way, that’s a good theory, so I’m going to keep experimenting with this.

#12

Can you record a video of what happens? (OP)

#13

I removed the PlayerModule from player2 who doesn’t have access to Iris and he is unable to move at all.
image

But same problem, in conclusion: this isn’t a problem with the ‘PlayerModule’ but PivotTo() or Humanoid:MoveTo() or in extreme cases, the physics replication.

#14

I meant the OP, I realized that we didnt help fix the OP’s problem.

#15

Alright so, @Ryguy903, there really is a problem with PivotTo() which could be related to:

  1. Humanoid:MoveTo()
  2. Physics Replication
  3. Models or NetworkOwnership

I also tried using on my original place with Iris:

Model.PrimaryPart.CFrame = Model2.PrimaryPart.CFrame

But the issue is the same, though it lasts way less.

Here’s the same issue addressed earlier on a brand-new place:

And here’s the repro file:

PivotTo() bug.rbxl (54.7 KB)

#16

I think it might just be his implementation. I think it may be inconsistent in combination with the default character scripts, but I doubt it won’t teleport them at all like OP details.

#17

I have discovered that if you set the collision for both players to false using PhysicsService, PivotTo() finally works perfectly fine as it should.

So this was really a problem with physics replication and how both humanoids interacted with each other BaseParts, I think one tried to steal the NetworkOwnership of the other.

@Geolio9 I think your previous theory was 100% right.

In this case, the part are player1 descendants of the character. Perhaps, PivotTo() works to well for its own good?

#18

You always have network ownership over your character and anything you have network ownership of you handle the physics for, so there should be no issues with physics replication. I think it’s the humanoid scripts.

#19

I agree that each player has ownership over their character, but if the latter would be the case PhysicsService should not have fixed the problem, or the problem should not have existed to begin with, so I really think there is something else going on.

I literally had to remove Collision physics between both characters in order to fix, so the problem is physics replication, especially collisions.

#20

Try using CharacterAppearanceLoaded instead of CharacterAdded, or just simply waiting a frame.

If this doesn’t work, then check if you’re using streaming enabled and make sure this part exists.

#21

There is no problem in the video. The characters are simply colliding because they were set to overlapping CFrames on the client.