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.
Thank the lord i am very greatful of this
This is great thank you for adding this.
What about some of the angular constraints?
Take this example: I have an object in mid air, I want to apply angular velocities to the X and Z rotation of the object, and I want to align the Y rotation to a specific angle. So I would want to use an AngularVelocity and AlignOrientation.
From what I understand AlignOrientation will only allow you to apply torque to a minimum of 2 axes by enabling the property ‘PrimaryAxisOnly’. Seeing as AlignPosition will now be able to apply force to either 1, 2 or 3 axes, it would make sense that AlignOrientation can do the same by turning MaxTorque into a Vector3, this would be a lot more cohesive.
And again, AngularVelocity’s MaxForce is a number not a Vector3, so AngularVelocity and AlignOrientation are gonna be fighting each other because I’m unable to separate their torques into the axes I want. AngularVelocity’s counterpart, LinearVelocity, does allow you to only apply force in specific axes. The current constraints system really just doesn’t feel ‘complete’ in a way and it’s been out for a long time now.
So once again BodyMovers (BodyAngularVelocity, BodyGyro) are the better option here despite being deprecated and I am forced to use them to get the functionality I want.
This still does not fix any issue on the topic of AlignOrientation having the minimum 2 axes.
I had a draft in this topic for a few months at one point saying that this would make sense to do but what would the new property be called? They can’t just change a property type and expect all those games to still work.
This is what they’re gonna do for AlignPosition I believe. They could do a similar thing for AlignOrientation.
Very excited for the ForceLimitMode, ForceRelativeTo, and MaxAxesForce features to be added soon. I am currently developing an experience that uses these features. It would also be nice to see these in AlignOrientation, not just AlignPosition.
Good good good. Is the change live yet?
after extensive testing, no; should be soon though