To reproduce, play the place file, which moves the model in a circle on a Y plane. After around 1 minute, the output window will start to print changes in the Y position of the non-primary part of the model (colored red). The non-primary part will slide down the Y-axis and at some point gets destroyed.
Welding the parts of the model together prevents the non-primary part from sliding, but after 1 minute rounding errors start to occur in the output, and after another minute or so the part gets destroyed.
Setting the model parts CanCollide to false causes the parts to get destroyed within a few seconds.
The problem does not occur when the parts are anchored.
This is not a bug in the PivotTo() code. The problem is that, because your part is not anchored, physics is acting on it and applying forces (if you take out your calls to PivotTo() you’ll see that the piece falls to the ground), and your script is trying to overwrite the results by placing it in a desired location just prior to rendering. This doesn’t stop physics from acting on the part and eventually, as you have observed, things blow up. Nature always wins.
As you’ve noticed, anchoring the part fixes the problem because then physics is deactivated for that part and you are free to place it as you like with your script.
But if you do leave a part unanchored, then physics will have its effects.
If you print out otherPart.AssemblyLinearVelocity during your callback, you’ll see that the physics system thinks it’s got a downward velocity.
So the physics is moving it downward because of gravity and the script is only overwriting one aspect of what’s going on; therefore the script is putting things in a kind of inconsistent state that runs against the physics reality. So eventually things go a little bonkers.
If you want to effect objects under physics and “play by the rules”, you need to do so with constraints, forces, and/or motors; but not by simply overwriting pivots or cframes.
