The OneAttachment option available with the AlignPosition and AlignOrientation constraints are preferable, as I can explicitly set the Position on the constraint itself, instead of relying on a second attachment floating somewhere for each entity. Additionally, though I’d like rigid behavior limited per axis, there will be situations where I would like to toggle this on and off for the same part (aligning position using forces for smoother transitions like I have now), and it’d be nice to have this behavior encapsulated by a single constraint rather than having to toggle between multiple different constraint setups for similar behavior.
4 Likes
For context, I’m creating a game similar to agar.io where a LinearVelocity constraint controls the movement of cells, and AlignPosition is used to stabilize the vertical position of the cells while they slide around freely. As the cells grow in radius, their height also increases to about 1% of their diameter, so that larger cells show on top of smaller cells. Because they grow in height, the AlignPosition also shifts up to keep them aligned vertically as they grow. Without rigidity, if the cell’s height increases by a large amount, then there is a brief moment where the align position would be too low, and cells would be pushed into the ground until the constraint applies enough force to move it up.
Using a plane constraint would make it hard to manage this setup if I were to use forces for other effects that do need smooth motion on the vertical axis, and would also interfere with the linear velocity that’s already controlling the planar movement on the X and Z axes.
2 Likes
I don’t understand why the developer is asking us “why do you need it”, these are supposed to be alternatives to BodyPosition, BodyGyro, etc.
You have failed to create the same functionally as the things that you were supposed to replace, and you are asking us why do we want it?
We never wanted Body movers to be deprecated in the first place, but it was. Now this “alternative” has the developer asking us “why do you want feature parity”. It’s legitimately infuriating.
6 Likes
Well, I’m sure they have many different people working on different things so this is the standard process for things to be added, they can’t cover all edge cases upfront which is why this forum exists.
1 Like
Yes, and when we make a request, we shouldn’t have push back for feature parity.
2 Likes
I believe the “push back” is just seeking clarification to see if what’s being asked is really a new request, or some kind of misunderstanding that an existing feature could resolve. No point in adding tons of redundant features wherever they’re requested without considering the specifics of what problems are being run into.
Hello I need some of your help! 
(if possible)
The following message I sent it to the release notes:
Ok so, at first I was excited until I noticed how the following feature works:
I thought we would be able to set an Unit Vector which would serve as a multiplier to the current MaxVelocity property, where the default would be Vector3.new(1, 1, 1).
This feature works exactly like the old BodyPosition and to this day I still don’t know how to control these huge numbers to maintain a PROPER LINEAR VELOCITY.
If I am missing something here, please let me know; else let me know how I can maintain a linear velocity since I don’t want my objects to move as fast as possible to the goal and then slow down to reach it.
I am probably using the wrong Constraint here, so what I want to achieve is to be able to move an object by X and Z at a certain speed like a Humanoid ignoring completely the YAxis so the object remains affected by Gravity.
Sorry for the perceived push back. I’m just asking for clarification about what exactly is missing with our current offering. The additional capabilities of AlignOrientation, in particular its ability to operate in Two attachment mode, makes the formulation of a vector torque limit very difficult. We believe it is feasible but would come at the price of performance and possibly stability. Before heading down that road, we want to make sure that anisotropic torque limits is truly what creators need. Based on our survey of use cases, we found that the vector torque specification for BodyGyro was predominantly used to disable the constraint along particular axes by specifying a zero torque for that component. AlignOrientation provides this capability explicitly so we believe we have feature parity in this regard. Do you have any use cases that use BodyGyro and require different non-zero torques along each axes? If not, is there anything that prevents you from using AlignOrientation? Based on the comments here, AlignOrientation clearly has some usability issues that we need to address so any feedback is welcome. Thanks.
6 Likes
Hey, regarding different torque values for the different axes, here’s my usecase that was posted above:
Of course, this can be replicated with two separate AlignOrientation objects, but it’d require essentially double the line count to instantiate & define the properties of both instances, and is more of a hassle to setup.
2 Likes
Any further input on this? I should have mentioned it before but, I don’t see how either the plane constraint or the cylindrical constraint would address the use case I provided, where I need only one axis to be rigidly aligned. The cylindrical constraint rigidly aligns two axes and allows for one axis of movement. Plane Constraints seem to just affect the orientation of parts, nothing to do with restricting movement. I need to keep my parts aligned to a specific height (rigidly), while allowing them to slide on both the X and Z axes unaffected. AlignPosition almost does this, barring the fact that it can only be done with this per axis force limitation, which necessitates being not rigid. Not sure what a good implementation would look like, but I think AlignPosition is the most ideal constraint to add this sort of functionality to. Something like, having the PerAxis limitation that’s already implemented also limit the axes of the rigid mode transformations would be sufficient.
2 Likes
Is there any update on this? I’m still very much in need of having a per-axis limitation on AlignOrientation to get what I require.
2 Likes
Limit AlignPosition and LinearVelocity Max Forces per Axes
The day’s finally come!
5 Likes
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.