Talk:LlTeleportAgent

Alternate version for freaky future-proofness

en:Talk:LlTeleportAgent

Template:Needs Translation/LSL/de Template:Needs Translation/LSL/es Template:Needs Translation/LSL/el Template:Needs Translation/LSL/fr Template:Needs Translation/LSL/he Template:Needs Translation/LSL/it Template:Needs Translation/LSL/ja Template:Needs Translation/LSL/ko Template:Needs Translation/LSL/nl Template:Needs Translation/LSL/hu Template:Needs Translation/LSL/no Template:Needs Translation/LSL/da Template:Needs Translation/LSL/sv Template:Needs Translation/LSL/tr Template:Needs Translation/LSL/pl Template:Needs Translation/LSL/pt Template:Needs Translation/LSL/ru Template:Needs Translation/LSL/th Template:Needs Translation/LSL/uk Template:Needs Translation/LSL/zh-Hans Template:Needs Translation/LSL/zh-Hant

/LSL

TeleportAgent

Talk:llTeleportAgent

	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 Captain");
    }
}

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)

Honestly I don't like that they have mixed both the intra-region and the landmark teleporter into the same function. It makes the documentation harder to write.

Ack, okay so I've over-reacted a bit having missed the other function. Even so, I don't see any need to have a landmark based function, and the coords function is still pretty unwieldy; if you need to use an llRequest* function to fetch necessary data, then there's something very wrong with the implementation! The permissions issue is still backwards; receiving of teleports is already in the viewer from other users, there's simply no need for server-side permissions to handle teleports, as the viewer can easily decide whether to automatically allow or deny a request, and it gives users the control they desire. The new experience permissions will help but there's just no need for them in this case, plus in the viewer it'd be possible to easily ignore requests that come too soon after the last. I just don't like anything about this implementation when we had a clear, and already exhaustively discussed solution proposed.
-- Haravikk ^{(talk|contribs)} 08:36, 30 May 2012 (PDT)

I think the permission is so you can grant them to an attachment so it can TP you (send you back to town when diablo smites you sort of thing). It's a good solution for Linden Realms, not so good for the rest of us. -- Strife ^{(talk|contribs)} 15:43, 30 May 2012 (PDT)

Only works for the owner?

Where does the information that this only works for the object's owner come from? That appears to be new restriction, and one that makes the function pretty pointless. Innula Zenovka 17:08, 17 July 2012 (PDT)

It is a new restriction, it came after the botched roll-out. -- Strife ^{(talk|contribs)} 11:14, 18 July 2012 (PDT)

Does this not effectively render the function largely useless, or is it simply to prevent abuse while problems are fixed? i.e - is it restricted to the object owner only for testing purposes?
-- Haravikk ^{(talk|contribs)} 12:47, 18 July 2012 (PDT)

I'm not in the loop, I just aggregate. -- Strife ^{(talk|contribs)} 20:14, 18 July 2012 (PDT)

The current description of functionality in the caveats is wrong, but I can't for the life of me find the text to edit it. Says that If landmark is not an empty string and... landmark is missing from the prim's inventory or it is not a landmark then it fails silently. That was true, but with the implementation of https://jira.secondlife.com/browse/SCR-342 It now gives a script error: "Teleport failed: landmark name provided but assets is missing or invalid." If someone can figure out how to edit that comment, please do so. Darien Caldwell 16:39, 18 July 2012 (PDT)

It's a template flag. I've disabled it. -- Strife ^{(talk|contribs)} 20:14, 18 July 2012 (PDT)

Throttle

There appears to be a throttle on this function similar to playing sounds. Calling it 2 times in a few seconds yields: "Too many llTeleportAgent requests. Throttled until average falls." Does anyone know the specifics?

----Gregory Maurer 19:20, 31 July 2012 (PDT)

I don't see any Jira's mentioning a throttle for llTeleportAgent (other than unacknowledged feature suggestions). Maybe open a new Jira for it? -- Strife ^{(talk|contribs)} 10:55, 1 August 2012 (PDT)

Caveats: BUG 4062(or equivalent) Fixed?

This bug has been closed and reopened under different numbers several times, I think, but -- at least as I understand it -- it was finally fixed in RC Magnum 14.04.16.289178. Presumably that was rolled out for the whole grid shortly thereafter, but I'm afraid I haven't checked. Innula Zenovka 08:51, 23 June 2014 (PDT)

It was fixed as SCR-382 which became BUG-5533. There are no new JIRA reports of dead scripts after teleport since then. --ObviousAltIsObvious Resident 09:32, 23 June 2014 (PDT)

These days, isn't it easier to use secondlife:///app/teleport/region/x/y/z ?

Even some scripts here on the LSL Library just spew out secondlife:///app/teleport/region/x/y/z and let the user click on it; as of 2022, you even get a chance to directly teleport to the link or see it on the World Map first.

Aye, I know, it's incredibly clunky, but almost as clunky as asking permissions to the object owner before doing a teleport (which, taking into account that the owner will be the only person to be able to use the teleporter, really makes absolutely no sense at all)...

Y I'd vote to mark this function as well as llMapDestination as deprecated and obsolete, and get rid of them!

— Gwyneth Llewelyn (talk) 13:50, 1 October 2022 (PDT)

Just because you can't figure out uses, doesn't mean there aren't. Remember that a script holds the permissions indefinitely once granted. This function allows you, for example, to make a destination HUD with pictures and whatnot; the HUD would ask for permissions only once. We're also using it (also with a HUD that only asks for permissions once) to simulate entering or exiting a cave where there's no physical room for one; the user is teleported to the entrance without clicking anywhere, giving a kind of seamless experience. Chat links are no substitutive for that usage at all. --Sei Lisa (talk) 23:50, 2 October 2022 (PDT)

I stand corrected. Aye, I see how this may be useful for HUDs, as well as for {{Experiences}}. I'd call it llRestrictedTeleportAgent() then... just to explain that it does have the desired functionality, but it can only work on very specific cases. Mind you, I'm not saying that the function isn't useful just because I have no use for it :-) Rather, that this function (as well as llMapDestination) have limited, clunky behaviour, which are only useful in very specific scenarios, for which equivalent functionality already exists in a form or another. Granted, I also know that LL will make a serious effort to avoid breaking existing scripts which have a legitimate need for the function, so it's quite unlikely that my sarcastic 'vote to remove the function' would never be addressed anyway. — Gwyneth Llewelyn (talk) 10:31, 11 February 2023 (PST) (currently playing around with llSetRegionPos instead of using a teleporter...)