Long distance tp problems

Is anyone else having problems with tp scripts not working properly? My tp for my skybox now only bumps me up about 10m instead of 500m. It hasn't worked since wednesdays update (I think).

*sigh* I just checked...I have a dozen TPs that arent working atm. Oh yay fun!

Don't forget http://blog.secondlife.com/2007/03/15/transaction-history-moves-to-the-web-v1134-fixes-in-testing/

Thanks Winter for posting this. My scripts are no mod, so I will wait for the "fix" or just use landmarks to tp for now.

I'd have posted my "ugly little hack" to temporarily revert warpPos teleporters back to SetPos looped teleporters (slow trains)... but the tone of the trhead seemed to say "darn it, all my PURCHASED teleporters are broken".. so I knew that wouldn't help much.

Thats the 2 that I still have a problem with, the rest were modable so 'fixable'. Its a bit entertaining to watch people try and use one of the long distant TPs and just fall back to the ground.

Also llScriptState() is strill broken, there was a fix promised for this morning but no sign that it was actually implimented. As usual no post in the blog one way or the other.

This has been listed as a blocker/showstopper but it doesn't appear that LL really is in any hurry to fix it.

I must say, it's making land/home hunting a blast.

Yup... lol. My tp's were made for me by a friend that doesnt play much anymore. I know next to nothing about scripting and did look in the scripting sections of this forum, but saw nothing that that specified teleporters in the thread title. What the heck is WarpPos?

Okay look at it this way.. "SetPos" (or llSetPos) is a command. SetPosition. When an object is nonphysical (that means "not affected by gravity" but still solid).. a "SetPos" command in a script, acts like a pneumatic ram. Startig off slowly, and then speeding up, and then slowing down again into position. You may notice this effect with scripted doors. They often have a lovely, but quick, animated movement.

SetPos isn't instant. It also has a limitation. If I tell an object to move 300m using SetPos.. it will move for about 10m, and then stop. It's a limitation. The way the older "beam" teleporters worked.. they would have a loop.. that said "while I am still not at 128,128,128, move me towards 128,128,128"

while ( llVecDist(llGetPos(), <128,128,128>) > 0.001 )
   {
      llSetPos(<128,128,128>);
   }

That's pretty simple to get. The problem is, that it's hella slow. There's a real oldschool "Sit" teleporter that can move you 300m in one second. Yet with a SetPos loop, it could take several seconds... creating a need for all sorts of fancy attempts to make the avatar invisible during transport.

ANYWAYS.. What is WarpPos? WarpPos is a cheat. There's a second way to move an object, that doesn't HAVE this delay. SetPrimitiveParams. SetPrimitiveParams lets you set any number of Prim Parameters in one statement.. avoiding a lot of the inbuilt delays and such of other commands.. and allowing you to make a number of changes "at once. One of the neat things about SetPrimitiveParams.. is that you can set the same parameter over and over again.

The trick is, that the script determines the length of the teleport. (the length of the straight line between start and finish) and then divides by 10m. (the maximum jump of llSetPos.). Then, in ONE SetPrimitiveParams statement, it piles on however many llSetPos's it can, in a single llSetPrimitiveParams command:

warpPos( vector destpos)
{   //R&D by Keknehv Psaltery, 05/25/2006
    //with a little pokeing by Strife, and a bit more
    //some more munging by Talarus Luan
    //Final cleanup by Keknehv Psaltery
    // Compute the number of jumps necessary
    integer jumps = (integer)(llVecDist(destpos, llGetPos()) / 10.0) + 1;
    // Try and avoid stack/heap collisions
    if (jumps > 100 )
        jumps = 100;    //  1km should be plenty
    list rules = [ PRIM_POSITION, destpos ];  //The start for the rules list
    integer count = 1;
    while ( ( count = count << 1 ) < jumps)
        rules = (rules=[]) + rules + rules;   //should tighten memory use.
    llSetPrimitiveParams( rules + llList2List( rules, (count - jumps) << 1, count) );
} 

The end result is that before the client can even render it... the prim has executed 30, 50, 70, howver many little jumps... so fast that it appears instantaneous.

In this last update, it seems that the SetPos-like function in SetPrimitiveParams, was altered, creating a situation where it would only try ONE of the jumps. The script was still trying all of them, but the server was basically saying "okay I did it" and wasn't (isn't) doing it the way it used to.

So, you're moving up 10m, and then the beam thinks it's at the destination, and dumps you out. WarpPos has no error checking, to self-revert to the "Slow Train" method.. because up until this last update, it has ALWAYS worked reliably.

The function is SO widely used, and so well known, it is referred to as WarpPos.. and sometimes erroneously as llWarpPos.. because so many assume that it is an official command. Frankly, there are many in the scripting world, who desire an llWarpPos.. if only to prevent the function from being carelessly disregarded in testing.. as it was for this last update.