LSL Scripting

[LeafIllusion]

My teleporter script using llSetRegionPos seems to have slowed way down lately.  It still works very well for very short teleports, under 50m.  But for longer distances it seems to hang, often the viewer displays 0,0,0 as location for several seconds.  The script eventually moves the avatar more or less to the desired location.  I was testing today in one of the premium sandboxes and this "momentary hang" happens about 80% of the time when teleporting over 100m distance.  (My destination coordinates were within the same sim.)  It also seems like the llSetRegionPos function is slower to execute, with the avatar often appearing to sit on the teleporter for a second or two.  Again, this slowdown only happens when moving longer distances.  Changing my viewers draw distance did seem to reduce the problem a little.  Also the problem occured with both the default viewer and Firestorm.  I did not notice these problems when I created the script and tested it right after llSetRegionPos was released.  Wondering if anyone else has noticed recent slowing problems with llSetRegionPos scripts or found a cure for it? 

[Rolig Loon Senior Helper]

I haven't noticed a serious problem with it myself, but I may not have been paying close enough attention either. Most of my own sit teleporters are not moving people more than 1000m or so.  I know that Qwalyphi Karpov complained in this forum less than a month ago that he was having trouble with hitting an accurate target location with llSetRegionPos. You might compare notes with him.

[LeafIllusion]

Further testing indicates there is a strong relation to the draw distance set in the viewer's graphics options.  With draw distance set at 300m the successful completion of a 200m teleport without stopping at 0,0,0 was over 80% of the attempts. So does this indicate the viewer is waiting for information to draw the new location?  Is there any cure for this, or just a price to pay for a long teleport?

Other odd things I noted in the 20 test runs using a simpler script than my earlier tests used.  With the draw distance set at 100m, on about 1/3 of the teleports the avatar went to 0,0,0 before eventually going to the destination.  On another 1/3 the teleporter worked quickly and reasonably accurately.  On the last 1/3 my avatar started walking briefly before teleporting and walked a short distance after arriving at the destination.  One time after sucessfully completing the teleport to the destination, the avatar turned and walked by itself all the way across the sim back to the teleporter!

[Jenni Darkwatch]

Unfortunately that does indeed coincide with my own observations. llSetRegionPos has some odd artifacts. The TP to <0,0,0> is one. TPing an object across sim borders often results in a "ghost" left behind for people looking at the object.

[Dora Gustafson Advisor]

Like Rolig I never had the kind of problems described in the OP
I used llSetRegionPos in my teleporters since it's release and they go above 1000m as often as anywhere else

I would like to know what the problem is though,
if it is related to the way the function is implemented in the the script, possibly.
So here is my code, with which I have no problems

Spoiler

listen(integer channel, string name, key idWriter, string message)
{
    if(llAvatarOnSitTarget() == idWriter)
    {
        integer listPosition = llListFindList(destinations, llCSV2List( message ) );
        if ( listPosition > 0 )
        {
            vector targetVector = llList2Vector(destinations, listPosition - 1);
            vector homeVector = llGetPos();
            if (llSetRegionPos(targetVector))
            {
                llMessageLinked( LINK_THIS, TRUE, "", NULL_KEY);
                llSleep( 1.5 );
                llUnSit(idWriter);
                llSetRegionPos(homeVector);  // teleport back to home
            }
            else llUnSit(idWriter);
        }
        else llUnSit(idWriter);
    }
}

It might be interesting to see the code used by those having problems

[Nexii Malthus Honored Resident]

I'm not sure how it is these days, but a long time ago, when I created a warpPos-based teleporter for a respawn area in a combat sim, where we needed to use the teleport on a high frequency, I attempted to solve the 0,0,0 location issue and some rendering issues.

The way I solved it on my setup as to slow down the teleporting into 30m chunk steps, just slowed down enough so that the server would have enough server frames to send the new location and then have the teleporter move onto the next chunk. This all happened really fast in 100 - 400ms across a vast distance, but gave some breathing room for clients to catch up so that it didn't impede with the fast action combat that we rely on.

[Qwalyphi Korpov]

The resident who provided the previous content, if any, has replaced it with this generic statement.

[LeafIllusion]

As with Qwalyphi, I've found inserting a 5 second delay averts the going to 0,0,0 problem, but of course, the cure is about as bad as the problem.  

In response to some of the other comments, the going to 0,0,0 issue almost never happens when making a vertical teleport.  I can also easily go 1000m as long as it is vertical.  With a  few very specific exceptions, it only happens when moving horizontally across the sim for longer distances.  For example I have 4 of these teleporters using this script in my SL home and all work well and extremely fast for the short hopes between rooms.  

I did try hopping across a sim diagonally using primarily vertical hops.  I did this by jumping from one corner up to the 4090m level then back down to the opposite corner of the sim at ground level.  When I tried that the 0,0,0 issue occured on the way down.  I have tried inserting various length delays into my script in multiple combinations of places with no success unless the delays exceeded a length of 5 seconds.  But having the avatar implanted on the teleporter in a store directory sign for 5 seconds looks rather silly, so not a good option!  I even tried hopping in 50m jumps across the sim, but also still had the 0,0,0 issue.  It is possible I could create a 2 hop teleport that places the avatar into a hidden room in the sim for the 5 second duration...  if all else fails that is my plan B at this point.

I am starting to wonder if this is this an intentional feature of llSetRegionPos?

So far the only reasonably reliable cure that does not need a delay that I have found is to increase my avatar's draw distance to 300m.  But that isn't helpful for a teleporter that will be used by others as part of a public sim.  It seems to me that this going to 0,0,0 may be a method that the function creators are using to address the time needed by the viewer to load the terrain and texture data for the new destination location.  So perhaps the function is designed to devert the prim to 0,0,0 during this process.  In most cases that would be an oout of the way location for it to sit and wait for the data to load.  

Going to 0,0,0 wouldn't seem to be such a bad thing if it were possible to blank the user's screen or something during the process.  But it is a bit unnerving for an unsuspecting avatar who expects to be teleported to a specific location to find themselves suddenly underwater or underground.  It will give the feeling of an error having happened and they may log out asuming a crash.

I should also not that there is not an issue with llSetRegionPos failing.  Of the 80 or so test teleports I've conducted over the last 3 days, only twice has the teleport failed to complete.  The avatar does make it to a lcoation within a few meters of the destination.  It is just a visually unpleasant process.

Here is the basic code segment I have been using.   Very basic and simple.  The llSleep command has been moved to various location and values in my tests so it can be ignored, this is just where it was on my last test.  Changing it to a 5 second delay at the current position often (not always) does work to stop the 0,0,0 problem.

{
	vector init_pos = llGetPos();
	llSetRegionPos(destination); // use llSetRegionPos function
	llSleep(0.2);
	llUnSit(user);
	llSetRegionPos(init_pos); // use llSetRegionPos function
}

I really appreciate all the responses an suggestions and comments.  Thank you all!  Keep brainstorming and making suggestions if you will, I will continue to test whatever pops into my feeble brain!

[LeafIllusion]

Another possible issue with llSetRegionPos:  After the teleporter prim returns to it's original location it sometimes becomes invisible to the avatar who just used it to teleport.  In other words, if you teleport then walk back to the original teleporter location the teleporter prim is not longer visisble.  Sometimes it is just "alpha" and can be sat on  although not visible.  Other times it is not even clickable.   It is visible and useable to other avatars, it is just the one that used it that can't see it.  I have only been able to duplicate this in the Second Life Viewer 3.3.4 and not in the current Firestorm.  Possibly a viewer issue?  I've not been able to find any other mentions of this in the forums.  Thought I would mention it since it showed up numerous times during my llSetRegionPos teleporter tests.  Anyone else noticed this one?

[Dora Gustafson Advisor]

I have made some more investigations and thinking about this problem. These are my conclusions so far:

1. The <0,0,0> problem is not caused by the function: llSetRegionPos,
   It is known with the warppos function as well and
   it can be shown easily that the prim is positioned instantly by llSetRegionPos
2. The problem is a "what you see" problem and must be related to the viewer and how the viewer repositions the camera when the location is totally shifted in 'no time'
3. It is claimed that the llSetRegionPos fail the target by several meters.
   I have never seen that and have no ideas about what it can be, but I would like to learn more

To see if the problem is camera related I made a script that places the camera before the teleporting.
This way the camera should be in place when the TP-prim arrives

Spoiler

// Minimized Teleporter script by Dora Gustafson, Studio Dora 2012
// using llSetRegionPos()
// v1.01 has cam control

vector homeVector;
vector targetVector = < 250, 250, 4090 >;
string sitter;
vector sitPos =  < 0.25, 0.0, 0.6 >; // sit position relative to the prim
rotation turnOnChair = ZERO_ROTATION; // the amount the avatar is rotated relative to the prim when seated
vector relCamP = <3.0, 0.0, 1.2>; // relative camera to prim position
vector relCamF = < 0.0, 0.0, 0.5 >; // relative focus to prim position

setCamPos( integer perms, vector focus )
{
    if ( perms & PERMISSION_CONTROL_CAMERA )
    {
        vector camPos = focus + (relCamP * llGetRot() * turnOnChair) ;
        vector camFocus = focus + relCamF ;
        llClearCameraParams();
        llSetCameraParams([
            CAMERA_ACTIVE, TRUE,
            CAMERA_FOCUS, camFocus,
            CAMERA_FOCUS_LOCKED, TRUE,
            CAMERA_POSITION, camPos,
            CAMERA_POSITION_LOCKED, TRUE
        ]);
    }
}

resetCamera( integer perms )
{
    if ( perms & PERMISSION_CONTROL_CAMERA )
    {
        llClearCameraParams();
        llSetCameraParams([ CAMERA_ACTIVE, FALSE ]);
    }
}

default
{
    state_entry()
    {
        homeVector = llGetPos();
        llSitTarget( sitPos, turnOnChair);
        llSetClickAction(CLICK_ACTION_SIT);
    }
    changed(integer change)
    {
        if (change & CHANGED_LINK)
        {
            sitter = llAvatarOnSitTarget();
            if ( sitter != NULL_KEY )
            {
                homeVector = llGetPos();
                llRequestPermissions( sitter, PERMISSION_CONTROL_CAMERA );
                llSetClickAction(CLICK_ACTION_TOUCH);
            }
            else
            {
                resetCamera( llGetPermissions() );
                llSetClickAction(CLICK_ACTION_SIT);
            }
        }
    }
    run_time_permissions(integer perm)
    {
        if ( perm & PERMISSION_CONTROL_CAMERA )
        {
            setCamPos( perm, targetVector);
            if (!llSetRegionPos(targetVector))
            {
                resetCamera( perm );
                llOwnerSay("Target is not accessible");
            }
        }
    }
    touch_end(integer num)
    {
        setCamPos( llGetPermissions(), homeVector);
        llSetRegionPos(homeVector);
    }
}

Note that the script has no llSleep function.
Note: To see the camera being positioned by the script the camera must be in default mode when you sit on the TP-prim(Press the Esc key first)

To me it looks like the visual experience is cleaner with this script but I can't tell if the approach works in places that have the <0,0,0> problem.

I would like to know the result if someone does test it