I am using AlignPosition on a Part to move it from one Position to another Position. I currently have it at OneAttachment Mode and MaxVelocity is 30. Is there a way to detect when AlignPosition has achieved its destination Position, similar to Humanoid.MoveToFinished? I looked at AlignPosition’s Events on the documentation and there currently isn’t an Event or Method to detect when it has arrived at its destination.
What solutions have you tried so far?
I thought about Part.Changed to check if the part has reached the position I want it at, but it would be firing an event to check the position every frame and that will lag the server. My current solution is checking every second if the part has reached its destination. I don’t like this solution too much because it is slightly off timing-wise and is constantly running.
AlignPosition uses forces to change the position of the object they’re working on. You should be able to set up a while loop to yield until the Part’s velocity reaches 0, or a value close to 0.
I am also facing this problem, right now, in fact. I haven’t found any practical solutions either. Definitely missing some more information about mover constraints.
It would be useful to have a time value to help us determine the approximate traveling period, or, even better, an event like you mentioned. Or at least access to the formula. I was trying to calculate the time based on gravity, MaxForce, MaxVelocity and Responsiveness, but the latter is the variable that’s stirring the pot.
From the announcement post
Responsiveness (float) - Used to control how quickly the constraint will reach its goal. Higher values will cause the attachment to align quicker. Value can be between 5 and 200.
The mechanism for responsiveness is a little complicated, but put simply the higher the responsiveness, the quicker the constraint will try to reach its goal.
Which is why it’s quite infeasible to accurately predict the timing to start checking moments before the goal should be reached.
To date the most reliable way seem to involve rapid checks.
This concern is well-placed, though I don’t think reading the positional properties and comparing them could actually significantly impact performance.
The above condition in an if-statement took me no more than 0.01 milliseconds on average! Indexing and subtraction are very lightweight operations, and magnitude is simply sqrt(x^2 + y^2 + z^2).
Here’s where I noticed something strange. Neither .Changed nor :GetPropertyChangedSignal() fired while Position or CFrame were being modified by a mover constraint.
Which leaves us with RunService or task.wait(). In my tests with a relatively large amount of parts, I didn’t sense any noticable lag. A reasonable precision like task.wait(0.1) in a loop seems like a fair middle ground for now.
(Btw, don’t forget about floating point error, exact position might never be reached at all.)