Upcoming Potential Property Name Conflict: "Pivot"

[tnavarts]

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 Pivot to 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 FindFirstChild instead of . 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.

[nooneisback]

Never really understood why people avoid using :FindFirstChild() for any child indexing. It’s way more secure than doing it directly.

[TheCarbyneUniverse (Carbyne)]

This is a great reminder especially since it stresses the need to use FindFirstChild more so than the dot operator because it doesn’t error or have any chance of being conflicted with properties.

However, can’t there be a better name other than “Pivot” such as “AnchorPoint” (to be consistent with UIs since the functionality is basically the same) or “PivotPoint?” TBH, just having pivot makes it sound like an Instance property as opposed to a CFrame.

Anyways, I very much appreciate this heads-up!

[axcracy (arch)]

@tnavarts

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

This sounds great! Can’t count the amount of times that I have needed a feature like this. Looking foward to using it

Some doors in my games use the name Pivot, as this is what the doors rotate around. The warning is always appreciated. Not sure why I didn’t think to use :FindFirstChild(), guess just because I never expected anything like this to be added.

Thanks for keeping us updated!

[LucasMZ_RBX (lucasmz)]

The wikia says it’s 20% slower, also it makes the auto complete feature not show stuff under it; that’s probably why

[Dvyz (dizzy)]

I can already tell that this is going to be a very interesting update and will make future projects a lot easier

[metatablecatmaid (metatablecat)]

Doesn’t this use a CFrameValue as of current though? Why not just stick with that, or, add CFrame support to attributes since they can be serialised.

Edit: i managed to break it already, nice

[tnavarts]

@TheCarbyneUniverse

However, can’t there be a better name other than “Pivot” such as “AnchorPoint” (to be consistent with UIs since the functionality is basically the same)

We totally could, it’s a tradeoff: We want this to be a fairly foundational feature (you’ll see why when we give you the full details), so we think the risk is worth it to have a short convenient name.

@FilteredStudio

Doesn’t this use a CFrameValue as of current though?

The implementation that exists on production behind flags was for the purpose of prototyping the behavior while we worked out exactly how the API would look. Note: How the tooling works has also significantly changed since that prototype, it’s from many months ago at this point.

[DataBrain (Amber)]

RIP every door in every one if my games.

I wish you could find a different property name. I don’t want to have to search literally every game I’ve made in the past for conflicts, let alone fix them, cause for me “Pivot” is very, very, very common in any code related to doors.

[BULK_BROGAN]

Performance and autocompiler aside, it also just bloats code and make it look ugly. This case is very rare

[DataBrain (Amber)]

I should also mention… a lot of the mayhem to come is out of my hands.

Some of the old projects I’ve worked on I don’t have the time to maintain or access to maintain.

I really hope you reconsider before letting this go through. Almost every rotating door I’ve made has had a marker called “Pivot” which I’ve dot-accessed because I subscribe to the school of thought that unnecessary use of WaitForChild and FindFirstChild is an anti-pattern.

[TheAmazeman]

I am lucky to have been more descriptive than just pivot then I suppose

[tnavarts]

FWIW, doors is the main case that I thought of this potentially breaking. I downloaded the top few dozen automatic doors out of free models when I was working on this and none of them used something called “Pivot”. It looks like your naming here is just unfortunate.

If there are enough people that do bring up being effected we can still reconsider or provide some form of automated tool which attempts to update a whole place. Would a script that find-replaces .Pivot into :FindFirstChild("Pivot") in a place work for some of your places or do you use “.Pivot” in Lua data structures as well?

[R0bl0x10501050]

Maybe change it to “PivotValue”? That seems unique and would clear up the Pivot issue.

[DataBrain (Amber)]

Like I said… I have to check every single place file I’ve every created, and even then it’s still tricky because something might slip through the cracks.

I’m just not sure if I have the time to maintain every project I’ve ever made in the past, nor do I necessarily have access to every project I’ve contributed to in the past at this point.

I personally like to have old games of mine playable. So maybe I’ll have to pick and choose which ones I want to maintain playable to the public, but it sure is an ordeal for me it seems.

[R0bl0x10501050]

It wouldn’t be too hard… just press CTRL + SHIFT + F and search for “Pivot”.

[SillyMeTimbers (Silly)]

Is that in the mod manager? If so whats the flags name?

[Hexcede]

I always use :WaitForChild() unless when I explicitly don’t care if the object exists. In my opinion, you should always use WaitForChild regardless of performance, particularly because you only tend to call it once and store your reference somewhere.

If you need to access a child in a frequently running loop and you’re really worried about performance, memoize it, this will give you some really performant speeds compared to either case:

local itemMemory = {}

-- Inside the loop
local item = itemMemory[script]
if not item then
    item = script:WaitForChild("Item")
    itemMemory[script] = item
end

I personally, in my own code, frown upon frequent use of :FindFirstChild() due to performance and debuggability, its difficult to debug something when the error can’t tell you what it is. This is one reason why people like ., since it will tell you what the name of the object is.

That is exactly why I prefer :WaitForChild() as well, you will actually potentially get better speeds than indexing an instance directly using the above since you’re removing the constant instance <=> lua layer, and you still get debuggability since children that can’t be found show a warning if you give no timeout.

[nooneisback]

That slowdown is irrelevant in most cases as you should cache the instance instead of always getting it from its parent. The auto-complete not working is definitely annoying, but it also often affects direct indexing of children. I’d rather it never worked than have an inconsistent behavior as I don’t have to wonder if it will show up in a few seconds or not.