Teleport Script question

[RavenSwarmsTheMountain]

So, as far as I know, there isn't any way in SL to have a teleport system that works where the destination, and/or departure point, are in motion. A Visual:

A sphere-shaped arena, spectator seating in the center, in a shaped enclosed area, floating. The action, as it were, all around. Outside the sphere(outer face is transparent)is the classical seating arrangement for any arena, except in enclosed shapes and said shapes are in motion. To access said shapes, a teleport pad, linked system style. 

The problem:As far as I know, TP-ing requires static coordinates, on the X, Y, Z axis'. If a teleport pad is in motion, the only 2 outcomes I see are, 1)TP doesn't work, because the destination pad isn't at a given set of coordinates(timing *might* fix this, but super split second, given the imagined speed of rotation), the TP process isn't started, error message occurs etc. 2)TP is completed but traveler arrives where the pad *was*at moment TP started, but isn't arriving where the destination pad currently*is*. 

Unless there's something I'm missing, either in that there's a TP-follow hybrid script(arrive and as you rez in follow the pad so fully rezzed where the pad is), or maybe a TP-movelock hybrid(arrive and attach to arrival pad until fully rezzed/walk your avatar away) I'm at a loss as to how I can acquire a script to make this possible. Also whether it's worth making the arena exactly as I envision it.

Please note: I have the very barest of knowledge of scripting; I know how to edit a rotation script to make it rotate on a different axis, or reverse the direction(clockwise to counter clockwise, vice-versa). I know barely anything else, my style of learning is copycat-ing so I'm very unlikely to ever stumble onto something new by myself.

Edited March 24, 2019 by RavenSwarmsTheMountain

[Rolig Loon]

If you plant a receiving prim at the destination, you could certainly ping it with llGetObjectDetails(target_object,[ OBJECT_POS])  (or simply ask it, "Where are you?") in the instant before your teleport. There's a tiny lag when you teleport, but unless the target is moving pretty fast, you should land close enough to be graceful.  I'm tempted to give that a try when I get home in an hour or so.  That's most likely to work if you are teleporting within the same region.  I doubt that you'd have any success teleporting to another region.

[Wulfie Reanimator]

I'm having a little trouble visualizing the construct you've described (and its behavior), but on a very abstract level, you can always ask the other object where it is (like Rolig said) and depending on how things are being moved, you can predict where the other pad be by the time the teleport happens. (For example, if the pad is moving in a circle at X degrees per second, you can use the center of the circle and its radius, combined with the rotation speed to calculate where the avatar should be teleported instead of the pad's immediate location.

But as this is a fairly abstract explanation and I'm assuming the arena doesn't exist either, I'm not going to try to write an example.

[Lucia Nightfire]

Also, teleporting does not maintain the target's initial velocity. Velocity is lost.

If you are trying to emulate someone moving through a portal without loss of velocity, there are a number of ways to fake it such as with movetotarget/force/push attachments, running-into/running-out-of animations or if scripted sitting is used, "in-place" running/walking/flying animations with moving sit objects on entry and exit.

 

 

[RozWright]

2 hours ago, RavenSwarmsTheMountain said:

A sphere-shaped arena, spectator seating in the center, in a shaped enclosed area, floating. The action, as it were, all around. Outside the sphere(outer face is transparent)is the classical seating arrangement for any arena, except in enclosed shapes and said shapes are in motion. To access said shapes, a teleport pad, linked system style. 

This may be anti-climactic (given some of the other, more sophisticated, solutions here), but if you're teleporting to a moving "seated area" the easiest way to pull it off is the lowly sit script (without the llUnSit).  Sit targets can take you places that llSetRegionPos cannot.  I've used simple sit scripts to put avis in circling planes, let avis drive and ride in speedboats patrolling outside the parameters of "island" sims (182 meters is the magic number to barely scrape your boat on the corners of a sim), and allowed avis to teleport to neighboring parcel skyboxes where Object Entry permissions slapped warPos travelers out of the sky.  If your floating skybox seats are orbiting an axis, you can texture your axis to appear stationary and then use that axis as an entry point to seat spectators.

The drawback is that the spectator will be seated immediately and abruptly, and for movement you'd need an axis prim that can be easily accessed by the spectators (within the 54 meter limit...as the patrol boat trick requires one avi actually wearing the boat as an attachment).  But it's a simple solution that will place avi's exactly where they need to be.

Edited March 25, 2019 by RozWright

[Rolig Loon]

OK, here's a quickly scripted teleporter that works for TPs to a moving destination in the same region. It's not prettied up -- just a demo of the concept.  The teleport script itself is like any other sit TP script.  You sit on the object that contains the script, it moves to the target location, and it unseats you.  The difference here is that you click the unit first to establish communication with the target destination. Clicking sends your UUID to the target and activates a fast repeating sensor in it.  The script in the destination target therefore knows that you are coming and seats you instantly when you are detected within 20m.  Performing that final trick requires using llRequestExperiencePermissions .  If you don't have access to an Experience on your region, therefore, the teleporter can't seat you automatically.  You have to be nimble enough to do it manually.  Still, this system will get you to the moving destination.

// This script is in the teleport object....

integer iChan = -12943728;
vector vHOME;
key iTargetID;

default
{
    state_entry()
    {
        llListen(iChan,"","","");
        vHOME = llGetPos();
        llSitTarget(<0.5,0.0,0.1>,ZERO_ROTATION);
    }
    
    touch_start(integer num)
    {
        llRegionSay(iChan, (string)llDetectedKey(0));	// Ping the target destination to set up communication
    }
    
    listen (integer channel, string name, key id, string message)
    {
        // Confirmation ping from the target destination
        iTargetID = id;
        llSay(0,"Target destination located.  Sit to teleport.");
    }
    
    changed (integer change)
    {
        if(change & CHANGED_LINK)
        {
            if(llAvatarOnSitTarget())
            {
          		// Here's the target's location at this instant
                vector vTargetPos = llList2Vector(llGetObjectDetails(iTargetID,[OBJECT_POS]),0);
                llSetRegionPos(vTargetPos + <0.0,0.0,0.5>);		 // Go there
                llSleep(0.1);	//OK, you might not really need to have a delay.
                llUnSit(llAvatarOnSitTarget());
            }
            else
            {
                llSetRegionPos(vHOME);	// Send the TP unit home again
            }
        }
    }
}

 

//  This script is in the target destination object

integer iChan = -12943728;
key kAv;

default
{
    state_entry()
    {
        llSitTarget(<-0.3,-0.2,0.15>,llEuler2Rot(<0.0,0.0,75.0>*DEG_TO_RAD)*llGetRot());
        llListen(iChan,"","","");
    }

    listen (integer channel, string name, key id, string message)
    {
        kAv = (key)message;	// Incoming message from the TP unit
        llRegionSayTo(id,iChan, "Ping");	// Confirmation response
        llSensorRepeat("",kAv,AGENT,20.0,PI, 0.2);	// Start a fast repeating sensor
        llSetTimerEvent(10.0);	// Start a timeout timer
    }
    
    timer()
    {
        llSensorRemove();	// Turn off the sensor after 10 seconds.  
        llSetTimerEvent(0.0);
    }
    
    sensor( integer num)
    {
        llRequestExperiencePermissions(kAv,"");	// Request permission to handle kAv
        llSensorRemove();	// Kill the sensor
    }
        
    experience_permissions( key Av)
    {
        llSitOnLink(Av, LINK_THIS);	// Force seating on the destination object.
    }
}

 

Edited March 25, 2019 by Rolig Loon

[Fenix Eldritch]

I like Rolig's approach with direct seating via the experience scripted sit commands. Out of curiosity, is there distance limit to how far away llSitOnLink can pull target avatars from? If there isn't, then we might be able to further simplify the example and omit the need to have the avatar sit on the departure prim, move it, and have the destination prim scan for the freshly moved avatar. Instead, you might be able to just relay the avatar's key to the destination script, and have it directly seat them in one swoop.

I imagine it could be something like this (rough sequence) :

1. user interacts with the departure prim, confirms they want to "teleport"
2. departure prim sends user key to destination script
3. destination script does some internal checks to verify it has an unoccupied target link to receive the user
4. if so, destination script can just call llSitOnLink targeting the user and desired link
5. else report back no seating available

[Rolig Loon]

I'm not aware of a distance limit,  so that's not a bad idea.  It's at least worth an experiment. It's an Experience-based version of the solution that Roz suggested (which does have a distance limit).

OK, a simple experiment:

// This script goes into the distant target that you want to sit on

default
{
    state_entry()
    {
        llListen( -1234567,"","","");
        llSitTarget(<0.0,0.0,1.0>,ZERO_ROTATION);
    }

    listen(integer channel, string name, key id, string message)
    {
        key kAv = (key)message;   /// Receive the av's UUID from the sending unit
        llRequestExperiencePermissions(kAv,"");
    }
    
    experience_permissions(key Av)
    {
        llSitOnLink(Av, LINK_THIS);
    }
}

And a dirt simple sending unit ...

default
{
    touch_start(integer num)
    {
        llRegionSay(-1234567,(string)llDetectedKey(0));  // Send the av's UUID to the destination target
    }
}

I have just experimented by putting the sending unit on the ground and the receiving unit at various heights, up to 4000 m.  I'm seated instantly every time.  No distance limit, as long as I stay in the region, even if I place the receiving unit in a fast-moving target.
 

 

Edited March 25, 2019 by Rolig Loon
typos. as always.