Hi so I was scripting a game and my third elseif wouldn’t work anways look at my script and please help me out!
Remote.OnServerEvent:Connect(function(Player)
if NewStairs.MainPart.Orientation == Vector3.new(0,0,0) then --- start of rotation
print("1st Rotation")
NewStairs.MainPart.Orientation = Vector3.new(0,90,0)
NewStairs.Part.Orientation = Vector3.new(0,90,0)
NewStairs.Part.Position = NewStairs.MainPart.Position + Vector3.new(-2,-1,0)
elseif NewStairs.MainPart.Orientation == Vector3.new(0,90,0) then --- start of rotation 2
print("2nd Rotation")
NewStairs.MainPart.Orientation = Vector3.new(0,180,0)
NewStairs.Part.Orientation = Vector3.new(0,180,0)
NewStairs.Part.Position = NewStairs.MainPart.Position + Vector3.new(0,0,0)
elseif NewStairs.MainPart.Orientation == Vector3.new(0,180,0) then ---- this part doesnt work for some reason I tried other ways of rotation and everything
print("YAY")
end
end)
end)
For your third else if, you check if NewStairs.MainPart.CFrame.Rotation is equal to CFrame.Angles(0,180,0), however for your other checks you are checking if it is equal to a Vector3.new().
Couldn’t you just pick out the specific axis of rotation for both? Also, I’m sure that .Rotation will have the translation of {0,0,0}, but .Angles() will have the translation of {1,1,1} (Judging by how you can multiply an angle with another CFrame and it doesn’t set it’s translation to {0,0,0})
CFrame.Angles takes arguments in radians, not degrees, a common pitfall. So does CFrame.fromOrientation(), even though Part.Orientation gives you degrees.
That said, you generally don’t want to do exact comparison by value of rotation matrices because they are a bunch of floating point numbers, and the whole comparison has the same problem as using == with floats. It’s also problematic to convert matrices to Euler angles and compare the X, Y and Z values, even with fuzzy comparisons. You’ve probably noticed how sometimes when you enter something like 180 into an Orientation, that it becomes -180, or 0, and sometimes the other two values also change? That’s why. It’s safer to convert to Axis-Angle and fuzzy compare the dot product of the axis vectors and the value of the angles, then the only gotcha you have to deal with is that two nearly-identical rotations can have different signs, because axis, angle == -axis, -angle. So if your dot product of the axes is very close to -1, and one angle is -1 times the other, that’s still an orientation match.
Keep in mind that even with Euler angle values that appear to be integers like 90 or 180, depending on how they got computed, they could actually be things like 89.9999997 or 180.00002, etc. They are stored as floats, so you have to always treat them as floats.
Yes, because on any particular axis, 180 and -180 are the same orientation in Roblox Euler angles, because the values are stored from -180 to +180, so as soon as you rotate past +180, the sign flips and you’re back at the -180 end of the range. It gets more complex when your orientation has more than one non-zero value, since there are multiple combinations of +/-90 and +/-180 that can all actually be the same orientation.
I should also have mentioned that if you can do fuzzy equals type comparisons directly of two CFrames’ RightVector, UpVector, and LookVector, without having to worry about any singularities or opposite signs meaning the same thing. Basically, you’d compare each vector pair something like this:
Where the 1e-3 is your tolerance for close they need to be. Two vectors pointing in the same direction have a dot product of 1, but because of floating point math, they can be slightly different and the dot product can even be ever-so-slightly greater than 1, which in pure maths isn’t possible with two unit vectors, but with floating point representation it is.