llSetPrimitiveParams()

Hi, I was using this function to move temporary prims across a sim, but it doesn't seem to work anymore :

warpPos( vector d ) //R&D by Keknehv Psaltery, ~05/25/2006
{
    if ( d.z > 768 )      //Otherwise we'll get stuck hitting the ceiling
        d.z = 768;
    integer s = (integer)(llVecMag(d-llGetPos())/10)+1; //The number of jumps necessary
    if ( s > 100 )  //Try and avoid stack/heap collisions with far away destinations
        s = 100;    //  1km should be plenty
    integer e = (integer)( llLog( s ) / llLog( 2 ) );   //Solve '2^n=s'        
    list rules = [ PRIM_POSITION, d ];  //The start for the rules list
    integer i;
    for ( i = 0 ; i < e ; ++i )     //Start expanding the list
        rules += rules;
    integer r = s - (integer)llPow( 2, e );
    if ( r > 0 )                    //Finish it up
        rules += llList2List( rules, 0, r * 2 + 1 );
    llSetPrimitiveParams( rules );
}

Does that mean that llSetPrimitiveParams() has been "optimized" to no longer accept more than one position rule?
Should I use a loop with llSetPos() instead, is there a better solution?

TIA
Twisted

I use warpPos a lot with no difficulty, albeit in one of the more recent versions at http://lslwiki.net/lslwiki/wakka.php?wakka=LibraryWarpPos (the mono version there,

warp(vector pos)
{
    list rules;
    integer num = llRound(llVecDist(llGetPos(),pos)/10)+1;
    integer x;
    for(x=0; x < num; ++x) rules=(rules=[])+rules+[PRIM_POSITION,pos];
    llSetPrimitiveParams(rules);
}

is particularly fast.

Or you could use http://wiki.secondlife.com/wiki/PosJump This comes with a warning that LL might break it, though I seem to recall reading in the release notes to a recent server version that they'd actually changed something *because* it was breaking PosJump -- does anyone have a better recollection than do I?

ETA -- it was fixed here https://jira.secondlife.com/browse/SVC-4984

Thanks for the reply, I updated it with the version from the wiki here: http://wiki.secondlife.com/wiki/WarpPos

But that didn't help. I finally figured out that it only happens when it tries to cross a ban line. It confused me because the prim only moves a few meters away from its starting position instead of ending near the ban line, so I thought it was only moved one time.

Ah.. try http://wiki.secondlife.com/wiki/PosJump which, as I understand it, bypasses intervening parcels, so provided your prims are allowed to enter the destination parcel, it should work.

Due to the various warnings, caveats and threats of breakage associated with both PosJump and WarpPos, I take a three-tier approach:

1) attemp to move using JumpPos (most efficient, deals best with uncrossable parcels/ban lines)
2) if distance from target > epsilon, attempt to move using WarpPos
3) if distance from target > epsilon, attempt to move using loops llMoveToTarget/llSetPos/etc

The theory is that, *if* JumpPos and/or WarpPos gets broken in the future (which will be more likely to happen once we have a non-restricted llSetPos), the product will continue to work. The entire mess gets wrapped as a function which can easily be replaced, when unrestricted llSetPos comes along.

When we have the no-delay functions as part of the 'efficient scripts' project then I assume this need for warp/jump pos will go - we can just itterate PRIM_POSITION

The other solution would be to remove the 10 meter cap on llSetPos() and PRIM_POSITION, which comments by Andrew Linden in http://jira.secondlife.com/browse/SVC-4089 suggest is under active consideration and would have -- I think -- the advantage that you wouldn't run into problems with crossing no-entry parcels (I think I'm right in saying that llSetPos() actually removes the object from the start position and replaces it at the end position and that any apparent movement between the two is a visual interpolation rather than the sim actually sliding the object through the intervening points).

In the same jira, Prospero Linden says,

you are correct, as demonstrated by posJump, you'll notice warpPos doesn't get the benefit because each POSITION call is evaluated separately, so each end point for each call is actually occupied.