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
Can you share some details on what you’re trying to achieve? Thanks
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.
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.
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?
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:
You now must:
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.
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:
What happens if that part bumps into a curb and rotates? The force will be relative to the attachment, which is relative to the part’s orientation if I understand correctly.
This means you need the attachment to be parented to something else (go-to method is parenting to Terrain) so that it does not move with the assembly.
Then you don’t set the “RelativeTo” to Attachment0, you set it World (which is what it is by default)
For the lily pads solution - I feel like it’s so much more intuitive to have 1 constraint accomplish this goal, (like legacy body movers can) instead of 2 constraints that could potentially interfere with each other. Especially in more complicated assemblies where you may have even more than 2 constraints working together, things quickly get messy as they are all fighting to achieve their own goals, and it becomes even more difficult to tweak the properties to get the result you want without messing something up.
As much as I think this modular approach to constraints is cool, it does not seem very user friendly to need 2+ constraints (plane, prismatic, etc.) just to limit certain axes. The fact that it is technically possible with a combination of constraints doesn’t take away from how useful it would be to do the same thing directly with align position and orientation. I think having this functionality also allows for more creative use of the different constraints, compared to being forced to rely on one solution for a problem like this.
TLDR: It’s good to know that this kind of thing is doable, but I still think the functionality should be added to individual constraints.
Sorry for the late response. The Lily pad solution might work but like Preston mentioned it is a lot more convenient to have a single constraint for this. For the first case it will not work however, because a PlaneConstraint has no MaxForce property, so if a player dies underwater their body will instantly snap to the surface. I require different MaxForces on the Y and XZ axes.
Example: I want to align an object to a specific X-Z coordinate but want to still be able to control the Y axis independently with other constraints, for example using a VectorForce to make the object jump upwards.
It may be possible to do this with constraints, but the solution is complicated. Right now, it is much simpler to use a BodyPosition due to its MaxForce property being a Vector3 value.
Changing AlignPosition.MaxForce to a Vector3 (or giving us the option to change it to a Vector3) and adding a AlignPosition.RelativeTo property (for MaxForce) will solve this thread, and make AlignPosition so much more useful. I don’t think that’s too complicated of a change.
This is still important, and would make switching to constraints a lot easier.
I am currently trying to use constraints for ship movement - with bodymovers, I’d only need one BodyPosition and one BodyGyro;
BodyPosition would have a higher MaxForce on the Y axis, and lower on XZ axes; this would make it instantly align to the water height, while still moving slowly on the XZ plane.
BodyGyro would have a low MaxForce on the XZ plane for slow up-and-down bobbing with the waves, and a high force on the Y axis for quick turnaround maneuvers.
Neither of these are possible without splitting each component into two, leading to four objects with 6-7 properties to set each.
I’ve had an extensively hard time trying to utilize these constraints even outside of this, because my understanding of physics is very shallow. BodyMovers allowed me to nonetheless create powerful effects without any knowledge, but with the constraints system I get constantly lost trying to configure the PrimaryAxis, SecondaryAxis, PrimaryAxisOnly, etc. properties.
This has lead to me spending a week simply trying to understand this system, which on one hand is embarassing on my behalf, but also a huge time-drain on something that could’ve been spent on projects far more productive.
Sad that after 5 years they haven’t made any improvements.
Though I kinda expected this, Roblox doesn’t care about developer feedback.
There is this called Plane Constraint to choose which axis to constraint to and it is relative to the attachment.
This constraint requires 2 baseparts to work. In addition to that, it is a rigid constraint, there is no “wiggle” ability like there was with body movers.
It’s less performant and you can’t get the desired effect.
It requires 2 attachments to work where 2 attachment is parented to 1 anchored basepart. But yeah it is rigid tho so that’s the downside if you ever want to drift the axis slightly.
I’m requiring such a thing with Align Orientation. I need to stop a train tilting over, thus locking its Z axis, but still allow it to go up hills etc, which requires keeping the Y and X orientations free to move. Because of this limitation, I’m still using BodyGyro as its the only thing that allows this.
I also ended up using this for a motorcycle I made.
As a matter of fact I use BodyGyro for every vehicle system I make.
I wish roblox actually took a look at this and made a change. The sad thing is they already made the code for this in body gyro and just need to essentially copy paste.
Good news everyone. We have added a “Vector” force limit to AlignPosition to address this request. The code is currently making its way through our normal QA and release process and should be available soon. I’ll follow up once the change is live to make sure we are moving in the right direction on this issue. Thanks.