Talk:llTeleportAgent

From Second Life Wiki
Jump to navigation Jump to search

Alternate version for freaky future-proofness

Emblem-important-yellow.png LSL Feature Request
The described function does not exist. This article is a feature request.

Summary

Function: llTeleportAgent( list parameters );
0.1 Forced Delay
10.0 Energy

SignpostMarv Martin's freaky future-proofed multi-purpose take on llTeleportAgent.

  • TELEPORT_AGENT,(key) id - the key of the Resident you wish to teleport (required, also signals the start of a subset in batch queries- see the second example)
  • TELEPORT_REGION,(string) region - the name of the region you wish to send TELEPORT_AGENT to (if missing, defaults to current region)
  • TELEPORT_POSITION,(vector) position - the destination you wish to send TELEPORT_AGENT to, specified in local co-ordinates (if missing, defaults to <128.0, 128.0,0.0>)
  • TELEPORT_FOCUS,(vector) focus - is intended to focus the avatar's attention on a location, specified in local co-ordinates (if missing, defaults to TELEPORT_POSITION)
  • TELEPORT_PERMISSION_REQUIRED, (integer) boolean - supply either TRUE or FALSE (defaults to FALSE)
  • TELEPORT_LOGINURI, (string) uri - if specified, restarts the client as if called with -url secondlife://region/x/y/z/ -loginuri TELEPORT_LOGINURI (not required, if missing doesn't do anything)
  • TELEPORT_VALIDATE_ONLY (integer) boolean - if set to TRUE, the function only returns whether or not the supplied parameters are valid
• list parameters

Caveats

  • This function causes the script to sleep for 0.1 seconds.
  • TELEPORT_AGENT must be the script owner or must be on script owner's land.
  • If TELEPORT_AGENT is not on the script owner's land, PERMISSION_TELEPORT must be granted and TELEPORT_PERMISSION_REQUIRED is ignored/defaults to TRUE
  • Aside from TELEPORT_AGENT, the order of parameters within a subset does not matter. Only the last TELEPORT_VALIDATE_ONLY in the list is processed

Examples

Single-user teleportation: 

teleport_to_ahern(key id)
{
    llTeleportAgent([TELEPORT_AGENT,id,TELEPORT_REGION,"Ahern"]);
}
default
{
    touch_start(integer touched)
    {
        if(llDetectedKey(0) == llGetOwner()) // Not sure of the correct way to handle things on deeded land
        {
            teleport_to_ahern(llDetectedKey(0));
        }
        else
        {
            llRequestPermissions(llDetectedKey(0),PERMISSION_TELEPORT);
        }
    }
    run_time_permissions(integer perms)
    {
        if(perms & PERMISSION_TELEPORT)
        {
            teleport_to_ahern(llGetPermissionKey());
        }
        else
        {
            llWhisper(0,"Teleportation permissions must be granted.");
        }
    }
}

Star-Trek style teleportation (works on script owner's land only): 

vector transporter_size = ZERO_VECTOR;
vector transporter_pos = ZERO_VECTOR;
key caller = NULL_KEY;
integer n = 0;
list away_team = [];
list calibration = [TELEPORT_REGION,"Ahern"];
vector destination = <128.0,128.0,0.0>;
default
{
    state_entry()
    {
        transporter_size = llGetScale();
        llListen(1,"",NULL_KEY,"Beam me up Scotty");
    }
    listen(integer channel,string name,key id,string message)
    {
        caller = id;
        llSensor("",NULL_KEY,AGENT,transporter.x/2.0,PI_BY_TWO);
    }
    sensor(integer sensed)
    {
        llWhisper(0,"Energising");
        n = 0;
        while(n < sensed)
        {
            away_team = (away_team=[]) + away_team + [TELEPORT_AGENT,llDetectedKey(n)] + calibration + [TELEPORT_POSITION,llDetectedPos(n) - transporter_pos];
            ++n;
        }
        llTeleportAgent(away_team);
        away_team = [];
    }
    no_sensor()
    {
        llInstantMessage(caller,"I canee do it Captin");
    }
}

Deep Notes

Signature

//function void llTeleportAgent( list parameters );


Just a note, my take on the function returns a bitfield containing any errors in execution.

  • TELEPORT_ERROR_REGION_UNREACHABLE- would be used if the sim is offline, non-existant, teleporting to that region is disabled etc.
  • TELEPORT_ERROR_INVALID_URI- would be used when the login URI is either malformed, blacklisted or not whitelisted at the estate or parcel level
    • If TELEPORT_LOGINURI has been disabled entirely at the estate or parcel, this is also returned.
    • White/Blacklisting would be useful for Residents with places on multiple grids to prevent griefers from putting a prim over their kiosk to redirect them to a phishing site.
  • TELEPORT_INVALID_AGENT- would be used if the agent is not online, or not in the current sim. Or obviously, if the value passed along with TELEPORT_AGENT wasn't a valid UUID :-P

(it'd be nice if someone tweaked the template to have the correct parameters for the return stuffages based on these notes)

I'm thinking that for batch queries, the ordering restrictions should be relaxed a bit to allow for optimisation- e.g. any params specified before the first TELEPORT_AGENT set the defaults for the entire list. SignpostMarv Martin 19:54, 27 April 2007 (PDT)

LL will never change the parameters of a function as it would break existing script and lead to confusion. Request a new function. -- Strife Onizuka 08:11, 28 April 2007 (PDT)
This function doesn't exist, so that rule doesn't apply.
SignpostMarv Martin 08:48, 28 April 2007 (PDT)
Internally, the llTeleportAgent project's # is SL-13078. --Torley Linden 14:28, 30 April 2007 (PDT)
OMG I'm sorry for jumping on you I seriously thought there was a function in existence with this name (think it was confusing it with llTeleportAgentHome). -- Strife Onizuka 14:45, 30 April 2007 (PDT)
While a nice idea I think the function as already described is fine, just needs to be actually implemented, you know, before the world ends ^^
-- Haravikk (talk|contribs) 11:25, 14 October 2010 (UTC)



Was recently implemented

The function here (not the freaky one above, the original desired implementation) was recently implemented and seems to be recognised. Albeit disabled? --Nexii Malthus 17:23, 4 November 2011 (PDT)

Ah, okay, they are working on it, it is indeed currently limited. --Nexii Malthus 20:54, 4 November 2011 (PDT)
Limited in what way? The limitations described on the function's page are all reasonable, but I dread there being unreasonable limitations that render the function pointless.
-- Haravikk (talk|contribs) 04:08, 5 November 2011 (PDT)

Automatic permission grants?

Without some kind of automatic permission grants (to landowner and attachments, at least) the only advantage this has over llMapDestination is that it doesn't require one click, and (as noted below) it's more limited in other ways. Even for intra-region teleports the existing WarpMove and PosJump hacks are more useful. There were comments by Lindens that such grants were going to be included, but there's no mention of them on this page. -- Argent Stonecutter 03:30, 30 May 2012 (PDT)

Without landowner or estate owner waivers it is not very useful. -- Strife (talk|contribs) 08:10, 30 May 2012 (PDT)

Using this to Rotate Avatars

Another often requested feature is the ability to rotate avatars. I'm very curious if teleporting an avatar to it's current position in the current sim but with a different lookat would effectively rotate it. Teleports often hang or fail when attempting to teleport short distances, so I hope this would work - unless there's going to be a more formal way to rotate avatars. We don't have one!Adeon Writer 18:36, 29 December 2011 (PST)

Apparently it can do that, or something very close. It helps to have the minimap on rotate to see this example in action -- When you walk through a Linden Realms portal, you are sent to a spot in the air just above a transparent llVolumeDetect prim. On collision with the prim, you can see that your avatar is spun around to face the workshop on landing. There is still a bit of a fall after this so it's maybe not strictly a teleport to the same spot, but the rotation part seems to be working OK inside the same region.
Forgot to add -- It is not clear from the LR implementation if the rotation thing is possible across regions or not. The portals rely on landmarks, so they don't have enough data to set it on that end. --Cerise Sorbet 19:56, 29 December 2011 (PST)
Cool. -- Strife (talk|contribs) 09:36, 31 December 2011 (PST)

Why Even Bother Implementing this?

The currently proposed implementation (at time of writing) is a function apparently has ignored every word of the (lengthy) discussion upon the subject. I'm posting to complain that far better proposals have been completely ignored, and wish to strongly request that this proposed function be implemented instead, so that we might actually have a useable function.

Let's take a quick comparison of the current proposal versus the one that was requested years ago:


Feature Linden Proposal Original Proposal
Co-ordinates Uses static landmark requiring landmark creation, cannot be changed dynamically and requires asset retrieval. Uses region name and co-ordinates as per LlMapDestination, which can be changed dynamically by script.
Permissions Uses inflexible script permissions system, requiring a dialogue in most common cases. Allows the viewer to accept/decline teleport requests, allowing any mixture of automatic, dialogue-based or disabled teleport requests. Potentially allowing for different behaviour for objects on owner's land, friend's objects etc.
Implementation Entirely new function with new permissions request and asset retrieval before teleport. Uses existing llMapDestination implementation extended with a single bit to specify a teleport request.

And this is me being generous, and the result is pretty damning. There is literally no advantage to the Linden proposal. Hell, consider some simple cases:

Use-Case Description Linden Proposal Original Proposal
Object Relay By far the simplest system in use today, an object-relay allows an avatar to teleport between tele porters. For example from one on the ground to one in a skybox. Requires each object in a simple teleport relay to contain a landmark (or have a list of keys) for all the other objects in the relay so that they can be selected as a teleport destination. Customer use-case; place tele porters, create landmark for each one, place set of landmarks into each teleport (excluding the one for the tele porter you're editing), use tele porters. Can use messaging or object keys (if local) to dynamically maintain a list of active teleport relay points, and use this information to determine where to teleport the avatar. This allows a relay to be setup by anyone simply by placing the objects, and can update dynamically if the relay is changed. Customer use-case; place tele porter objects, use tele porters.
Teleport Broker Commonly used by merchant stalls to direct avatars to their main store, but also useful for sending people to popular clubs or other useful locations. Requires each broker to contain a landmark (or have a list of keys) for each location that a user might wish to teleport to. If a location is to be added then a new landmark must be created, so too if a destination is relocated, requiring landmarks to be replaced. Can simply grab data from a messaging service (such as a website), which can be trivially updated without requiring the creation of a landmark.
Infinite corridor More interesting case, but a simple corridor that appears to go on forever using some visual trickery. When the avatar reaches a certain "end" point they are teleported invisibly back to the "start" to continue onwards. Requires creation of landmarks for the start and end points, such that if the corridor is moved it will stop working. If more than one avatar is using the corridor then they will both be given permissions dialogues every time the corridor loops. End points of the corridor can dynamically link to one another, allowing the corridor to be relocated at will. Teleportation is seamless (if in same region) and requires no dialogue unless viewer uses more restrictive than normal settings.

There is literally no advantage to the Linden proposed system, other than the fact it doesn't require them to read or acknowledge the feature that was actually requested by their users.
-- Haravikk (talk|contribs) 03:25, 30 May 2012 (PDT)

The asset retrieval aspect is covered by llTeleportAgentGlobalCoords. -- Strife (talk|contribs) 08:10, 30 May 2012 (PDT)
Retrieved from "https://wiki.secondlife.com/w/index.php?title=Talk:LlTeleportAgent&oldid=1167827"