RotVelocity decelerates while Velocity is retained, which is unrealistic behavior in most environments (basically any environment that isn’t super pressurized). We could really use a setting to determine whether or not parts will automatically slow turning, and I have reason to believe that this degradation is hardwired in the first place.
I don’t know if this would be better as a BasePart value or a Workspace setting but it’d be super helpful in my game with more than a hundred scripts updating RotVelovity every 1/30s.
Hundreds of scripts changing RotVelocity every step? That sounds very bad and unnecessary. Try have one script that loops through the parts you need and change them from that instead of having lots of separate threads.
Also, what do you mean by Velocity doesn’t decelerate? As far as I understand, both rotVel and Vel decelerate.
Regardless of that, I think having a bool property or maybe even a vector3 to define how much or whether or not either property should decelerate would be very helpful and eliminate the need for clunky Body(Angular)Velocitys when you don’t need the MaxForce property functionality.
My game basically needs to check almost every single individual part, this fact combined with my lack of knowledge in that sort of mechanic (but trust me, it has a lot of individual components which i’ve jury-rigged with the same script; bad, I know). By ‘Velocity doesn’t decelerate’ I meant that in a zero-gravity game parts will continue to move until acted upon since there is no friction or drag. For whatever reason parts will stop spinning rather quickly after changes to their RotVelocity, although I believe is because touching parts don’t simulate friction towards RotVelocity so Roblox has improvised.
For now we will only decrease it. We still evaluating how much we can do so as it changes behavior and some systems might become unstable. In the future when we implement rolling friction, we might be able to eliminate it.
