Why rotation becoming negative?

Help and Feedback Scripting Support
#1 
print(rotation, xPivot, zPivot)
	-- Set position
block:SetPrimaryPartCFrame(
	CFrame.new(position) * -- Just the general position
	CFrame.Angles(math.rad(xPivot), 0, math.rad(zPivot)) * -- This is for FaceRotations (X & Z Pivots)
	CFrame.Angles(0, math.rad(rotation), 0) -- This is for TextureRotations
)

The print prints:
180 90 0

As you can see, both numbers are POSITIVE, yet the orientation is becoming negative. Why is this?

image
image1920×1080 411 KB

If I manually set the orientation to be right (90, 180, 0) then the block is the right orientation

image
image1920×1080 410 KB

But what I dont get is how is it becoming negative? No negatives are being printed, so by that logic, a negative orientation should never exist in this instance

#2

I’ve had this problem before too. I’m pretty sure this is a display issue; no difference between the two. I’ve noticed Studio has had some other numerical displaying issues too. I don’t remember what they were, but I remember some properties suffered from floating point errors among other things. It’s possible those issues are still around, similar to this.

#3

There’s a clear difference between -90,-180,0 and 90,180,0 though

#4

Ah, my bad - I read it wrong. From the code you posted, I see you’re setting the actual CFrame of the object by (mostly) converting degrees to radians. Maybe something is going wrong in that process?

Try printing CFrame:ToOrientation() for the CFrame you create and see how it compares to your first print.

#5 
BEFORE 180 90 0
AFTER -1.5707963705063 -3.1415927410126 0

print("BEFORE", rotation, xPivot, zPivot)
print("AFTER", NewCFrame:ToOrientation())
#6

Converting those numbers back to degrees you get about this (and reorder them because CFrame:ToOrientation() uses YXZ):

BEFORE 180 90 0
AFTER -180 -90 0

I’m not an expert with CFrames, so maybe change your code to negate those components? If you have any other possible orientations, try testing those to see how they turn out. I somewhat doubt that this is an all-inclusive answer. It could be the case that in constructing the CFrame is where something is going wrong that I don’t realize.

block:SetPrimaryPartCFrame(
	CFrame.new(position) * -- Just the general position
	CFrame.Angles(math.rad(-xPivot), 0, math.rad(-zPivot)) * -- This is for FaceRotations (X & Z Pivots)
	CFrame.Angles(0, math.rad(-rotation), 0) -- This is for TextureRotations
)
#7

That fixed that CFrame problem, but it messes with a bunch of other results :confused:

#8

I’m Still Learning how CFrames Work So im only here for information :+1:

#9

I wondered. When you were testing other results did you notice any pattern that you can trace back to the way the CFrame is constructed? The only other thing I can think of is it might be an issue with how the numbers were input.

#10

Orientations are within the bounds of (-180, 180), not (0, 360). It’s the same thing at the end of the day. If you want to convert it back to the (0, 360) range, just do a modulus operation on the number.

For instance:

local yRotation = part.Orientation.Y % 360

But in terms of what you’re seeing, that’s just a side-effect of Euler angles. Euler angles have a bit of ambiguity since it’s limited to 3 dimensions.

7 Likes