User:Haravikk Mistral/llTeleportAgent/Draft

From Second Life Wiki
Jump to navigation Jump to search

Overview

The llTeleportAgent() function is a much desired one in the scripting community, intended to allow scripted objects to initiate teleports on an avatar's behalf, surpassing the current solutions of using llMapDestination(), llSitTarget() or WarpPos. Potential uses include:

  • "True" in-sim teleports, allowing an avatar to be teleported anywhere within a region with no restriction on range other than those defined by the limits of the region's volume.
  • Rich global teleports, useful for moving to a new location without landmark passing, or teleport brokers such as the popular stargate networks.
  • Illusive building, allowing the creation of portal-like manipulation of space by permitting an avatar to walk through a door, and seamless appear from another that could be located elsewhere. For example; a home at ground level, upon entering teleports to the home's interior, located in a more private spot. TARDIS like effects, and so-on.

Implementation

LSL Function

The actual function specification is one of the simplest components: <lsl>llTeleportAgent(key avatar, string region, vector position, vector look_at);</lsl> Parameters

  • avatar - the key identifying the avatar to send a teleport request to.
  • region - the region/simulator to which the avatar would teleport. If provided an empty string ("") or the value of llGetRegionName() then this will produce a local (same-region) teleport.
  • position - the position within the target region to teleport to. A value less than 0.0 or greater than or equal to 256.0 for either of the x and y co-ordinates will result in a local teleport becoming a global one.
  • look_at - a position within the target region that the avatar will turn to look at upon completing the teleport, or already be looking towards on completion.

When invoked, the function simply sends a teleport request to the target avatar's SL viewer. This request will be based upon an extended version of the request used in llMapDestination(), causing older viewers to present the map, allowing backwards compatibility.

The scripted function would be throttled at 10 requests per 30 second period, allowing sustained calls of 1 per 3 seconds, or a burst of up to 10 requests. Values provided only as a guideline, and subject to change.

Viewer Behaviour

Once the viewer receives the request, it can decide whether to accept it, present the user with a dialogue, or reject it.

For the purposes of deciding how to treat the request there are two points of consideration:

  • Type of teleport:
    • Local - A teleport that will send the avatar to the same region that they are currently in.
    • Global - A teleport that will send the avatar to a different region from the one that they are currently in.
  • Type of object (from which the request originates):
    • Attachment - An object attached to the avatar that is to be teleported.
    • Land Owner - An object belonging to the owner of the parcel on which the avatar is currently located (see llOverMyLand() for details).
    • Others - All other objects.


Object Type Local Teleport Global Teleport Notes
Attachments Automatic Automatic It should be safe to allow automatic teleports for attachments, as attaching them is commonly considered to imply a degree of reasonable consent.
Land Owner Automatic Automatic The requirement for land ownership should be safe, as it greatly the reduces the potential for malicious use as it is not in the best interest of a vested party, as their land can be forfeited.
Others Dialogue Dialogue For non-privileged objects, a dialogue is always presented.

Objects permitted automatic teleport will result in the viewer immediately attempting to follow the teleport request, while those marked with Dialogue will produce a standard dialogue box.

Regardless of an object's type, all scripted teleport requests are throttled to 1 every 20 seconds within the viewer, to prevent flooding or an endless teleport trap.

Teleporting to…

The standard teleporting to dialogue will only appear for global teleports, and will include the standard Cancel button. In addition, it will include a Block button, which will cancel the teleport immediately, and provide options for adding either the object, or its owner, to the block-list. In the case of attachments, clicking Block will simply detach the offending attachment.

For automatic teleports it may be advisable to enforce a minimum time for global teleports, negotiating with the target region but pausing for at least 2 seconds before actually fulfilling the request, in order to provide opportunity to click Cancel or Block.

Teleport Dialogues

Requests that produce a dialogue will produce one similar to a teleport offer from an avatar, detailing the target location, and source of the request.

Options will include Accept, Reject, and Block.

Post-Teleport

After an avatar is teleported via scripted means, an entry will be added to their chat history, providing a link for where they were teleported from, as well as convenient links to block the source of the teleport, or file an abuse report.

Preferences

Only a single preference option should be required by the initial implementation, and this will allow all automatic teleports to be disabled, causing all such requests to produce a dialogue first.

Reference

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Haravikk_Mistral/llTeleportAgent/Draft&oldid=1148665"