Differential D1545
BGE: allow setting velocity to zero in a motion actuator. Authored by Sybren A. Stüvel (sybren) on Oct 9 2015, 12:14 PM. Tags None Subscribers None
Details The motion actuator goes out of its way to prevent setting zero velocities, One of the issues that's already visible with this simple change, is
Diff Detail
Event TimelineComment Actions Looks good to me. With respect to ZeroLinear/AngularVelocity, I think we should keep them in place as a method to detect fuzzy zeros and avoid undefined results when we compute m_current_linear_factor or m_current_angular_factor Comment Actions That tiny movement is due to the gravity acting during the physics pass. For me is ok as if we want to stop completely the rigid body under those circunstances we always can disable the rigid body. I.e. if we would have a ball over an horizontal plane and we stop it then in that case the ball wouldn't move.
Comment Actions @Jorge Bernal (lordloki) @Porteries Tristan (panzergame) this change caused T46902. We overlooked what happens when someone applies a force with the motion actuator, instead of setting a velocity. In that case, the velocity is also set to (0, 0, 0) in the UI, and should be ignored (like before this patch). This can be worked around by enabling the 'add' button, but that is a backward-incompatible change, and isn't available to angular velocity. The root cause, in my opinion, is that the motion actuator tries to do too many things in one brick. We have to guess what it means when the velocity is set to (0, 0, 0), and I don't like that. I can think of multiple ways to fix this. A) A "simple solution" would be to split it up into two bricks (or two modes for this brick), where one influences velocities and the other applies forces. However, I'm fairly sure that someone has done both simultaneously in one brick, and that would make loading such a file (and automatically setting the correct new brick (sub)type) rather difficult. B) Alternatively, we can add even more UI elements (I'm not a big fan, but want to mention it anyway) to let the user make a distinction between explicitly setting to zero and ignoring. C) Another alternative is to move the zeroing of velocities to a new subtype. That way the new functionality (setting angular/linear velocity to zero) has to be chosen explicitly. This also wouldn't clutter the UI for the "Simple motion" brick subtype. D) A final option would be to simply roll back this patch. My preference would be with option C), although option D) also works for me; my stuff will keep working, as this patch was merely a way to bring D952 (which I really need) to the logic bricks (which I usually avoid). Comment Actions Since there hasn't been any further discussion here, I have reverted the patch (i.e. option D above) in rB83c910992667. | ||||||||||||