WarpPos -- llSetPos without the limits

So far this same general principal...

Did not work for me trying to apply multiple CAMERA_POSITION calls to llSetCameraParams to try to move the camera more than 50m from my avatar.

Did not work for calling multiple PSYS_PART_END_SCALE to make larger particles.

But, I'd be pretty surprised if there were not other instances where one could "stretch the rules-list" of other functions, maybe the vehicle engine, ect, using this...

Of course not. If you think about it, the CAMERA_POSITION is related to your AVs location, which does not change. With PRIM_POSITION, after each execution, the position is changed. The same sort of this goes for particle size-- there is a hard limit to how large it can get, it is not relative to current size.

Well done, certainly one of the most exciting hacks in SL I have ever seen.

This doesn't supprise me at all (I've done alot of work with llSetPrimitiveParams, i'm supprised i didn't think of this use).

I've made some changes that should reduce it's memory overhead (and make it a bit faster).

    warpPos( vector d ) //R&D by Keknehv Psaltery, ~05/25/2006
   { //with a little pokeing by Strife
   	if ( d.z > 768 )	  //Otherwise we'll get stuck hitting the ceiling
   		d.z = 768;
   	//The number of jumps necessary
   	integer s = ((integer)(llVecDist(d, llGetPos())/10)+1) << 1;
   	//Try and avoid stack/heap collisions
   	if ( s > 100 )
   		s = 100;	//  1km should be plenty
   	//Solve '2^n=s'
   	integer e = (integer)( llLog( s ) / 0.69314718055994530941723212145818 );
   	integer i = e;
   	list rules = [ PRIM_POSITION, d ];  //The start for the rules list
   	while ((i+=2) <= e)	 //Start expanding the list
   		rules = (rules=[]) + rules + rules;//should tighten memory use.
   	llSetPrimitiveParams(rules + llDeleteSubList( rules, s - (1 << e), s));
   }
   

Ah, I was waiting for something like that, Strife.

Yes, your function is faster. With my benchmarking code, it took 42% of the time that the original function uses.

I'll update my stuff to include your code, cleaned up the slightest bit.

I suspect you might have already known this, but it came as a surprise to me: unlike the series of llSetPos calls this simulates, this does not actually appear to cause movement through the intervening space. I know because I replaced the guts of my llSetPos-based teleporter with this, expecting to merely see a speed increase, and discovered this also solved the problem I had where my teleporter would stop dead in its tracks if there was a "NO ENTRY" fence between the start and end points. So now, not only can I get to my skybox almost instantly, I can teleport between spots I couldn't before due to intervening security. Thank you so much for publishing this information.

I totally endorse your cool hack, Keknehv Psaltery. Genius.

You too, Strife Onizuka.

From strife's code:


Remember that lsl floats are only 32 bit IEEE representations, only accurate to 6 or 7 decimal digits, so 0.693417 would have had the same result. I guess that the lack of double accuracy might somewhat impair the use of long distance travel.

Fantastic ideas, however, Strife!

Yes, it is rather interesting how it happens in one frame. I suspect that this is because ll calls are handled by the server in one frame, and the land accessing takes a moment to register. Have you ever noticed how it is possible to partially fly into a parcel before you are repulsed?

I noticed that, so I trimmed it to about 12 digits in my update.

Very interesting.

This totally rocks.

Now, if we could get one with a limit of 100,000 meters, (100 scripts?) we could probably fly warp speed anywhere on the grid.

LL might as well introduce llTeleportAgent.

Can you really move an avatar with llSetPrimitiveParams?

Of course. If they sit on the prim. With the new update, all the av has to do is to touch it. I used this to make an elevator from my house to my skybox and back. It's instant. I'd say its even quicker than tping within the same sim.

BTW I accidentily introduced a bug that reduced the range from 1000 -> 500 meters (which i have fixed below).

The issue with the Log2 generation is obscured behind a set of other issues. First the distance is limited to 2^31 - 1 by the conversion of the distance to an integer. Then it is trimmed down by a conditional to be no greater then 1000m.

Lets ignore the 16k memory cap for a moment.
The first issue isn't the error introduced by using an approxomimation of Log(2), the issue is in the distance calculation with llVecDist (or llVecMag, which ever you use, using llVecDist will save you 1 byte and be a bit faster). llVecDist returns a float. Floats only have 24 useful bits. This means that when the distance exceeds 2^24 + 10 it will no longer be able to reach the destintion. It should also be pointed out at this time, that unless the distance is diagonal, the floats making up the vectors used won't have much precision either. You can get 2 more bits out of it, if you devide each of the componants by 10 before you take the distance (it would be 3 bits but that bit is probably corrupt from the devide by 10).

The code has been optimized with the intention that it is not to be extended beyond 2^24
I've converted the while loop to a do-while loop, which should speed up the looping a bit.

warpPos( vector d ) //R&D by Keknehv Psaltery, ~05/25/2006
{ //with a little pokeing by Strife, and a bit more
    if ( d.z > 768 )      //Otherwise we'll get stuck hitting the ceiling
        d.z = 768;
    //The number of jumps necessary
    integer s = ((integer)(llVecDist(d, llGetPos())/10)+1) << 1;
    //Try and avoid stack/heap collisions
    if ( s > 200 )
        s = 200;    //  1km should be plenty
    //Solve '2^n=s'
    integer e = (integer)( llLog( s ) / 0.69314718055994530941723212145818 );
    integer i = e;
    list rules = [ PRIM_POSITION, d ];  //The start for the rules list
    if(i <= e)
        do
            rules = (rules=[]) + rules + rules;//should tighten memory use.
        while ((i+=2) < e);     //Start expanding the list
    llSetPrimitiveParams(rules + llDeleteSubList( rules, s - (1 << e), s));
}

    if ( s > 200 )
        s = 200;    //  1km should be plenty

Max in-sim distance is 849.056 m. So, yes.

Yes, I calculated that, but decided that 1km was a prettier number to write than .85km

I was playing with this in order to improve the "Park" command on my airships. My thinking was I'd basically turn this into a long distance warp home. I already was storing the parked position in global coordinates, so I could park across a sim boundry (it seems my land is always on a sim boundry, and it's nice to be able to get close and just park and not worry about which side of the line I'm on). The posted warpPos function intentionally limits itself to no more than 100 steps, and to keep memory usage down I decided to keep the list length from getting much bigger than that, and just call llSetPrimitiveParams multiple times in a loop for real long distance warping. So I threw together this function:

glSetPos(vector dest) // dest must be in global coordinates
{
    vector prev = dest;
    vector pos = llGetRegionCorner() + llGetPos(); // glGetPos() inlined
    while ( llVecDist(pos, dest) >= 0.01 && llVecDist(pos, prev) >= 0.01 )
    {
        integer steps = (integer)llCeil(llVecDist(pos, dest) / 10.0);
        if ( steps > 128 ) steps = 128;
        list rules = [PRIM_POSITION, dest - llGetRegionCorner()];
        integer len = 2;
        while ( len < steps )
        {
            rules += rules;
            len += len;
        }
        rules += llList2List(rules, 0, steps * 2 - len - 1);
        llSetPrimitiveParams(rules);
        prev = pos;
        pos = llGetRegionCorner() + llGetPos(); // glGetPos() inlined
    }
}

The result was rather interesting. I first flew from Solha to Danbi and hit "Park". Worked perfectly. Then I flew from Solha down to Malgeungaram (say that ten times fast), then hit "Park". Next thing I know, I'm hanging in mid air. The menu bar is reporting my position as something like Gilum 241, 955, 252. Hitting the map shows my position as well away from Gilum, indeed Gilum is about halfway between my starting point and my current position. I can't move, hitting "Release Keys" does nothing, eventually I log out and log back in. I appear at the north border of Gilum, and begin flying home. I assume something has gone wrong on the second hop, leaving me and my airship in limbo, and now, flying along the straight line course home, I can't find my airship. Did I remember to back up my script changes before testing? No. So I'm flying home hoping to come across the airship on the way. Never find it. That is, until I get home, and see it's parked exactly where it's supposed to be!

So, the airship makes it home just fine from any distance. However, anyone sitting in it ends up in limbo after the second hop.

That's fine in this case. The "Park" command wasn't meant for transport anyway, just a nice way to align the ship right where I want it when I'm done flying. Usually I'm already out of it before I hit "Park", so it's no big deal to just eject the passengers before auto-parking. But this will making implementing a grid-wide "warpPos-teleporter" difficult. You can jump between sims just fine, passengers included, only if you can do it in one hop.

Maybe a pause between hops would allow the avatars to keep up with the object? I'll leave further research as an exercise to the reader. <grin>

Interesting failure mode.

Have to break the journey up at sim boundaries. Might be quicker to use this trick to get to 768m, then use insane physical movement to get to the target sim, and finally pop to the target location with another pass.

0.2s per sim is pretty damn fast.

How does this compare with long range sit teleports in the same sim? I've found that setting the touch action to sit makes the "bouncing around" problem almost vanish, so a sit teleport to 512m is almost fast enough to fake llTeleportAgent() with.

When I get a chance to be in-world longer I'll definitely play around with this.

Gaius, as I said, avatar warping is perilous, but the objects seem to be fine. Yes, I agree that a teleporter utilizing warpPos is not likely to occur anytime soon. The really fascinating thing for me is how one call to llSetPrimitiveParams can successfully shunt an object through 8 sim crossings-- the sims must transfer objects at a different stage. I find it highly unlikely that the script processing is being handed through 8 sims.

Argent, I've played around with using it as an in-sim teleporter, and I've noticed no difference from sit targets, if the list has already been calculated.

I've replaced all the transporters at the Shelter with warpPos() replacing the old llSetPos() method.

My god, what a difference. Teleportation has always been an issue for us because our build is split between three corners of sims (Isabel/Wingo/Galinas).

Transportation within Isabel is instantaneous - the difference is absolutely amazing.

Transportation to the Wingo side however, I'm still working on. For some reason, I can successfully transport an avatar from Isabel to Wingo without any significant crazyness. Wingo to Isabel, however - the avatar ends up getting disconnected from the Sim.

Transportation from Isabel to Galinas (on a diagonal) causes a sim disconnect every time in both directions.

I'm going to play around with pausing if llGetPos().x or llGetPos().y are either =0 or =255, and see if that adds to the reliability.

If you want to check out what I've done, there's an "Elevator" next to the West side of the Isabel Infohub.

I have news for you: Crossing sim borders at ANY high rate of speed it like asking for your avi to get vaporized.

Even normal setpos movement can wreak unholy avatar damage at sim borders, or that's been my experience. This thing? It's almost a certanty. Still works wonders inside a sim though...

jump to the border then hop the border in a small 2 meter or so jump. maybe put a little pause in before you make the short jump. If one of the sims is suffering from a low time dilation the risk of a disconnect goes up a lot.

WTG Kehknev! (hope I got the speeling right ;^P)

THis is awesome. I cant wait for the grid to come back up so I can incorporate this into the new drifter transport I'm making

Cheers!

Farfletched/Skalligrim

...

This is fantastic, Keknehv! I was using a long range teleporter for my condos in the sky - it was using llSetPos. I added your function and what a huge difference! The teleporter now works like a Sit style teleporter - very fast! It takes longer of my teleporter to start its funky glowing lights than it does to actually teleport someone!

I could not get the optimized function working - my av was always dropped about half-way to the the destination. Your original function works perfectly!

Thank you for sharing this!