This is a suggestion for a llTeleportAgent() implementation alternative to SVC-212. I've been giving this a lot of thought, trying to take into consideration ways the SVC-212 method could be abused and what would be the easiest method to implement for LL. I'll go over my observations of the current teleport request used by avatars (Which I think would be the best method to mimick) and how I came to the conclusions I did for this suggestion now. llTeleportAgent(key user, string message) Sends a teleport request from an object to a user similar to one sent by an avatar, the message variable is the descriptive request used in the popup. The popup will say "[Object Owner Name]'s [Object Name] has offered to teleport you to it's location:" followed by the message variable (Or if none entered "Join me in [Sim Name]). Button options on the popup the target user receives include "Teleport", "Cancel", and "Mute". Agents would teleport in offset from the requesting object by +1 meter on the X axis (Or whatever it is the current teleport system uses, ideally using the same code to make this addition less work), request positions can come from child or root prims and use the coordinates of the prim the object is in to calculate the landing point. TeleportAgent() can be triggered by a collision_start event or touch only, however a script can only send out 10 requests within 10 minutes time (The time of the first request being the limiter). ... Server side requirements to implement include two new database fields for scripts, both integer values which are exceptionally low load on a MySQL database. One would be for a simple value between 0-9 to represent how many teleport requests a script has sent out (We'll call this integer field "tp_requests"). The second value would be for a UNIX timestamp, this would be all zeros initially (We'll call this integer field "tp_time"). (http://farm4.static.flickr.com/3083/2307747332_5918635cc8_o.jpg) Above and attached is a flowchart to explain my logic... This would allow a script to use llTeleportAgent() ten times within ten minutes, all ten can be bunched up or spread out over the time limit. It would be possible to try and get around this system for the purposes of spamming by for example calling one instance of llTeleportAgent() at 12:00:00pm and then nine at 12:09:59pm, followed by another 10 at 12:10:01pm. However this may be an acceptable caveat considering my suggesting calls for the addition of a "Mute" button to the teleport request popup and names who the object is owned by in the popup to aid the user in stopping spam (Alternative the llTeleportAgent() limit could be on the object itself not the script, this would be different from how other scripted limits like the one for llEmail() are handled however). See the below linked and attached image for an example of the popup I am suggesting... (http://farm3.static.flickr.com/2335/2307774272_b629064227_o.jpg) ... I decided on a prompt such as the one we use when a teleport is requested by an avatar for a couple reasons. One it follows the pre-existing style currently used in Second Life, two by having a prompt it prevents someone from using a teleport loop to grief, by having you teleport from A to B to A indefinately (Even a land owner should not be able to do this). I also decided against a permission system similar to to the one with animations because that could cause the same problem, since the entire SL menu become unavailable during teleport and the device could just repeatedly try to teleport you (Using child scripts if nessicary) to prevent you from using Second Life. And I also decided against allowing attchment or sit as a trigger because again that has the same problem as the animation perms method, it could be abused as you would be unable to detach or unsit. However touch and collision_start are both things that happen only once and then cease happening. Even if a user is teleported into another collision activate teleporter they would not automatically get a teleport prompt again until they cause another collision_start by moving. Even so they would again get the dialog which clearly states who owns the object, the object name, the gives the option to mute said objet and block further teleport requests. Showing the owners name in the dialog is important because it gives the user the option to block all of the owners objects if they so wish. This system while it allows remote teleport requests, ie you can request an agent in another sim to teleport, it does not allow teleport routing. By that I mean a scripted device can not ask an agent to teleport from point A to point B while it is at point C. This again is to prevent possible griefing, the script can only request the agent to teleport to itself so there is no location option unlike llMapDestination(string sim_name, vector position, vector lookat). Addendum: Just to be even more clear, the EXECUTE section of the flowchart would be where the server sends the actual dialog to the user, where if they say "Teleport" they go, otherwise nothing happens. Though I think there is cause for a limitation of some sort onto how many llTeleportAgent() calls a script can make (To prevent spamming a list of people) and I think this a better way to handle it than the tradition sleep (Because often enough you do want to teleport more than open person at the same time), even if no grey-goo fence was added it would be nice to have a Teleport dialog request that we can send from scripts. That and I'd very much like to see a "Mute" button added to the teleport dialog, even from other avatars.