Please consider adding this! It’s really frustrating working with the new constraint system because of the limitations such as this as opposed to BodyMovers. If BodyMovers are being put under “Legacy” status, we should be able to continue to have access to the benefits of the BodyMovers.
21 Likes
I’ve hit a snag with using AlignPosition since I can’t constrain its force to one axis. I’m trying to make a hoverboard float a certain distance above ground while other constraints propel it along the ground. Since AlignPosition applies forces in all axes, it interferes with the other constraints.
23 Likes
Extremely disappointed we still don’t have this. Constraints were meant to be the proper replacements for the aged BodyMover classes. Where is the functionality?
35 Likes
I’m in need of this functionality at the moment. The AlignPosition constraint is useless in my case because you can’t limit specific axes.
16 Likes
It’s been 3 years and many Constraints are still lacking features that are present in certain BodyMovers they’re meant to replace. Any word on this?
29 Likes
This is a blocker for me adopting new physics constraints.
I want to have a part move around with LinearVelocity on the X and Z axis, and have an AlignPosition control the height of the part off the ground.
This currently isn’t easily possible unless I swap the AlignPosition to a BodyPosition object. If I wanted to use AlignPosition I’m forced to integrate the functionality of LinearVelocity into my code or handle the height control with LinearVelocity instead of a AlignPosition/BodyPosition object.
Ideally I could just turn off the X and Z axis forces of the AlignPosition to solve this problem, just like I can with BodyPosition. I’d really like to use new technology but I don’t want to adopt it if I have to redesign how these physics objects are managed. It’s a different story if I can achieve 1:1 functionality with the older BodyMover objects.
34 Likes
Support. This is literally the only reason I won’t stop using BodyPosition and BodyGyro. It’s disappointing to have to keep using deprecated features due to silly limitations like this, especially given the benefits of the new constraint system. Please add this, it’s long overdue.
20 Likes
4 years on and we still don’t have independent axis control for alignposition.
It should be relative simple too, since they already have a similar implementation for LinearVelocity.
Just add a VelocityConstraintMode with Line/Plane/Vector, and then a category for each, such as in Vector mode its just Position, in Plane mode you have Position with PrimaryAxis and SecondaryAxis, and in Line mode you have Position with Axis.
17 Likes
Have just run into the need for this once again with AlignPosition. This is a highly needed feature for those who want to move away from legacy movers and take advantage of new constraints
3 Likes
Can we finally have this added in?? I’m also at a point in my project when i’m having the exact same issue. This is really dumb and alignposition should just have what bodyposition already had.
(Edit) Roblox giving the bare minimum to developers:
2 Likes
We have multiple constraints to lock to a specific axis.
PlaneConstraint will lock to 1 axis.
PrismaticConstraint will lock to 2 axis.
AlignPosition will control all 3.
Is there a particular use case where these constraints will not work?
3 Likes
I still use BodyPosition because I need to restrict the Position on all axes, but at different strengths for each axis. Essentially, I need MaxForce as a Vector3. AlignPosition’s Maxforce property controls all axes at once and the other constraints do not even have a MaxForce property at all.
10 Likes
I still use BodyVelocity instead of LinearVelocity for this reason as well.
BodyVelocity allows me to set the MaxForce on each axis, so I can do (1, 0, 1) and have gravity still affect the object.
LinearVelocity means your object loses all gravity and must be floating to have the velocity applied.
3 Likes
You can do this with LinearVelocity by changing the VelocityConstraintMode between Vector, Plane, and Line.
BodyVelocty with MaxForce == (1,0,1) is the same as LinearVelocity with VelocityConstraintMode == Plane.
The benefit using LinearVelocity is now you aren’t limited to the World XYZ axis. Your plane can be anything
3 Likes
Can you share some details on what you’re trying to achieve? Thanks
1 Like
When players die in water, I need to make their body float (Part water, not roblox terrain). To do this I use a BodyPosition that locks the body on the Y axis, but the X and Z axes have a less powerful maxforce so the body can be pushed around. Something like this:
BodyPosition.MaxForce = Vector3.new(mass*20,mass*300,mass*20)
I also have lily pads in my experience that need to stay in place on the X and Z axes but need to give in slightly on the Y axis when a player jumps on them.
1 Like
Slightly offtopic, but I have also not switched to LinearVelocity due to a bug that causes 2 clients to desync if they are welded together while controlled by LinearVelocity. I need to be able to weld characters for the combat in my game so I had to switch back to BodyVelocity after discovering this.
1 Like
For your first case, you want it locked on the Y axis, and movement on XZ. So, you’d use a PlaneConstraint to achieve this.
Then, you can additionally add the AlignPosition with a MaxForce of mass*20 to slightly restrict that XZ movement.
For the lily pads, you want it locked on XZ, with movement on Y, giving the lily pad freedom to slide up and down. So you’d use a Prismatic to lock in place, then use the AlignPosition again with a small max force.
Would this work for your cases?
1 Like
I guess the issue is 99% of the time, I’m just looking for the (1, 0, 1) case. Very rarely (if ever) have I needed to constrain a force to an arbitrary rotated plane. I would just manually adjust the force.
So whereas previously you simply:
- Set MaxForce = (1, 0, 1)
You now must:
- Create an attachment in a separate instance that isn’t a part of your moving assembly
- Set the force to use this attachment
- Align the attachment to the desired plane, which will likely take trial and error to figure out which axis is used
So even if the overall functionality is greater, it’s added a lot more complexity to the use case that the majority use it for - to the point where nobody can even figure it out without asking an engineer. I’m not sure what the right answer is here, but hopefully that explains why people aren’t intuitively switching over.
2 Likes
Agree that things can and should be easier. Eventually we hope do develop better tools that simplify setting up various constraints while still having the flexibility when needed.
However, I don’t totally understand your first step for the alternative? Why do you need to add a second attachment that isn’t part of your moving assembly etc? And ideally the constraint visualization should prevent any need for trial and error when rotating the attachment.
Here is a quick demo of how I would set one up for having a part move around on the XZ plane relative to itself:
1 Like