Why is the position always 0,0,0 when teleporting?

[Nerkonl]

So I’m trying to teleport a player to a part but his teleport position always goes 0,0,0 for no reason, here’s the position of the part that I’m trying to teleport the player to: 103.98, 1.025, 5950.197

Here’s the script that I’m using:

Code

print(plrCharacter.PrimaryPart.Position) -- The player's primarypart position before the teleportation
print("===================================")
plrCharacter.PrimaryPart.Position = Vector3.new(workspace:FindFirstChild("StartPart",false).Position)
print(plrCharacter.PrimaryPart.Position) -- The player's primarypart position after the teleportation

And here’s the output:

[greatneil80 (NilOfNils)]

Try this

PlrCharacter:SetPrimaryPartCFrame(CFrame.new(workspace.StartPart.Position))) 

replacement for line 3

[Nerkonl]

I fixed this issue by using the part’s position instead of referencing the part and then getting the position of it like this:

plrCharacter.PrimaryPart.Position = Vector3.new(103.98, 1.025, 5950.197)

But I still currently have no idea why it isn’t working when I reference the part and then get the part’s position instead of pasting the position directly so for people who are coming in the future who are having the same issue you just have to get the part’s position directly and then past it in like I did.

Does anyone know why this happens?

[Nerkonl]

Your method worked but mine works too, I heard that :SetPrimaryPartCFrame() has issues within it so I will just use my solution that I came up with because it’s probably better but thanks for trying to help anyways.

[greatneil80 (NilOfNils)]

What issues, can I get a link? Describe the issues, I always use SetPrimaryPartCFrame, it works like magic, all it needs is a PrimaryPart, also using MoveTo can be useful

[Nerkonl]

Here are some posts that talk about why it’s bad to use :SetPrimaryPartCFrame() and that you should avoid using it:

https://devforum.roblox.com/t/do-you-use-the-primarypart-property-of-models-and-if-so-for-what-purposes/673556/29?u=nerkonl This one is by @colbert2677 he says to avoid it at the end of the post and gives a reason why you should do that.

And here are people reporting issues about it:

SetPrimaryPartCFrame has inaccuracies

I know this has been brought up before, but when you continuously use SetPrimaryPartCFrame, the parts separate from their intended positions over time. Will ROBLOX fix this at some point, because the method is robust… but too flawed to utilize for major features.

SetPrimaryPartCFrame() isn't exact

So I’ve been working on a project for a little over a week now. This project was running smoothly until I tried to optimize my code. Lets say I have a ship, this ship contains roughly 450 parts. What I’m doing right now to move it is have all the parts anchored, move the engine part, and set each part’s CFrame relative to that engine part (the efficiency of this method surprised me a lot). Then I tried SetPrimaryPartCFrame. It ran much faster than the previous method… at a cost. After flying ar…

SetPrimaryPartCFrame() is very choppy when looped

I decided to use SetPrimaryPartCFrame() for an elevator in a building I’m working on because it’s something rather new and I wanted to test it out. However, as soon as I tested it out, I realized it’s very choppy. I’m assuming this is a bug because it would only make sense that if you move the primary part, all the other parts would move instantly. It appears there’s a short delay in-between each part’s movement. Note: this is only happening in a server, NOT studio. GIF to show what’s happeni…

[colbert2677 (ImagineerColbert)]

SetPrimaryPartCFrame is only bad if you’re using it against a fully anchored model. If you have a model that’s completely unanchored or has at least one anchored part and every other part is connected together through welds, the inaccuracies issue does not occur.

I still hate SetPrimaryPartCFrame in any case and will avoid it like the plague. I prefer to directly set the HumanoidRootPart’s CFrame if I need to send the character somewhere.