Do I need to read this post?
If you have any Instances named “Pivot” in any of your places, please read on. Otherwise you can disregard this post.
What is changing?
Coming soon, we’re going to be introducing the concept of editable “pivot points” to studio, letting you set the point around which parts and models can be manipulated using the Move and Rotate tools. We’re not quite ready to share the details of how that will work yet, but we do need to share a detail that may impact developers:
- We plan to add a CFrame property called
Pivotto both Models and Parts.
Why does this matter?
This means that if you have any Instances named
Pivot underneath Models / Parts in your game, and access them via the
. operator, your code will likely break. E.g.:
local pivotInstance = myModel.Pivot pivotInstance:Clone().Parent = ... --> Oops, pivotInstance is now a CFrame!
This kind of breakage is a risk that always exists when we add new properties, but it is normally a very low risk that does not break any games in practice. Since in this case we are adding the property to Models, which are used as a general container object, the risk of a name collision is significantly higher than usual.
“Pivot” is not a very common term, so the change may not end up affecting any games, but given the elevated risk we’re choosing to give advance warning just in case.
What do I do if I have Instances named Pivot?
If you have no Lua code which references the Instances named Pivot using
., no changes are needed. If you do have Lua code referencing them, then you have 2 options:
- You can edit the Lua code to use
.when accessing the Instances.
- You can rename the Instances to something else and edit the Lua code accordingly.
Please make these changes by March 10th or let us know as soon as possible that the change will be an issue for you, as we plan to ship the release with the Pivot property on that date. E.g.:
local myObject = myModel.Pivot --> Existing code which will break ✗ local myObject = myModel:FindFirstChild("Pivot") --> Use FindFirstChild instead ✓ local myObject = myModel.PivotObject --> Or rename it to something else ✓
Why isn’t there a better process for this kind of change?
This case is very unique. We rarely add properties to Instances commonly used as containers, and even when we do, they are normally names with no realistic chance of collision.
This kind of collision is not something you should worry about when naming your Instances.