View source for Talk:LlTeleportAgent

== Alternate version for freaky future-proofness ==

{{LSL_Function|func_id|mode=request|func_sleep=0.1|func_energy=10.0|func=llTeleportAgent|sort=TeleportAgent|p1_type=list|p1_name=parameters||func_desc=[[User:SignpostMarv Martin|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
|return_text=(integer) success|spec|caveats=* 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:
<pre>
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.");
        }
    }
}</pre>
Star-Trek style teleportation (works on script owner's land only):
<pre>
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");
    }
}
</pre>
|}}

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.
[[User:SignpostMarv Martin|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. -- [[User:Strife Onizuka|Strife Onizuka]] 08:11, 28 April 2007 (PDT)
::This function doesn't exist, so that rule doesn't apply.
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 08:48, 28 April 2007 (PDT)
::: Internally, the llTeleportAgent project's # is SL-13078. --[[User:Torley Linden|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]]). -- [[User:Strife Onizuka|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 ^^ <br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 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? --[[User:Nexii Malthus|<span style="color: #111; text-shadow:-1px -1px #ddd, 1px 1px #888;">Nexii Malthus</span>]] 17:23, 4 November 2011 (PDT)
:Ah, okay, they are working on it, it is indeed currently limited. --[[User:Nexii Malthus|<span style="color: #111; text-shadow:-1px -1px #ddd, 1px 1px #888;">Nexii Malthus</span>]] 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.<br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 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. -- [[User:Argent Stonecutter|Argent Stonecutter]] 03:30, 30 May 2012 (PDT)

:Without landowner or estate owner waivers it is not very useful. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 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![[User:Adeon Writer|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. --[[User:Cerise Sorbet|Cerise Sorbet]] 19:56, 29 December 2011 (PST)

::Cool. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 09:36, 31 December 2011 (PST)

== Why Even Bother Implementing this? ==

The currently proposed implementation ([https://wiki.secondlife.com/w/index.php?title=LlTeleportAgent&oldid=1167818 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 [[User:Haravikk_Mistral/LlTeleportAgent|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:


{| {{Prettytable|style=margin: 0px 0px 10px 1pt;}}
|-
! Feature !! [[LlTeleportAgent|Linden Proposal]] !! [[User:Haravikk_Mistral/LlTeleportAgent|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:

{| {{Prettytable|style=margin: 0px 0px 10px 1pt;}}
|-
! Use-Case !! Description !! [[LlTeleportAgent|Linden Proposal]] !! [[User:Haravikk_Mistral/LlTeleportAgent|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.
<br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 03:25, 30 May 2012 (PDT)

:The asset retrieval aspect is covered by [[llTeleportAgentGlobalCoords]]. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 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.<br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 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. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 15:43, 30 May 2012 (PDT)