How? As shown in this GIF I want to limit the train (or in this case, part) from tilting left and right, effectively the red axis (which is the Z axis on the part’s orientation). The other two I need to freely move for hills and corners.
I believe this is currently possible with AlignOrientation using the PrimaryAxisOnly option and the Perpendicular AlignType. You would create an Attachment with the PrimaryAxis oriented with the Y-Axis of the part and set the PrimaryAxis of the AlignOrientation constraint to be the X-Axis. This should replicate what you had with the BodyGyro when using a non-zero torque only on the Z-axis. As the train turns, you may need to adjust the PrimaryAxis on the AlignOrientation to ensure it can go up and down hills oriented in different directions but I assume you were already doing that when using the BodyGyro. Would this setup work for your case here?
I have attempted to do as you describe, but its proven challenging, and as you say, requires adjusting the PrimaryAxis. It would be a lot simpler to have a way to limit what Axis the AlignOrientation effects, similar to the feature recently added to AlignPosition and what BodyGyro had, for simplicity more than anything.
6 Likes
I’ve been having issues with a similar thing to @TheModsterRB as well.
I need to make a character stand upright but be able to turn freely from physics, and bodygyro works perfectly for this but it’s buggy sometimes.
I tried using primary axis on AlignOrientation but it didn’t work (the reasoning is complicated) and I agree that it would be much better if the force could be limited per axis.
Currently I have to use a bodygyro which is definitely not ideal as it’s deprecated but it’s the only thing that does the job correctly.
The basic reason of why the primary axis didn’t work is it allowed the character to be rotated upside-up AND upside-down, as it was on parallel mode.
Parallel mode was the closest to it working I could get.
4 Likes
Still looking for AlignOrientation limits.
2 Likes
Started working on a game that needed this about a week ago, so this is great timing, one issue I have though, is that using RigidityEnabled seems to not be compatible with the PerAxis setting, as enabling it hides all the options pertaining to the axes, and forces it to apply to all 3 axes again. Is it possible that this feature could work with rigidity? If not, I guess it’s close enough.
1 Like
The feature we implemented only relates to how the constraint force is limited. If you want rigid behavior on a per-axis basis, you are much better off using a planar constraint or cylindrical constraint. Is there anything about these constraints that make them unappealing for your scenario?
1 Like
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.