"CFrame" in "Properties" window is not showing the correct CFrame data

This CFrame, for example:

When collapsed, it shows this:

{-260, 3.652, -20}, {0, 90, 0}

The correct should be (when I print the object CFrame):

-260, 3.65199995, -20, 0, 0, 1, 0, 1, 0, -1, 0, 0


The display in properties window is correct. The first braces display Position and the second ones display orientation in degrees.

Printing CFrame results in positional arguments along with right vector, up vector, and look vector, which describe orientation.

In your case they translate to 0,90,0 relative to the world space.

In a similar way all position and size arguments in GUI objects are displayed. Printing the orientational vectors may raise much more confusion that representation in degrees.


Please, check CFrame | Documentation - Roblox Creator Hub.

{-260, 3.652, -20}, {0, 90, 0} is NOT a CFrame.

I’m saying this property should show a pure CFrame.
In such a way that I can copy and paste its value into a CFrame.new().
And currently, I can’t do that with this property.

I know it’s not a CFrame, it’s position and orientation from the dropdown inside braces compacted into a single window. It’s been like this for years (my bad, time flies!) and it’s a standard that doesn’t apply only to CFrames. All GUI objects behave like this.

It’s not a bug but a design decision, so you can edit the properties without opening the dropdown. Maybe you could open a feature request for this, although the display is meant to be readable instead of containing individual components of a CFrame. What could perhaps be done if we went in that direction is have the display remain unchanged, but have copying take the full CFrame.


Since a field named CFrame is displaying non-CFrame content, this IS a bug.
If Roblox decides it won’t show a true CFrame on this property, then let them change it to another name.
Please do not flood this post with polemics.

1 Like

I’m not starting any polemics nor is it my intention to do so. Discussion is why bug report replies are open.

What I’m saying is, this is not a bug but rather Roblox’s conscious decision. Because adding an ability to view CFrames as matrices makes sense, this may be a fruitful feature request. The idea was considered before, but it appears to be sleeping at low priority right now.

Here’s the quality of life update that introduced CFrame in Properties: Improved CFrame support in Studio.


Orientation and position condensed applies to all CFrame properties, including CFrame, WorldPivot, Origin, PivotOffset, CFrame value base, tool grip, C0 and C1 properties etc. Similar in GUI objects.

Scrolling down the replies, you’ll find some ideas to have a designated setting in studio to switch the way CFrame is represented. The main concern of the devs was bloat full CFrame display would introduce, so they decided to go for what we have instead. Because not all developers are aware how CFrames work, they went ahead and combined those vectors and exposed them as orientation. After all, a majority of people prefer using CFrame.lookAt(), CFrame.new() along with CFrame.Angles() etc. to matrices, because three unit vectors are not as readable.


Hi. As others mentioned this is a conscious design decision. There is limited space, so showing all 12 cframe numbers in a single line is unfeasible. That’s also why we truncate to 3 digits precision, so even if we showed the 12 numbers, copy-pasting would result in a slightly different cframe. If you have another cframe property, copy-pasting the {x,y,z}{a,b,c} format works. If you need it in Lua, you could use one of the constructors taking Euler angles on the documentation page you linked.

I agree that a way to also copy the underlying numbers would be helpful. If that is something you’d like, I would suggest opening a feature request. Thanks


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.