[Action Required] Pivot API Release: Update F3X / SBS Plugins

Updates Announcements
,
#1

UPDATE: As of June 3rd, the APIs are now permanently enabled on all platforms.

We’re releasing the Pivot Point APIs on the 24th

We currently plan to enable the scripting API for pivot points and make the Pivot Editor available in Team Create on Monday, May 24th. The Studio tooling to view and edit pivot points will still remain in beta for the time being while we modify it in response to developer feedback, however, from May 24th forwards you will be able to start relying on pivot point APIs such as Part/Model:PivotTo(...) and Part.PivotOffset in live games and plugins.

While you won’t see Model pivot points in Studio unless you have the beta enabled, every model will have a pivot point from May 24th forwards even if the beta is disabled, and building plugins will have to properly update those pivot points for them to not become out of sync with the models that they belong to.

Most building and object creation plugins will keep pivot points correctly updated, however, the old versions of a few popular plugins will not: F3X Building Tools and Studio Build Suite (SBS) are the most popular ones. These plugins have been recently updated to properly handle pivot points, but you will have to Manage Plugins and hit the update button to get those updates.

Please do this before continuing to use these plugins after the 24th:

image

Help! I didn’t see this before using them, is my place broken?

No, don’t worry, nothing will be irreparably broken if you continued to use the old version of the plugins!

If you see pivots in weird places for some Models after enabling the Pivot Editor beta because you continued to edit using an old version of SBS or F3X, you can reset the pivots for those Models back to their default values by selecting them and using the “Reset Pivot” button in the Model tab:

image

However, it will save you some future disruption when the Pivot Editor is fully released if you use the updated version of those plugins, so please update them if you use them in your development workflow.

Reminder: Potentially breaking change to GetBoundingBox()

A quick reminder that as part of releasing the pivot API, the potentially breaking change to Model:GetBoundingBox() explained in the beta announcement post will take effect. We haven’t heard any reports of this breaking code so far from developers with the Pivot Editor beta enabled, but please keep an eye out for bad behavior in any game where you use Model:GetBoundingBox().

Technical details for the curious :slight_smile:

What’s going on here, how does the pivot get “out of sync”?

For Models which do not have a PrimaryPart set, the pivot is a position in world space, not directly tied to any of the parts within the model. This is very convenient in allowing you to use pivots on anchored scenery without having to worry about setting a PrimaryPart, but does means that if you move all of the parts underneath the one of those models, the pivot will not automatically move along with them.

This is not an issue for most building and object creation plugins since they used dedicated model movement APIs such as Model:MoveTo and Model:SetPrimaryPartCFrame that have been updated to also move the pivot of the model in addition to moving the parts underneath it.

However, some plugins such as F3X and SBS have their own dedicated movement code that individually moves the parts underneath the model, and this code had to be updated to also set the Model.WorldPivot property of models when moving them.

Going forward, you should use the new PivotTo API when you want to move models. In addition to updating the pivot like the other model movement APIs, the PivotTo API has several other benefits (or rather, it will have these benefits after the 24th):

  • It works based off of the pivot, so you can freely set the reference point that makes the most sense for you to move the model relative to, and aren’t required to set a PrimaryPart.

  • It works using the same infrastructure as BulkMoveTo, meaning noticeably improved performance compared to SetPrimaryPartCFrame.

  • It does not have floating point drift issues. PivotTo caches part offsets internally, so even if you move a model every single frame using PivotTo, the parts will always stay perfectly aligned (noticeable gaps will start to form between the parts in the model if you try to do this using SetPrimaryPartCFrame).

Thank you and remember to make any necessary updates before May 24th.

131 Likes
Character goes insane after changing the position of the HumanoidRootPart
PivotTo Drift Issues
Pivot Editor: Full Release
#2

This topic was automatically opened after 13 minutes.

#3

I made my own function some odd years ago that did the same thing as SetPrimaryPartCFrame but without the floating point drift issues because I couldn’t stand it. Now with this update I don’t have to use it anymore, cool!

27 Likes
#4

I almost feel bad taking the rite of passage of writing said error-free model movement function away from new developers, but it’s for the better!

36 Likes
#5

Thankfully it’s being enabled to Team Create, our team will finally get to use Pivots!

3 Likes
#6

AKA: The Extended Customer Support plan where @tnavarts fixes my old code for me.
Thanks for the patch!

21 Likes
#7

I hope I can make a better lightning system with this, since atm trying to position each bolt is a pain.

3 Likes
#8

Alright, I am genuinely suprised roblox notified users of F3X and SBS in specific in the title. This update seems extremely useful for block-specific pivots. I can’t wait to see more demos of this.

2 Likes
#9

What do you mean by “live game”[ as in updated instantly] and also
What is the FUNCTION Model:PivotTo()?
Does it just give off a vector3 position of the position that it going to be rotated? One more thing is Pivot Points just like this. I’m getting confused.

3 Likes
#10

Yes, pivot points work pretty much like that, only we have a dedicated Edit Pivot tool rather than mode you enter to change an object’s pivot. Both Parts and Models have pivot points.

Calling part/model:PivotTo(targetCFrame) will move the part or model such that its pivot is located at targetCFrame after the move, it’s like SetPrimaryPartCFrame but much more flexible in that it doesn’t require a PrimaryPart and you can use it on individual parts too.

See the pivot beta announcement post linked in this one for more details.

6 Likes
#11

This is a nice update, but I need to say that Model:MoveTo() is kinda buggy, since if I try that function on a character, a teleporter for example, it spawns the player upper, way upper, because the upper part that may be above. I don’t understand the Pivots yet, too many CFrames, but I will be sure I get this.

2 Likes
#12

That’s the intended behavior for Model:MoveTo(): It will move the model up until it doesn’t collide with anything after moving it to the specified location. Usually you don’t want that behavior (because it gets you into bad scenarios like spawning objects on the roof of the building you tried to put them in), but it’s occasionally useful.

The CFrame part of PivotTo() is not that difficult. If you just want to use it with positions you can always call model:PivotTo(CFrame.new(position)) and not worry about the CFrame part.

8 Likes
#13

:MoveTo() has always worked like that, much like .Position it just positions an object above parts and not inside.
Suggest you try using :SetPrimaryPartCFrame or CFrame, since both can also just use a Vector3 like :MoveTo().
:slightly_smiling_face:

1 Like
#14

That was changed a while ago. Using Position currently doesn’t force objects above others.

1 Like
#15

You monster! Do you have any idea what I’ve been doing the last two hours? If you wish to know, it’s

Then I look at this and see that it was all for nought! In other words, THANK YOU SO MUCH! :grin:

1 Like
#16

Why are you suggesting someone use what is going to become a deprecated function in 6 days? PVInstance:PivotTo is the intended replacement and also has better functionality than PVInstance:SetPrimaryPartCFrame. You should start using PVInstance:PivotTo instead.

1 Like
#17

When this update is released will you also be releasing the documentation for PVInstance | Roblox Creator Documentation and PVInstance | Roblox Creator Documentation? While most who already understand Model | Roblox Creator Documentation will be able to understand how to use this we still won’t know all the constructors that can be used. Like @Yume_Akizuki sort-of said, :SetPrimaryPartCFrame has more constructors than we currently know that PVInstance:PivotTo has.

1 Like
#18

SetPrimaryPartCFrame won’t be deprecated until the Pivot Editor has been fully released, exactly because the documentation for PivotTo and pivot in general isn’t there yet, but will be before the beta ends.

3 Likes
#19

Will SetPrimaryPartCFrame still have compatibility after the Pivot API releases?

3 Likes
#20

Yes, deprecated doesn’t mean removed, SetPrimaryPartCFrame will still continue to work in existing code. As noted in the post, SetPrimaryPartCFrame will even update the pivot correctly too, so you won’t have to change your existing code to get the right behavior.

Deprecated just means that we will no longer recommend using it, and that you may need to use PivotTo in the future if you want to take advantage of other new features added after it.

6 Likes