Jump to content

llSetRegionPos teleporter problems


You are about to reply to a thread that has been inactive for 2956 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

That's a good point, Innula, but I'm not sure what differences might be significant, if any.  I have only been home for a couple of days now and am still digging out from under the stuff that accumulated while I was gone, so I haven't had time to study the problem carefully.  I am running Firestorm on a custom-built PC with XP and a GeForce 9800 GT GPU.  My ISP provides me with a 5 Mbps cable connection that is quite stable. I have ping times typically around 60 ms.  This system is not top of the line by any means, but I rarely have trouble with it -- hardly ever crash and have minimal lag -- so I hesitate to blame the machine.  Dora's script is failing for me because the at_target event isn't being triggered, but I haven't had time to figure out why, or to experiment with a workaround.  I'll get it, though.  Dora's approach is lovely, so I want to get it working here.

Link to post
Share on other sites

Lucky you:) I have ping times on 200 to 300mS (I live in Europe, far away from LL)

I took the script one step further, in the right direction I hope
It is the script without camera control so camera constraints has no influence

// Minimized Teleporter script by Dora Gustafson, Studio Dora 2012// using llSetRegionPos()// v1.01 has cam control// v1.02 with unsit. Use big flat TP-prim where avatar can stand after unsit. A 2.0x2.0x0.1 meter box will do// v1.03 camera control removed// v1.04 llTarget introduced// v1.06 Check for prim, camera and avatar in position// v1.10 compare relative positions to relative positions prior to tpinteger DEBUG = FALSE;vector homeVector;vector targetVector = < 56.0, 224.0, 4090 >;string sitter;vector sitPos =  < -0.5, 0.0, 1.5 >; // sit position relative to the primrotation turnOnChair = ZERO_ROTATION; // the amount the avatar is rotated relative to the prim when seatedinteger targId;vector ravPos;vector rcamPos;vector ravPos2;vector rcamPos2;float dAvPos = 0.01;float dCamPos = 10.0;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 )            {                if (DEBUG) llResetTime();                llRequestPermissions( sitter, PERMISSION_TRACK_CAMERA );                llSetClickAction(CLICK_ACTION_TOUCH);            }            else            {                llSetClickAction(CLICK_ACTION_SIT);                llTargetRemove(targId);                if (DEBUG) llOwnerSay("TP time: "+(string)llGetTime()+"S Deviation: "+(string)llVecDist( ravPos2, ravPos)+", "+(string)llVecDist( rcamPos2, rcamPos));            }        }    }    run_time_permissions(integer perm)    {        if ( perm & PERMISSION_TRACK_CAMERA )        {            ravPos = llList2Vector( llGetObjectDetails( sitter, [OBJECT_POS]), 0) - llGetPos();            rcamPos = llGetCameraPos() - llGetPos();            vector target = homeVector;            if ( llVecDist( llGetPos(), targetVector) > llVecDist( llGetPos(), homeVector)) target = targetVector;            if (llSetRegionPos( target)) targId = llTarget( target, 0.1);            else llOwnerSay("Target is not accessible");        }    }    at_target( integer tnum, vector targetpos, vector ourpos)    {    // This event will fire when the prim is on target and continue to fire untill llTargetRemove is executed    // check for prim, avatar and camera positions. UnSit when all are in place        integer inplace = tnum == targId;        ravPos2 = llList2Vector( llGetObjectDetails( sitter, [OBJECT_POS]), 0) - targetpos;        inplace = inplace && llVecDist( ravPos2, ravPos) < dAvPos;        if ( llGetPermissions() & PERMISSION_TRACK_CAMERA )        {            rcamPos2 = llGetCameraPos() - targetpos;            inplace = inplace && llVecDist( rcamPos2, rcamPos) < dCamPos;        }        if ( inplace )        {            llUnSit( sitter );            llTargetRemove(targId);        }    }    on_rez(integer param) { llResetScript(); }}

The values for float dAvPos = 0.01; and float dCamPos = 10.0; are based on measurements taken with DEBUG = TRUE;
If they become too small the avatar is not unseated.
Here are some of the measurements:

[11:15] Simple TP v1.10 no cam: TP time: 5.358257S Deviation: 0.000122, 0.946859[11:15] Simple TP v1.10 no cam: TP time: 5.360114S Deviation: 0.000000, 0.947637[11:16] Simple TP v1.10 no cam: TP time: 5.364861S Deviation: 0.000122, 0.947293[11:16] Simple TP v1.10 no cam: TP time: 1.553149S Deviation: 0.000000, 0.946075[11:16] Simple TP v1.10 no cam: TP time: 1.357945S Deviation: 0.000122, 0.945857[11:16] Simple TP v1.10 no cam: TP time: 5.335431S Deviation: 0.000000, 0.947409[11:16] Simple TP v1.10 no cam: TP time: 5.365803S Deviation: 0.000122, 0.946013[11:17] Simple TP v1.10 no cam: TP time: 5.362220S Deviation: 0.000000, 0.946091[11:17] Teleport completed from Nautilus - Suniaton (23,47,1280)toMagnum RC Sandbox 1[11:18] Simple TP v1.10 no cam: TP time: 5.291660S Deviation: 0.000099, 3.844394[11:18] Simple TP v1.10 no cam: TP time: 1.377621S Deviation: 0.000000, 0.601530[11:18] Simple TP v1.10 no cam: TP time: 1.421530S Deviation: 0.000099, 0.413688[11:18] Simple TP v1.10 no cam: TP time: 1.555970S Deviation: 0.000000, 0.413029[11:18] Simple TP v1.10 no cam: TP time: 1.508351S Deviation: 0.000099, 0.413475[11:18] Simple TP v1.10 no cam: TP time: 5.379225S Deviation: 0.000000, 0.666611[11:19] Simple TP v1.10 no cam: TP time: 5.287707S Deviation: 0.000099, 0.423405

The time it takes for a teleporting is monitored as well.
The time is unpredictable, but it looks like it is grouped around 1.5 seconds and 5.3 seconds.
5.3 seconds may seem much but in exchangeI I never saw the avatar go to <0,0,0> and it was never lost somewhere away from the destination

Link to post
Share on other sites

This variation works for me most of the time, Dora.  About one time out of ten, it still delivers me to the target location but does not follow me with the camera or unsit me, but nine times out of ten it works fine.  It never takes me to <0,0,0>.  This is a lot better than any teleporter I have ever built.

Link to post
Share on other sites

Here is the latest version of the teleporting script. Over version 1.10 it has:

  1. A Sit timeout with a default value: 6.5 seconds
    This means that the avatar will be unseated after 6.5 seconds no matter what
  2. A better and more simple test for the camera position
// Minimized Teleporter script by Dora Gustafson, Studio Dora 2012// using llSetRegionPos()// v1.02 with unsit. Use big flat TP-prim where avatar can stand after unsit. A 2.0x2.0x0.1 meter box will do// v1.04 llTarget introduced// v1.06 Check for prim, camera and avatar in position// v1.12 with DEBUG and a Sit timeoutinteger DEBUG = TRUE;vector homeVector;vector targetVector = < 56.0, 224.0, 4090 >;string sitter;vector sitPos =  < -0.5, 0.0, 1.5 >; // sit position relative to the primrotation turnOnChair = ZERO_ROTATION; // the amount the avatar is rotated relative to the prim when seatedinteger targId;vector rAvPos;vector rAvPos2;vector camDist;float dAvPos = 0.01; // metersfloat camMaxDist = 20.0; // metersfloat timeOut = 6.5; // Secondsdefault{    state_entry()    {        homeVector = llGetPos();        llSitTarget( sitPos, turnOnChair);        llSetClickAction(CLICK_ACTION_SIT);    }    changed(integer change)    {        if (change & CHANGED_LINK)        {            sitter = llAvatarOnSitTarget();            if ( sitter != NULL_KEY )            {                llResetTime();                llRequestPermissions( sitter, PERMISSION_TRACK_CAMERA );                llSetClickAction(CLICK_ACTION_TOUCH);            }            else            {                llSetClickAction(CLICK_ACTION_SIT);                llTargetRemove(targId);                if (DEBUG) llOwnerSay("TP time: "+(string)llGetTime()+"S deltaAv: "+(string)llVecDist( rAvPos2, rAvPos)+"m Cam distance: "+(string)llVecMag( camDist)+"m");            }        }    }    run_time_permissions(integer perm)    {        if ( perm & PERMISSION_TRACK_CAMERA )        {            rAvPos = llList2Vector( llGetObjectDetails( sitter, [OBJECT_POS]), 0) - llGetPos();            vector target = homeVector;            if ( llVecDist( llGetPos(), targetVector) > llVecDist( llGetPos(), homeVector)) target = targetVector;            if (llSetRegionPos( target)) targId = llTarget( target, 0.1);            else llOwnerSay("Target is not accessible");        }    }    at_target( integer tnum, vector targetpos, vector ourpos)    {    // This event will fire when the prim is on target and continue to fire untill llTargetRemove is executed    // check for prim, avatar and camera positions. UnSit when all are in place        integer inplace = tnum == targId;        rAvPos2 = llList2Vector( llGetObjectDetails( sitter, [OBJECT_POS]), 0) - targetpos;        inplace = inplace && llVecDist( rAvPos2, rAvPos) < dAvPos;        if ( llGetPermissions() & PERMISSION_TRACK_CAMERA )        {            camDist = llGetCameraPos() - targetpos;            inplace = inplace && llVecMag( camDist) < camMaxDist;        }        if ( inplace || llGetTime() > timeOut) // in place or timeout        {            llUnSit( sitter );            llTargetRemove(targId);        }    }    on_rez(integer param) { llResetScript(); }}

 

The teleporting times turn out to be in three groups: 0.7 seconds, 1.5 seconds and 5.3 seconds
I have no Idea how to predict the time

The script now looks very reliable, I have never seen it visit <0.0.0> and the script never dropped the avatar or left the avatar flying, walking or falling.

I am interested to learn about any functional error you may discover.

Note that the script is ment for testing and not for general use
Only the idea can be adopted in full teleporters

Link to post
Share on other sites

I just spent much of the morning testing my copy of the script.  If I increase the range in llTarget to 0.2, I can get my success rate over 90%, so that I arrive properly at the destination, with the camera, and am unseated.  I discovered mid-morning that I could apparently improve success rate by turning off Pathfinding for the sim (which cleared up a few other minor problems too --- I need to figure out why). 

Link to post
Share on other sites

I'm glad I found this because I was just about to start a thread about this.

It was at a specific point in time that I started having this problem.  You can read my comments and also see the script I use in this Server Release Notes Thread:

http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2012-06-18/m-p/1573109/highlight/true#M5887

I probably should have started a JIRA but Oskar never replied after I responded to his question.

Oddly enough, my problem with not hitting the target has gone away but I'm not certain when that straightened out.  But for me, it was distinctly at this time that this problem started.

Maybe there is a clue to this here.  It's above my ability to decipher.


ETA:  At that time, I didn't mention the 0.0.0 problem.  I was used to it occurring on rare occasions.  I didn't realize it was going to become the normal occurrence.

Link to post
Share on other sites


Qwalyphi Korpov wrote:

It appears that waiting for the camera to catch up with the AV/TP_prim before unsitting avoids the side trip to 0,0,0.  I've changed my scripts to wait until the camera is no more than one meter further away than it was to start.  Or 6 seconds - whichever comes first.

To compare camera positions before and after does not make much sense.

From the beginning I did that myself, but the start position vary very much with the your position, before you sit on the TP-prim.

Try stand close, like 2 meters and far away like 20 meters.

It doesn't help to read the camera position after you sit, because the camera moves softly and slowly and hasn't settled before you take off.

Fortunately it works better only to test the camera position after the teleporting.

In my latest version: Minimized Teleporter v1.12, llUnSit is executed when the camera is within 20 meters from the TP-prim and TP-prim and avatar are both in place.

Conditions for unsitting:

  1. The TP-prim is in place when the at_target event triggers
  2. The avatar is in place when it has same relative position to the TP-prim before and after the teleporting
  3. The camera is in place when the camera is within 20 meters from the TP-prim

I find that all three conditions must be fulfilled to secure a safe and fast trip:)

 

Link to post
Share on other sites


Qwalyphi Korpov wrote:


Perrie Juran wrote:

I'm glad I found this because I was just about to start a thread about this.

It was at a specific point in time that I started having this problem.  You can read my comments and also see the script I use in this Server Release Notes Thread:

I probably should have started a JIRA but Oskar never replied after I responded to his question.

Oddly enough, my problem with not hitting the target has gone away but I'm not certain when that straightened out.  But for me, it was distinctly at this time that this problem started.

Maybe there is a clue to this here.  It's above my ability to decipher.

 

ETA:  At that time, I didn't mention the 0.0.0 problem.  I was used to it occurring on rare occasions.  I didn't realize it was going to become the normal occurrence.

It appears that waiting for the camera to catch up with the AV/TP_prim before unsitting avoids the side trip to 0,0,0.  I've changed my scripts to wait until the camera is no more than one meter further away than it was to start.  Or 6 seconds - whichever comes first.  Works.  Kinda kills the efficiency gain that llSetRegionPos was supposed to provide.  Simply waiting 5.3 seconds is another fairly effective option.

Why it often takes the server over 5 seconds to move the camera a hundred meters is a puzzle to me.

Unfortunately your deploys of the week link didn't lead to any camera movement throttling clues.  Unless... maybe to rezz prims on the right parcel you have to move the camera really really slowly.

"Why it often takes the server over 5 seconds to move the camera a hundred meters is a puzzle to me."

Could it be related to Caching?  The prim moves so fast that the Server and Client are having trouble reconciling which information you need to see and what comes from your Cache and what the Server needs to send?

When you walk, fly, ride a vehicle, as I understand it the system predicts what information you will need.  When we use the teleport function like this, the system has no way to predict where we are going to end up.

Regardless, you would think it would respond faster.

In normal teleporting you see a teleport screen which in effect is hiding this 0.0.0 effect from your view.

Just thinking out loud here.

 

Link to post
Share on other sites


Qwalyphi Korpov wrote:


Perrie Juran wrote:



"Why it often takes the server over 5 seconds to move the camera a hundred meters is a puzzle to me."

Could it be related to Caching?  The prim moves so fast that the Server and Client are having trouble reconciling which information you need to see and what comes from your Cache and what the Server needs to send?

When you walk, fly, ride a vehicle, as I understand it the system predicts what information you will need.  When we use the teleport function like this, the system has no way to predict where we are going to end up.

Regardless, you would think it would respond faster.

In normal teleporting you see a teleport screen which in effect is hiding this 0.0.0 effect from your view.

Just thinking out loud here.

 

The process you're talking about makes sense to me.  The puzzle is that the new slower process happens with old viewers as well as new.  That indicates it's not a viewer change.  To me it seems that 'moving the camera' for all distances almost always took less than 0.5 seconds before.  Now for all but the shortest distances it's usually taking over 5 seconds.  Looks like the servers are providing the same infomation a lot slower than they once did.

 

This really does make sense to me.  In a normal teleport you tell the Server where you are going so it knows as soon as you tell it.  Very smooth Server to Viewer communication.

When we use a prim to TP the server knows instantly where the prim is going.  The delay is that the server doesn't know we are going to be moving with the prim.  For all practical purposes, the server loses track of where we are, hence the 0.0.0., and it is taking several seconds to figure it out.

But I also agree with you, why this process is NOW taking longer is a puzzle.  It really used to be almost instantaneous.

Might be a good riddle to poke Oskar with.

I won't suggest a JIRA because the current Fubar won't allow all of us to participate.

This is at least my best logic given my limited technical understanding.  Maybe somebody smarter than me will pipe in.

Link to post
Share on other sites

My aim is to find how to make a teleporting as fast as possible to the exact destination without the risk of visiting <0,0,0>
I don't know what your aim is, but from my viewpoint your result is not the best.

For Minimized Teleporter v1.12 I measured to day:

43 in 95 TPs are below 1.75 seconds, that equals 45 percent
50 in 95 TPs are below 5.00 seconds, that equals 53 percent

The figures you publish shows 4 percent below 5 seconds (1 in 23)

As I said I don't know what your goal is and I better not guess, you tell me:)

Link to post
Share on other sites

The difficulties with getting a valid camera position before teleporting is essential
so I thought: why not set it to a known relative position and compare that position to the camera position after teleporting?
I have tried with llSetCameraParams but that is only effective without camera constraints.
Now I tried with llSetCameraEyeOffset and llSetCameraAtOffset and that works with and without camera constraints.

// Minimized Teleporter script by Dora Gustafson, Studio Dora 2012// using llSetRegionPos()// v1.02 with unsit. Use big flat TP-prim where avatar can stand after unsit. A 2.0x2.0x0.1 meter box will do// v1.04 llTarget introduced// v1.06 Check for prim, camera and avatar in position// v1.12 with DEBUG and a Sit timeout// v1.13 set and check camera at new positioninteger DEBUG = TRUE;vector homeVector;vector targetVector = < 56.0, 224.0, 4090 >;string sitter;vector sitPos =  < -0.5, 0.0, 1.5 >; // sit position relative to the primrotation turnOnChair = <0.00000, 0.00000, -0.14673, 0.98918>; // the amount the avatar is rotated relative to the prim when seatedvector relCamP = <-2.3, 1.2, 1.8>; // relative camera to prim positionvector relCamF = < 0.0, 0.0, 1.3 >; // relative focus to prim positioninteger targId;vector rAvPos;vector rAvPos2;vector rCamPos;vector rCamPos2;float dAvPos = 0.01; // metersfloat dCamPos = 0.01; // metersfloat timeOut = 6.5; // Secondsdefault{    state_entry()    {        homeVector = llGetPos();        llSitTarget( sitPos, turnOnChair);        llSetCameraEyeOffset( relCamP * turnOnChair);        llSetCameraAtOffset( relCamF * turnOnChair);        llSetClickAction(CLICK_ACTION_SIT);    }    changed(integer change)    {        if (change & CHANGED_LINK)        {            sitter = llAvatarOnSitTarget();            if ( sitter != NULL_KEY )            {                llResetTime();                rCamPos = relCamP * llGetRot() * turnOnChair;                llRequestPermissions( sitter, PERMISSION_TRACK_CAMERA );                llSetClickAction(CLICK_ACTION_TOUCH);            }            else            {                llSetClickAction(CLICK_ACTION_SIT);                llTargetRemove(targId);                if (DEBUG) llOwnerSay("TP time: "+(string)llGetTime()+"S deltaAv: "+(string)llVecDist( rAvPos2, rAvPos)+"m deltaCam: "+(string)llVecDist( rCamPos2, rCamPos)+"m");            }        }    }    run_time_permissions(integer perm)    {        if ( perm & PERMISSION_TRACK_CAMERA )        {            rAvPos = llList2Vector( llGetObjectDetails( sitter, [OBJECT_POS]), 0) - llGetPos();            vector target = homeVector;            if ( llVecDist( llGetPos(), targetVector) > llVecDist( llGetPos(), homeVector)) target = targetVector;            if (llSetRegionPos( target)) targId = llTarget( target, 0.1);            else llOwnerSay("Target is not accessible");        }    }    at_target( integer tnum, vector targetpos, vector ourpos)    {    // This event will fire when the prim is on target and continue to fire untill llTargetRemove is executed    // check for prim, avatar and camera positions. UnSit when all are in place        integer inplace = tnum == targId;        rAvPos2 = llList2Vector( llGetObjectDetails( sitter, [OBJECT_POS]), 0) - targetpos;        inplace = inplace && llVecDist( rAvPos2, rAvPos) < dAvPos;        if ( llGetPermissions() & PERMISSION_TRACK_CAMERA )        {            rCamPos2 = llGetCameraPos() - targetpos;            inplace = inplace && llVecDist( rCamPos, rCamPos2) < dCamPos;        }        if ( inplace || llGetTime() > timeOut) // in place or timeout        {            llUnSit( sitter );            llTargetRemove(targId);        }    }    on_rez(integer param) { llResetScript(); }}

I haven't had time to make a thorough testing but it looks like this script is not performing worse than its' predecessor

Link to post
Share on other sites
  • 2 weeks later...
  • 4 months later...

I hadn't checked on the 000 problem in a while, and was messing around yesterday and noticed I couldn't reproduce it.  Tried in 3 different regions using a teleporter script that produced the problem in the past.  Did a quick search of recent viewer and server release notes, but didn't see any references to llSetRegionPos (I admit I was lazy and didn't read each note.)  

Does anyone know if the 0,0,0 issue with llSetRegionPos has been fixed?  Is anyone still having problems with 0,0,0 displaying when using llSetRegionPos?  

Oh, I should also say thanks to everyone who has helped me and provided input on this!

Link to post
Share on other sites
  • 1 month later...
You are about to reply to a thread that has been inactive for 2956 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...