Is there any way to disable this? I’m often finding that my pivots are way off in Narnia for no reason whatsoever, and it makes my building workflow a lot slower with default tools. I find myself reverting to plugins a lot more.
I don’t want to have to set the PrimaryPart on every single model I create.
Edit: I should mention… These is happening on models that existed before pivots existed! This means a number of models in my existing build is a complete mess to work with using roblox’s default tools.
I’m guessing it’s because these models were created and parts under it were deleted later on, leaving vestigial pivot points? Whatever the case may be, it’s super hard to work with.
Yes, the above two suggestions work. But that’s not the point. The point is that I have hundreds of pivots from models copied/pasted that are messed up in my game, which weren’t messed up prior to this update.
Going through each of them is just annoying to deal with.
The pivot API got turned on a few months ago, so if you were using a plugin which moves stuff around using custom code (rather than model movement functions like PivotTo or SetPrimaryPartCFrame) but doesn’t update pivots the pivots could have gotten screwed up in that interval without you noticing because you didn’t have the pivot visuals turned on yet.
I made sure that the top SBS and F3X distributions were updated to avoid that issue, but I didn’t go through other smaller plugins. Can you reset the bad pivots for now and try to figure out specifically when they’re being messed up?
Also, imported meshes have their pivot set to be equal to the origin of the space you imported from, so you should make sure that the mesh is positioned relative to the origin how you actually want it positioned now in your mesh editor where that wasn’t relevant before.
That’s because SetPrimaryPartCFrame checks if the CFrames are very close to equal and does nothing in that case. The way that I design my APIs I prefer not to second-guess the developer if possible. There is an expectation that setting a property redundantly doesn’t do extra work if possible, but I don’t think there’s a similar expectation for functions.
TL;DR: If you want to PivotTo to a location 0.00001 studs away from where you currently are I didn’t want to make the API second-guess you.
Just a random bit of fun: Here’s the full announcement thread from when SetPrimaryPartCFrame was introduced back in 2014 (I also had a hand in designing that API way back in the day!). It actually had one of the (at the time) longest discussion threads of any feature announcement on the DevForum:
I just enabled a change bringing BasePart:PivotTo in line with Model:PivotTo: Now when you call BasePart:PivotTo, both the part and any descendants parts will be moved just like for a Model, where previously only the part you called PivotTo on would be moved. This was the initially intended behavior but things were implemented wrong.
This should not affect any live games because we contacted the potentially affected place owners ahead of time.
I was told to listen to CFrame since position changes will not be triggered now - CFrame does not work as well. I tried to listen to CFrame changes on primary part under model - NOT WORKING (just a simple print for every signal change).
There is now no way to listen to CFrame/position changes on models. Needs a solution, especially for a live game that depends on this.
You’re likely listening on the on a part that isn’t the root part of the assembly (it may have been the root part before but changed as you changed the assembly in question) – Position / CFrame / etc events have never been fired for non-root parts, they only get fired for the root part of the assembly.
The root part of the assembly is usually the largest part within a set of parts that are connected together with Welds / other rigid joints. You can see which part is the root part by looking at the “AssemblyRootPart” property of the part you’re interested in. To change which is the root part you can set the RootPriority property.
Another small update. With today’s release, pivot indicators are now hidden while box selecting, so if that was causing you issues, please try opting back in!
I don’t think my builder uses any third-party plugins; regardless of this, these models are all vestigial and were created before pivots were even in roblox. So I’m pretty sure there are bugs with the default tools/backwards compatibility in general.
I opted to write a script (which I run using a macros plugin) to fix random wayward pivots:
--!strict
local SIZE_SCALE_DISTANT_THRESHOLD = 1.5 -- scalar relative to total size (i.e. diameters) from the
-- centroid at which a pivot is considered distant
local changed = 0
local descs = workspace:GetDescendants()
for i = 1, #descs do
if descs[i]:IsA('Model') then
local base = descs[i] :: Model
local savePivot = base.WorldPivot
local cf: CFrame, size: Vector3 = base:GetBoundingBox()
local relCF = cf:ToObjectSpace(savePivot)
if math.abs(relCF.X) > size.X * SIZE_SCALE_DISTANT_THRESHOLD
or math.abs(relCF.Y) > size.Y * SIZE_SCALE_DISTANT_THRESHOLD
or math.abs(relCF.Z) > size.Z * SIZE_SCALE_DISTANT_THRESHOLD then
base.WorldPivot = cf
changed = changed + 1
end
elseif descs[i]:IsA('BasePart') then
local base = descs[i] :: BasePart
local relCF = base.PivotOffset
local size = base.Size
if math.abs(relCF.X) > size.X * SIZE_SCALE_DISTANT_THRESHOLD
or math.abs(relCF.Y) > size.Y * SIZE_SCALE_DISTANT_THRESHOLD
or math.abs(relCF.Z) > size.Z * SIZE_SCALE_DISTANT_THRESHOLD then
base.PivotOffset = CFrame.new()
changed = changed + 1
end
end
end
print('Adjusted the pivot of ' .. changed .. ' instances')
I wish I could just disable pivots in general, or on demand. Pivots have literally done nothing but slow down my workflow thus far.
I like this update, except for the new pivots on imported meshes. It bothers me not being able to center the pivot on the mesh. I know this is fixable by just going back into blender and fixing it, but with all the effort of reuploading the meshes, No thank you.
If you don’t care about the pivot at all, you don’t have to reimport, you can simply click the “Reset” button in the Pivot section of the ribbon bar.
FWIW figuring out what to do with this is the holdup on rolling out the feature further. We may remove pivot from import by default (putting it behind an option) until we have the new importing workflow available.
Hey, I have a bug,
This has been happening since the start but I always forget to report it. The pivot point and the selection box dont realign themselves after moving, this happens only on unanchored parts on which physics acts. To show better what I mean I have a video for you but roblox has been extremely bugged from yesterday including the devforum, whenever I try to upload a video it says an error occured and you cant upload the file
You have to set the PrimaryPart of a Model if you want that Model’s pivot to “follow” it during simulation under the new system, the PrimaryPart will inform which part in the Model the pivot follows.
Also, setting the pivot when importing a mesh has been moved behind the new studio setting “Set Pivot of Imported Parts”. We want this to be a core part of the workflow long term with our upcoming unified asset import process, however, for now it makes more sense to keep this optional as there are some outstanding complexities with what mesh pivots make sense.
Opt-out is still available, however, will be going away reasonably soon unless further issues are brought up. Some mesh importing issues were the only outstanding blocker that we were aware of, so if something else is causing you issues please speak up now!
