trying to write an orbiter; it's NOT what you think

I'm trying my hand with dealing with "physics" for the first time, applying pushes to an avatar to try to move them to sky platforms too high to use non-physical means (and with me too lazy to fly to). I've seen a very nice avatar transit system in The Future, which seems to use this principle.

I understand that the ever-annoying "griefer" tools use multiple scripts acting in concert to achieve this sort of effect, without any finesse. That's not my goal.

Suppose I wanted to push an avatar precisely 1000 m in the air.

1. Potential energy = (mass of avatar) * (g=9.8 m/s^2) * ( 1000 m )
   
2. So, at ground, I'd need that as kinetic energy = 1/2 * (mass of avatar) (velocity^2 )
   
3. Solving for v, I'd need an upward velocity of sqrt(2*9.8*1000) = 140 m/s
   
4. To get that velocity, I'd need an impulse of m*v = 140 * (mass of avatar)
   

(BTW, I'm doing this to try to convince you that I'm not a wannabe griefer, and am serious about trying to write a useful script.)

So, when I tried it with a default 0.5 x 0.5 x 0.5 m cube, with a single instance of the cube, and waited till its "energy" charged up to 1.0, it provided significantly less altitude than predicted. Not surprising.

Increasing the cube size to 10 x 10 x 10 m and waiting for it to "charge up" with energy was much better, but still applied inadequate impulse.

I was unable to stay in SL long enough to try multiple scripts, and now can't login -- do 2 scripts in one charged up prim deliver twice the impulse? Only the same amount as 1 script, because the energy gets split evenly? Something in between? Is it predictable and reproducible, if you start with a fully charged up prim?

Also, it's VERY unappealing to have to use a 10x10x10 m cube to apply the impulse... Is there a better way to have more "energy" available in a smaller prim?

I know that the eventual impulse delivered / velocity achieved / final height reached will be somewhat variable (does wind affect avatars, causing drift?), but if the avatar can get CLOSE enough to the platform, perhaps the platform could have a scripted object that could then apply pushes to get the avatar back "on track" for a landing on the platform.

Would this work?

Or is there a better way to deliver an avatar to a precise spot, 1000m+ in the air?

Thanks for any help.

Edited to add: I'm generally in favor of knowledge being available to all, but if knowledgable people believe that this topic should not be discussed publicly, I understand. On the other hand, I'd still hope to receive a PM / IM explaining the principles, hoping that I am not coming across as a future griefer.

So there's a big spanner in the works, namely that velocity of objects gets clamped to 50m/s. Any nice parabola you have going that has a velocity over 50m/s at some point will not work.

Big orbiter stuff often relies on the fact, somehow, that you get maybe one frame at the velocity you're given, before whatever it is that clamps you to 50m/s notices. This is not going to be a good way to get accurate movement control though (well, I'd be impressed if someone managed it).

It is however possible to put prims up there above 768m (there are a few tricks for working up there), and pushes still work. I once had a chain of pushers going all the way up to 4000m set up.

LOL, that'll teach me to believe that SL would obey the laws of physics, as set forth in the scripting Wiki (or perhaps I just missed the velocity clamp).

Any suggestions for _controlled_ movement to a target at 4000 m? Perhaps a warpPos() to 768 meters, and followed by a series of pushers?

I figure the pushers would have to be "5 seconds apart", if each pusher in the chain accelerated the avatar to 50 m/s, with a velocity decay of g just under 10 m/s^2?

Or, to keep velocity up, a pusher that got the avatar to 50 m/s, and then an attached object would provide a constant upward force to maintain that velocity? But even in this scenario, the time to get from 768 to 4000 m at 50 m/s would still be just over a minute of travel time.

Or is there a better way?

I don't know of a faster way up. IIRC warppos won't get you up above 768 either. Well, presumably griefer style orbiting technology will get you up, but I don't know how that stuff works, or if it's controllable.

There is a faster way down though: sit on a prim and edit it

LOL -- yes, that was my plan for going down -- sit on a prim at 4000 m, script a call to llSetPos (so it wouldn't be restricted to only the owner) to drop to 768 m, and then warpPos() the rest of the way down. That should be near instantaneous.

Not much in the public domain that I know of about how griefer push scripts work, but the hints seem to be that it may be one or both of up to hundreds of scripts acting simulteously (how indescribably crude...), loops calling llPushObject within the script, and possibly having the scripted object follow the target as well, to minimize the r^3 decay in power with distance between the pushing object and the target, between subsequent pushes.

Here's hypothetical idea #2: use a modified griefer tool in iterated steps with rapid / exponential decay in vectored push power, depending on remaining distance to the final target:

1. set up multiple griefer-style prims (once I learn how to do that)
   
2. have the first one orbit upwards with good power, to reach hopefully within a thousand meters of the target altitude (say, ~4000m); communicate to the next prim that it has fired
   
3. have the second and subsequent prims figure the difference between current position and target position, and fire another vectored llPush that would be scaled down, depending on how close we got
   
4. by the time we get near target, fire a controlled llImpulse to hopefully drop velocity to near zero
   

Since I _think_ energy available is to an entire object, these prims would have to be unlinked, which is annoying, because each would likely have to take up an attachment point. Which also makes it a pain to set something up to allow visitors to reach the suborbital skybox. Or, perhaps regeneration of "energy" occurs fast enough / movement is slow enough, that fewer prims could do the pushing.

Bah. Perhaps your series of fixed pushers is still better (but slower).

I feel like a theoretical scripter... I need to get in-world to try to make sure any of this can actually be applied.

I have some experimental push-lifts from ground to 768 using only a couple of simple booster prims. For me it's a nearly instantaneous trip, assuming the av passes through all of the phantom boosters. You might give it a try and see how it works for you. The "full velocity for a frame, maybe" theory is interesting and might explain some erratic impulse behavior I've seen in my setup- also why the journey is usually so fast.



This is pretty much what I'm shooting for with my lifters but my maths are coming up short. :/ I've been trying to create a function to calculate the impulse needed to pass the av through some remote point at a given general velocity. As far as I've been able to tell, wind is not a factor but gravity is. Then again, lately I seem to get different results depending on the av's rotation so I'm probably way off anyhow.

Being able to calculate if the moving AV is on target to the next booster and how fast they'll pass through it would also be very useful for energy budgeting in booster prims. I'm trying to lift groups of avs nearly simultaneously and the lifters only seem to work well with a full energy budget.

I have a long range teleporter that will put you where you want to go. IM me ingame.

I think I could review the physics and calculate all that; the problem is that when LSL puts caps and limits on top that alter the physics (like velocity limiters, and "energy" recharging), the calculations do no good.

When I get the chance, I'll tinker some more.



Cool! If it's a non-full permissions script, though, with proprietary / secret algorithms, that's OK -- I'd like to try writing my own.

For me, it's not just the end result that matters so much. I'm trying to learn how to work with scripting physics interactions, and this seemed to be a nice challenging project.

But your teleporter sounds cool! Does it work above the "usual" limits, to heights between 768 and 4,000m? Because that's the challenge.

It's a free one I found somewhere recently. I dropped it to you ingame and attatched it here.

It looks like this one uses warppos, which last I heard, is limited to 768m because it uses setpos-like movement. Great for long range teleports more horizontally...

I grabbed the wrong one. Sorry. Here is the right one also opensource.

Just scanned the code -- thanks VERY much! That ought to work as a really good starting point for me. Issues that might come up with their solution:

1. it only handles vertical target altitudes; no X/Y targetting. This should be modifyable by calculating an appropriate X, Y impulse in the not_at_target() event handler, and possibly further corrections once at altitude, if not at the appropriate X/Y coord
   
2. in fact, if you started running this script with enough horizontal velocity to move more than 50m away in the X,Y coordinates, llTarget would never be satisfied
   
3. X,Y targeting might end up being pretty tricky, because the eventual goal (for me) will be to deliver an avatar to land gently on perhaps a 20 x 20 meter landing area, at 3000+ meters, from above (doesn't do much good to slam the avatars head into the bottom of a platform, and then let him plummet)
   
4. this script will fail if there is insufficient energy, so lifting massive objects will likely fail (likely for the person who was trying to lift multiple avatars). Could probably be fixed by including additional prims with energy, but I have to look into how energy in linked prims is expended, as well as how quickly energy is repleted
   
5. the descent could be made much more rapid, if instantaneous descent to 768 m was wanted (as Seifert Surface mentioned), by calling a non-physical movement function
   

When I manage to get in-world, I'll actually try out the script.

Wow, nifty

Thanks Simstick!

Ged: looks like it switches to the normal llMoveToTarget once it gets within 50m of the height it's going to. You could just switch it at that point to llMoveToTarget to wherever you want to go.

Yes -- it all depends on how much energy is left in the prim when it gets there. OR, if the limited impulses make it take too long, and you'd prefer to quicken the process by using more of the energy allotment, and relying on the "single frame" of really fast movement, followed by a loss of most of the kinetic energy.

I wasn't able to get the script to work -- perhaps the physics engine on SL has changed a lot since the script was written, and drastic changes are needed. There is never sufficient energy.

Bottom line is that I think it still might require a loop or multiple calls to llPushObject within the script to generate initial massive upward impulse, as well as probably multiple copies of the script.

Or, if I'm not getting it to work for more obvious reasons, I'd love to hear it.



Edited to remove conjectures, and to add: the script does work very well -- not sure why my object didn't work, but I received one with an identical script, and it works fine on the same land / sim. Will figure it out later. Probably something stupid I did.

It works a little different in that you right click and sit or teleport then when seated you have to click on the object. Other than that it might be your sim. Ill test mine tomorrow when I get online.