Orientation should never be -180

[rogeriodec_games]

I compare the orientation of two parts and I found that in some cases, the orientation didn’t match because one part showed 180 and another part showed -180, on the Y axis.
Therefore, I was forced to make an exception in my script to handle this case.
However, there shouldn’t be a -180 orientation, as it is the same thing as 180.

[BackspaceRGB]

Im pretty sure this is just a rounding issue? Same thing with -0, its not a real number, but it exists in studio because the actual number is like -0.0001 and it gets rounded

[rogeriodec_games]

No. Already tested with math.round

[Eestlane771]

Your mistake was using Part.Orientation. Do not ever script Orientation if you can avoid it.

In this case, you might want to see whether two of the parts’ axes are facing similar directions.
(You only need to check the third if you have oddities like inverted parts in your game.)

local function isOrientationSame(a, b)
	return  a.CFrame.XVector:Dot(b.CFrame.XVector) > 0.999
		and a.CFrame.YVector:Dot(b.CFrame.YVector) > 0.999
end

print(isOrientationSame(workspace.Part1, workspace.Part2))

edit: oops the dot was unnecessary, the vectors are all going to be the same length anyway

local function isOrientationSame(a, b)
	return  a.CFrame.XVector:FuzzyEq(b.CFrame.XVector)
		and a.CFrame.YVector:FuzzyEq(b.CFrame.YVector)
end

[tnavarts]

@rogeriodec_games

No. Already tested with math.round

Yes, unfortunately, because the Orientation property is rounded to the nearest hundredth because it is intended for UI convenience not numerically precise computations.

If you run this code you can see the true orientation, which will be something like -179.99345 on some axis, which gets rounded to -180.

local a,b,c = game.Selection:Get()[1].CFrame:toEulerAnglesYXZ() print(math.deg(a), math.deg(b), math.deg(c))

What are you actually trying to do? Most things are better done in code using a computation on the CFrame, not by using the orientation property.

TL;DR: This isn’t a bug. But I guess it’s not the most intuitive behavior. I’ll actually look into whether it makes sense to round these cases to +180 instead.

[rogeriodec_games]

@tnavarts

local a,b,c = game.Selection:Get()[1].CFrame:toEulerAnglesYXZ() print(math.deg(a), math.deg(b), math.deg(c))

In fact, using your CFrame example, the Y axis appears as -179.999991348578.
However, print(MyPart.Orientation.Y) it still shows -180.
That is, the same object shows an exact value in CFrame and a rounded value in Orientation.
Isn’t this a bug?

[rogeriodec_games]

Here a practical example of I told in OP:

p1 = workspace:WaitForChild('Part1')
p2 = workspace:WaitForChild('Part2')
p1.Orientation = Vector3.new(0, 180, 0)
p2.Orientation = Vector3.new(0, -180, 0)
print(p1.Orientation.Y, p2.Orientation.Y)
print(p1.Orientation == p2.Orientation)

will print:

-180 180
false

Again, the angle 180 is exactly the same of -180, however it’s being considered different.

[tnavarts]

@rogeriodec_games

Again, the angle 180 is exactly the same of -180, however it’s being considered different.

That’s not unexpected, Lua doesn’t have a concept of angles, they’re just numbers, and the number 180 is different from the number -180. The type system isn’t powerful enough to know your intent. You would need a “compareAngles” function or something like that which does know your intent to treat them as angles.