Part Orientation randomly resets on setting Position

Hey!

Currently experiencing a bug where Orientation for parts is flipping back to 0, 0, 0 randomly when setting the Position of parts.
This bug occurs both in studio and in game when published, the parts are completely client sided.

local function calculateRegimentFormation()
    local mag = (initialPosition - endPosition).Magnitude
    local newColumnWidth = math.max(mag//columnSize, minColumn)

    local initialCFrame = CFrame.new(initialPosition, endPosition) * CFrame.Angles(math.rad(0), math.rad(90), math.rad(0))

    for i, part in regimentParts do
        local row = (i - 1)//newColumnWidth 
        local column = ((i - 1) % newColumnWidth) + 1

        part.Position = initialCFrame:VectorToWorldSpace((Vector3.new(column * columnSize, 0, row * rowSize))) + initialPosition
    end
end

I’ve attached the code that sets the position as well a place file for reproduction.

Expected behavior

Expectation is for Orientation to not change as the code is only setting the Position.
Orientation is only set when parts initially created.

A private message is associated with this bug report

3 Likes

Neat issue, it took me a second to spot what’s wrong: The orientation is getting reset as part of NaN protection.

When you try to do something that sets a part’s position to NaN it instead gets placed at a known CFrame below the kill-plane where the kill plane will remove it rather than it potentially accumulating as a leaked invisible part. That known CFrame has a zero orientation, that’s what’s resetting the orientation.

Then your code subsequently moves it back to a normal position. But the orientation has already been reset and doesn’t recover.

The fix is that you need to check for the initial position and end position potentially being the same before doing CFrame.new(initialPosition, endPosition). Also you probably want to use CFrame.lookAt instead because it’s more readable and has slightly better numerical stability than the old .new(a, b) constructor.

2 Likes

I don’t see his cursor moving off the baseplate though.

When it flips is it possibly due to gimbal lock? The white cylinders appear to be directly in line with the baseplate X or Z axis when they flip sideways.

Cursor off baseplate is something entirely different.

Here the problem is that initial position == final position, which can happen whether you’re on the baseplate or not.

1 Like

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