Bug w/ llSetForce?

I've been experimenting w/ llSetForce and came across a behavior that seems like a bug.

I am attempting to use llSetForce to cause a prim to oscillate back and forth along a line. I’m finding that sometimes the prim gets “stuck” at zero velocity.

My script simply applies a force vector of <0, 0.3, 0> w/ llSetForce(vec, FALSE) for a few seconds, then reverses the force vector to <0, -0.3, 0>. The script cycles between the positive and negative vector values every few seconds. Often the prim is moving very slowly when the force is reversed, then reversed force causes the prim to quickly slow further, stop and get stuck at zero velocity when it should instead start moving in the other direction. It will stay stuck at zero velocity for a few cycles, then usually start moving back and forth again after a while.

I’m assuming others have probably encountered this behavior. If so, could anyone explain the conditions that cause the behavior and any known work arounds?

If you're firing off two setforce commands alternately with equal timing you might first want to consider cutting the first duration in half.

+0.3 for 10 sec followed by -0.3 for 10 sec = 0 velocity.

The irregular behavior may be due to the timing not being precise. For matters involving forces and impulses one must not rely on LSL timing, it's just no precise enough.

Control the action based on position instead.

Thanks for the response, but the problem is that the object sometimes stays at rest (zero velocity) for one or more entire cycles. It's as if the object gets into a state where it completely ignores the force being applied for extended periods of time.

For example, if the script reverses the direction of the force every 5 seconds, then sometimes the object will come to rest and stay at rest (zero velocity) for 5, 10, 15 seconds or longer. During that period the force is being applied to the object for whole cycles (5 seconds per cycle) w/o causing any movement at all. After some time the object becomes unstuck, the force starts pushing it as expected, and it starts oscillating again.

It isn’t an issue of LSL timing. I know the timer is changing the direction of the force every 5 seconds because it is sending chat debug messages.

This unexpected behavior (ignoring force) only happens if the object is at zero velocity. If the object is moving then the force is constantly changing the object’s velocity (accelerating or decelerating it) as expected.

This is a problem with the phyiscs engine "settling" the object when you don't want it to. Once an object is settled, it seems to stay still unless a big enough jolt is given to dislodge it and get it moving again. This allows the physics engine to concentrate on less stuff at once.

I think when something's settled, the physics engine has decided that the sum of the fources on the object has resulted in a net velocity of zero for long enough that it thinks the object has come to rest. In your case, it's not right... but once the object's settled, Havok just ignores that 0.3 force. You might have to give the object a little nudge with llApplyImpulse.

In short: Friction

0.3 is a tiny force. In Newtons it's the equivalent of supporting about 30 grams.

I play with physics/gravity all the time and noticed this as well. I *think* its a linden feature, not a bug. Basically I think the sims changed around 1.9 such that physical objects tend to freeze after a) too many appear, b) too much movement too quickly, c) some other thing I haven't quite figured out.

Basically I've had physical sphere floating via a script and WHAM. They just stop moving and hang in the air until I click on them with the pointer. I really think its an anti-griefer feature.

doubt it'd be an issue with that small of a force but have you checked energy?

Thanks. Applying a slightly larger force does seem to break it out of it's "stuck" mode. Understanding the issue (settleing) helps me to design around it.