What do you want to achieve?
If the player types 155, 0, 0, into a textbox, a weld’s c1 will rotate to 155, 0, 0
What problem is occurring?
(With correct math and everything), or even just editing it directly in the explorer, the orientation seems to “approximate” and returns 25, 180, 180. To the point that i’m starting to think it’s an inbuilt roblox feature that can’t be turned off.
What solutions have you tried so far?
Looked for solutions everywhere. tried a bunch of different math, editing it directly, without welds, just on parts, scripts, nothing seems to be working.
I can provide more details if needed
Edited: It’s been about 2 months, problem is that I was using CFrames that approximate. Yep. Always read the documentation.
What’s your issue exactly? That the weld changes the coordinates property but the positioning is almost the same, or that the 3d world representation completely messes up? If the 3d representation seems okay and you’re just annoyed by the Roblox engine automatically changing the input you can store the input somewhere else(in a datastore, in the script as text, in a vector value) and edit that instead of the actual weld every time you want to apply changes(then if you use a vector value you can attach the changed event of that value to changing the actual weld to the new value). However, if your issue is related to the weld actually messing up your game mechanics and such then it’s most likely an issue with your code itself, and for that case, we need the code snippet related to the issue to investigate it further.
It could be something to do with “matrices” (i.e. CFrames), where sometimes, an orientation cannot be perfectly represented due to Size, Position and Rotation being stored in the same matrix, i.e.:
“Rotation and Scaling” share the same 9 numbers, so maybe the issue is that having the rotation be 155, 0, 0 would result in the scale (size) being effected, which you obviously do not want, and so it needs to correct the error by doing some more matrix shenanigans and changing the other numbers as well.
The real question is, does it achieve the desired rotation? From what I can see in my own testing, it does in fact rotate the Baseplate’s Spawnlocation 155 degrees on the X axis:
TL:DR: Everything is fine, Roblox is not to blame, math and trigonometry is, but neither are wrong in changing the orientation in a way that is weird to not make things look like they are ascending into the 4th dimension.
That will not change anything as rendering will be based on the CFrame, not Position and Orientation, which are simply there to make programming easier for us developers instead of having to fiddle with CFrames. See my reply above this one.
I think rather than editing the orientation itself you can do:
--
local rotation: Vector3 = getInput()
local rotationCFrame = CFrame.Angles(rotation.X, rotation.Y, rotation.Z)
Weld.CFrame = CFrame.new(Weld.Position) * rotationCFrame
Note that this may need to be modified to account for any relative positioning of the weld. E.g. if it is part of a character that moves around you would need to work in the cframe of the humanoid root part (rather than world cframe).
Ah, I get it now. If it were to not approximate, it would look like this:
What OP could possibly do is just display the value to the user, but internally the orientation is approximated.
It’s possible that the issue is with the order of rotations. When using the CFrame object in Roblox, rotations are applied in a certain order which can affect the resulting orientation.
Here’s an example of how you can use CFrame to set the orientation of a weld’s C1 to a specific rotation:
local Weld = game.Workspace.Part.Weld
-- Input values
local xRotation = 155
local yRotation = 0
local zRotation = 0
-- Create a CFrame with the input rotations
local newCFrame = CFrame.fromEulerAnglesXYZ(math.rad(xRotation), math.rad(yRotation), math.rad(zRotation))
-- Set the C1 of the weld to the new CFrame
Weld.C1 = newCFrame
This should set the orientation of the weld’s C1 to the specified rotation without any approximation. If you’re still experiencing issues, you can try applying the rotations in a different order to see if that resolves the problem.
In my game, I have a script to set the orentation and display it, works perfectly, as if you were editing it within the workspace itself, but it does that, and i’m not sure if the players of my game would understand why it does that.
Nothing wrong with the script itself, just don’t know if there’s any script that tells the part "Please use this value exactly and do not change it afterwards.
Yeah there won’t be a way to tell it that explicitly as for any cframe value there is more than one set of orientations that would describe it.
On this page - Euler angles - Wikipedia
it describes some standard constraints that are put on the angles. For the β angle (around the x axis) it is commonly limited to [-π/2 , π/2] radians which is [-90, 90] degrees. This may be why it is being changed to 25 degrees. (180 - 155 = 25)
Nothing you can do about it, as Roblox uses CFrames to rotate its parts.
What is happening internally:
You set the orientation,
Roblox calculates CFrame rotation matrix, based on the provided Orientation,
Roblox recalculates the approximate Orientation using the new CFrame.
Orientation is overwritten.
To solve this, you can probably cheat a little and display that the orientation is what the player have chosen, rather what the engine spat out. They are equivalent to each other. Just make sure that the user cannot put more than 180 or less than -180 per axis.
