Hi. I know your first thoughts are that a post already like this exists. However, my problem is not that. I am currently using the command bar to copy and paste a stair model to create a very long stairwell. When I try and move the primary part of my model, it only moves itself. Here is the code I am using:
local primary = game.Workspace.Model.PrimaryPart
primary.Position = Vector3.new(0,50,0)
I have tried welding the whole model to the primary part but that did not work either.
Deprecation doesnt mean it wont work. It means future updates may prevent it from working. And It has yet to be “deprecated”. Since pivot is still technically being worked on. For now setprimarypartcframe is the better choice until its actually classified as deprecated.
For large models, because PivotTo uses what BulkMoveTo under the hood, PivotTo is the better option for performance. Also, it doesn’t have offset issues, unlike SetPrimaryPartCFrame.
I mean I dont have offset issues to begin with because I make all of my assets. I know exactly how things are gonna be positioned even before they spawn in the game. You say its better for performance > but thats not entirely true if you dont program something correctly you can just destroy performance. Because SetPrimaryPartCFrame has been around so long theres so many tutorials on how to use it > you just cant go wrong with using it. As for larger models I dont even have a problem with those when it comes to setting the cframe If I need a direct placement I can just use a smaller part in the center and set that as the primary part. Like its not that complicated. Theres literally 0 reason to use pivotto right now. I 100% promise you if we both script a model me using set cframe and you using pivotto I will for sure have better performance and ping out my scripts.
local ModelCFrame = CFrame.new(2, 5, 0)
function PivotTo(Model)
Model:PivotTo(Model.PrimaryPart.CFrame + Vector3.new(0, 0, 0.05))
end
function SetPrimaryPart(Model)
Model:SetPrimaryPartCFrame(Model.PrimaryPart.CFrame + Vector3.new(0, 0, 0.05))
end
wait(10)
local GamerModel = workspace.Trampoline
local StartTime = os.clock()
for i = 1, 10000 do
GamerModel:PivotTo(ModelCFrame)
end
local EndTime = os.clock() - StartTime
print("Pivot To: ".. EndTime)
local StartTime = os.clock()
for i = 1, 10000 do
SetPrimaryPart(GamerModel)
end
local EndTime = os.clock() - StartTime
print("SetPrimaryPart: ".. EndTime)
Also, you can literally replace SetPrimaryPartCFrame with PivotTo and it will work fine, it’s not like PivotTo is some foreign language.
This is an issue with the SetPrimaryPartCFrame function, not the model.
lol alright think what you want, I could still get way better performance out of SetPrimaryPartCFrame > like you honestly think you’re getting good performance out of
function PivotTo(Model)
Model:PivotTo(Model.PrimaryPart.CFrame + Vector3.new(0, 0, 0.05))
end
function SetPrimaryPart(Model)
Model:SetPrimaryPartCFrame(Model.PrimaryPart.CFrame + Vector3.new(0, 0, 0.05))
end
xd I adjusted your script a tiny bit and already got better performance out of it. I didnt even rescript it at all I just changed a few things and its way better. and by performance I mean for both of them. Of couse SetPrimaryPartCFrame will always be behind PivotTo using the method you used to script them. Theres a million different ways to script something and in a couple of those ways theres a way to make set primary a lot more efficient than pivot to. Just because you dont know how to doesnt mean its not possible. By default though someone new to using pivotto could easily mess up performance a ton which brings me back to my main point as well as the solution of this question which is to just use SetPrimaryPartCframe c;
I mean if he wants to opt in for pivotto then he perfectly can, no ones stopping him.
For some odd reason, SetPrimaryPartCFrame outpeforms PivotTo when you’re setting it to the same CFrame over and over. You will almost never do this in the real world, which is why I changed the CFrame every iteration.
Well that is one way, but theres a couple more good ones to use. I script a lot of abilities that use models > and a lot of my effects are client side using setprimarypartcframe has shown outstanding results. Needless to say if its never actually deprecated then I will always opt in for set primary. But I will add to this there are ways that pivotto is better I’m just saying someone new to using pivot can completely destroy performance. But that doesnt mean the opposite isnt true either. Heres a gif showing that when I messed with your script just a tiny bit the performance changed dramatically. Wip Workshop - Roblox Studio (gyazo.com)
As I said the performance will be better if I script it, not if you. Just throwing it client side and scripting the model using set primary wont make the performance better I know thats how you thought it worked, but sorry to disappoint .
It is a benchmark, it is literally the best and most balanced way to measure the performance of a function. I’m not really sure how you scripting it would change that.
I’m not really sure what you’re trying to show, as in that screenshot, PivotTo outperforms SetPrimaryPartCFrame. Also, you didn’t even show the code you used to get those results.
I’m literally using your code, but changing a few parts. xd its literally the same exact code you gave me to work with im just changing specific things.