AlignPosition goes off the goal path and doesn't go directly to goal when updating its Responsiveness and MaxVelocity

The AlignPosition object bounces off path when modifying it’s Responsiveness and MaxVelocity while moving. I wrote a script where once the Part that is parented to the AlignPosition hits near Max Speed, I take that speed and set it as the MaxVelocity of the AlignPosition, while also setting it’s Responsiveness to 200. That way it moves at that Max Speed after reaching it. The issue is that the AlignPosition seems to bounce off path when I do this, which is different from when it just goes to the goal position normally without any changes to MaxVelocity and Responsiveness or when done at certain angles (90 or 45 degrees) with the changes to MaxVelocity and Responsiveness.

Expected behavior

I was expecting the AlignPosition to just smoothly go to the goal like it would if I didn’t change the values of the MaxVelocity and Responsiveness once it hit near Max Speed. In fact, it does this as intended if its moving in a straight 90 degree perpendicular line (start position to goal) in worldspace, it even does this at a 45 degree line in worldspace. The only issue seems to be in smaller angles like 15 degree line in worldspace that I noticed this issue with.

A private message is associated with this bug report

2 Likes

Hi Aclysmic,
Can you give us the .rbxl file that the gifs were made from? Thanks

Sure! I have edited the message to include an .rbxl file at the bottom below the script txt file.

Hi @Aclysmic. If you saw my previous reply, don’t worry about it.

Is there a reason why you’re choosing to use PerAxis as your ForceLimitMode on the AlignPosition constraint? My hypothesis is that the behavior you’re seeing is a result of using PerAxis instead of Magnitude. Using the latter will produce a velocity for the moving Part that is always in the most direct direction towards the Goal, which may be what you’re going for.

When ForceLimitMode is set to PerAxis, the value set for MaxVelocity (which is a single number) is used to clamp each of the components of the velocity. This means that if the velocity of the Part is too large in any of its components, despite the velocity vector being the “most correct” velocity to move towards the Goal, the constraint will clamp each component to MaxVelocity, which produces a final velocity vector that need not point in the direction directly towards the Goal, and I believe this is what you’re witnessing.

1 Like

The reason I’m using PerAxis is because I am trying to have movement on only the X and Z axis but not the Y axis, so that it is effected by gravity and other forces on that axis. I believe your hypothesis would be correct considering when MaxVelocity is set to inf the problem no longer occurs as well. This explains a lot considering the fix I found for my specific use case involved setting the MaxVelocity to math.huge and sometimes tweening the Position of the AlignPosition to keep it at the same speed as the original MaxVelocity value, which allowed it reach the position as it should.

This makes complete sense though, I originally thought AlignPosition worked similar to how BodyPosition did but I can see how AlignPosition properties have some fundamental differences.

You should look into using a PlaneConstraint to achieve the functionality you’re looking for (constraining movement of something affected by physics to 2 axis only)

1 Like

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