llPushObject imprecisions

I've recently been playing around with llPushObject, trying to do things like make a series of rings an object/person can jump into to be propelled around to other parts of the world, tractor beams (we've all seen Star Wars, right?), have weapon effects with a gentle nudge (push someone back a few feet), and the gravity gun (weapon in HL2 that lets you pick up, move, and toss around physical objects).

However, there are a few major problems I've found when working with llPushObject. The biggest problem is the lack of an llDetectedMass. How can we safely push an object we don't even know how heavy it is? A large push could move a large object fine, but that same push applied to a small object or avatar would likely ghost it, if not done straight up or down.

Another big issue is the falloff in llPushObject, in which the power decreases with the inverse of the cube of the distance between the two (1/r^3). A push is not an explosion that rapidly decreases effectiveness as range increases, it is a precise, directed movement. Furthermore, the falloff can be easily nullified by multiplying your push by llVecDist(llGetPos, llDetectedPos()). However, if an object to be pushed is in motion (most often by gravity), the distance is likely to be changed since that call is made (LSL doesn't exactly operate at the fastest possible speed), occasionally causing your tiny push in a direction to become a large one, sometimes even enough to ghost an agent or send an object off-world.

These things do little to prevent griefing, as it's much more simple (and much more effective) to simply think of the biggest number you can and apply that push. However, for people who have legitimate reasons for pushing things around, we're finding it next to impossible to do a simple thing like get our tractor beams to bring us up to the ship. Another good example is the bullet with a push. How can we be sure our push will only give the person a gentle nudge, and not either sit and do nothing half the time, or the other half, fling them into the next sim?

To do some quick illustrative (as far as math can be illustrative) examples: A .5x.5x.5 cube has a mass of 1.25kg. If we want to push it up 5m/s (A little push up), it would need a force of 1.25 * <0,0,5>, or <0,0,6.25>. However, if the object doing the push is 2m away, suddenly it becomes <0,0,6.25>*2^3, or <0,0,50>. If the object doing the push were then to move .5m closer during the time it's calculating this, such as either are moving quickly or the sim hiccups or something, we'd now have that push of 50 applied from only 1.5m, on the same 1.25kg object, which would fling the object 11m/s up instead, a little over twice the initial push we'd wanted.

Worse yet, we don't actually KNOW the object we are pushing is a 1.25kg object. At present, the most reliable method I have for determining an object's mass is to get it's bounding box, assume it totally fills some random amount of box, and determine the mass from that. Now, this is not an accurate operation, nor is it fast (leading up to the fallout problem above.) So, now we have unsure amounts of push being applied to objects with data that is potentially outdated and wrong.

This all becomes even worse when we try to push on the opposite of their current velocity, such as to prevent someone or something from being flung offworld by pushes too high, or while trying to keep their velocity constant. Because our pushes are sometimes too strong, the push on the opposite of their velocity causes them not only to stop going in their direction, but also fly into the other direction. When these pushes are called in loops, such as for a tractor beam, the object will oscillate madly until it is out of sensor range, where by now it is probably several sims away. (This has happened to me several times while playing with llPushObject.) The worst is when my opposite push on their velocity happens after they hit an object and are bounced in the opposite direction. This most often happens because the script is spending so much time doing calculations to get it to work correctly, that by the time the push is called, much has changed and the data is no longer accurate. Indoors, this often results in an object bouncing increasingly madly off the ceiling and walls like Flubber until something breaks.

So, as it stands, I feel that this current state actually CAUSES more grief than it prevents, both to the scripter and to whoever is/owns what is being pushed. I think that pushing things or people offworld is MUCH more aggravating than having them moved a little, or held in place. The potential for abuse of small, precise pushes is much lower than the potential of random, very high pushes.

I encourage you all to reply to this, whether you agree or don't, in hopes of either getting these fixes implemented, or showing why this has been broken in the first place.

I find a lot of Linden Labs attempts to stop griefing to less then they seem to think -- or hoped at the time. The only issue I see is in changing llPush -- especially in removing a fallout -- you effect many peaceful scripts. Of course, llAdvancedPush or something could be added.

I also noticed you can't use LL push to rotate an avatar. I always thought it would be cuter to have a gun spin someone around then push them,

I wonder if the mass of avatars is equal regardless of size? This could be tested using the llGetMass() function within an object attached to various avs.

The MegaTower, recently demolished, employed push-rings as a means to get people from the ground to the top floor very quickly... something like 970m up I think? It seemed to work fairly well by incorporating a series of push-rings. The av was propelled just enough to reach the field of the next ring above, which would then push again to just the right level for the next ring up. A few clear, hollow tubes guided the first few meters upwards so that the trajectory could be set, after which the av couldn't steer off-course.