We are in the process of releasing a bug-fix in the constraint ecosystem that may cause issues in your games if you have been relying on the incorrect behavior. We would like to ask anyone who is employing the feature described below to reach out with a testing place number where we will activate the bug-fix for you to experiment and fix any possible breakdowns before the release.
The correction is concerned with Cylindrical constraints/Hinge constraints when AngularActuatorType/ActuatorType is set to Servo AND AngularLimitsEnabled/LimitsEnabled is ON.
If all of the above conditions are met anywhere in your game, you should continue reading.
Under such circumstances, the previous behavior of the servo may be incorrect in some scenarios depending on the currentAngle, TargetAngle, LowerAngle, and UpperAngle. For instance, if you set up LowerAngle=-120, UpperAngle=120,Target Angle=110, and currentAngle=-110, the servo will eventually get locked at the angle currentAngle=-120. In other words, it will never reach your target angle because it is taking the shortest path toward the target angle, and it reaches the lower limit before reaching the target.
Note that this is not correct, because if the servo chooses the other direction it should be able to get to UpperAngle=110 with no problems. The current bug-fix addresses such issues. See this post. More details about the corrected servo behavior is as follows:
If the servo can reach the target angle from the shortest path without encountering either of the upper and lower limits, it will.
If the servo cannot reach the target angle from the shortest path without encountering either of the upper and lower limits, it will take the longest path.
If the target angle is not in the feasible region and cannot be achieved (for example if TargetAngle>UpperAngle or TargetAngle<LowerAngle) the servo will take the path which will be eventually closer to the target angle.
If the servo’s currentAngle is not feasible, (for example if currentAngle>UpperAngle or currentAngle<LowerAngle) then the servo will snap the current angle to the closest limits from LowerAngle and UpperAngle and then tries to work out the motion. Note that you should already have received a warning indicating that this is an incorrect setup and is discouraged to use because it can cause instability.
See the following figures for more examples (top:previous/incorrect and bottom:future/correct)
Please reach out with a testing place number for experimenting with this bug-fix in your game.
Hello, I’m not sure if this is related but this morning when I tried to update my place I made it public yet it’s not going public for others this is the ID: 4732474971
Unfortunately this is not the issue in your case; this feature is not currently activated unless requested here, so it does not have any effect on you.
I have found this shortest path behavior annoying and limiting because it assumes that the output of the servo is 1:1 with the output of the machine that the servo is used in.
Consider a rack and pinion assembly driven by a servo on the pinion. If the rack moves 2 studs for every rotation of the pinion, one would expect to be able to move the rack to the 6 studs by setting the servo target angle to 1080 degrees. This is impossible because of shortest path behavior. It is also not possible to set relevant limits on the pinion, because limits are constrained to +/-180.
In this gif, the pinion is set to 90, then 180, then 360, then 0. When it is set to 0 from 360, there is no movement. If I had attempted to set the angle directly to 360 from 0 without “in between” positions, there would have been no movement.
This is a slightly contrived example because I could use a prismatic servo for this case, but it demonstrates the problem well. I have seen this problem in the wild in building games where users can set up servos with limits. This issue can in some cases cause the servos to not rotate as the user expects, which causes issues with their creations.
If servos are being revised, I would hope they would be looked at with consideration for this limitation. Perhaps an alternative operating mode that treats rotation as linear space only and will never consider wrapping around.
The current bug-fix indeed addresses the issue with the servo taking the shortest path; However, the servos still work in the space of [-180,180], and your request must be considered in a separate feature release.
Thanks. Just went in-game for some quick tests and found the doors still work except once fully open or closed they will randomly twitch a little bit. I’m guessing this is because I set the target angles for the doors to exactly the limit.
Eg if my door is in the open position when TargetAngle = 90 and closed is at 0 I have Lowerangle set to 0 and Upperangle set to 90 exact. Then a script is responsible for changing the TargetAngle to open or close the door. I guess I could work around this by setting my limits to -2 and 92 to give a bit of breathing room.
Edit: I took a quick video showing the twitching it is really prominent on this bus in particular. robloxapp-20210104-2114118.wmv (2.5 MB)
I have made some minor changes and the feature is now activated everywhere. Could you please take another look and let me know if you see the issue?
If you could reproduce the issue in a simple Roblox model that only has a few parts and a hinge that would let me inspect the issue better if it still exists.
Sorry I’m afraid not. I actually reworked my doors so they do not use LimitsEnabled to stay in the correct positions they now just use a high torque value.
