So what happened to llTeleportAgent?

I've been expecting llTeleportAgent since it was announced for, what, the 1.8 preview?

Here's 1.12 on the horizon and there's nary a whisper.

I take that as a good sign - If it were announced it was due to be released then I would throw all of my plans back into the filing cabinet for another 6 months.

At least un-announced it has a chance of falling into the release bucket by mistake.

Yeh, yeh, but I'm working on the warp-move upgrade for my security teleporter anyway.

Update: the development resources for llTeleportAgent were, and still are, reallocated to getting the new Groups system pushed out faster. llTeleportAgent is still on the books to be done. Haven't forgotten; heck, how could we--I keep bringing it up.

Give me a login and I'll implement it for you. It can't be more code than I've already written for sit teleports.

Yeah, I don't see why either, even just for in-sim teleports it would be helluva useful.

Given that the native code to do this already exists (e.g. click big-map, teleport there with all the checks and tests already implemented) I imagine writing an LSL wrapper must be pretty hard.

Could be some permissions stuff to do. When is a script allowed to tp someone who isn't the owner of the script?

Well, let's see...

1. llTeleportAgentHome can already teleport you home if you're on land owned by the script owner. llTeleportAGent shouldn't have any stronger restrictions than that.

2. Vehicles you're riding, and attachments, can already use llApplyImpulse, llSetPos, and llSetPrimitiveParams to zap you anywhere in the same sim, or most anywhere within a few kilometers, almost instantly.

So, if it's attached, you're the owner. No question it should just work. If you're sitting on it, or you're llOverMyLand... it should just work. Any other situation... it should ask permission.

yeah weird! you'd think this would be a 10 minutes jobby.

oh well, who knows what wierdness they are up against.

It's the Teleport Cabal! The Transdimensional Inner Core!

Hmm, I do wonder what kind of restrictions it might have though? Unlike teleport home and eject, teleport agent is potentially multiple use. You could teleport someone to another plot of your land so they intersect an object and are immediately teleported again and again, forcing them to force close SL or get stuck in a loop.
Would llTeleportAgent() therefore be immediate or optional, with teleport home and eject being there to protect land (and thereby not be optional)?

Just a thought, though admittedly I can't think of any worse abuse than that, except maybe to teleport you from happy bunny land on a PG sim into a room full of harcore porn or something.

Personally I think it would be alot better if it did ask for permission, using llRequestPermissions, and have it return the permissions event.. and if it's the owners object permission is automatically granted, same goes for if it's on the owners land.

imagine a 10m cube running as a volume detect, sitting on the owners land, that does an llTeleportAgent to the center of the cube.

Hey presto - we have an instant prison - no way out apart from relogging - once you step in, you're screwed.

Major TOS violation of course, but that won't stop people from doing it, or similar.

So the simple straight-forward "on the owner's land" permission simply isn't enough.

I've already seen issues reported where someone's misconfigured security script was llTeleportHome ing them into it's scanner range still, and repeat...

Personally, I can't wait for llTeleportAgent - I'd love to have it, but I _do_ want in implemented 'right' - the Lindens get enough grief when people discover new and inventive ways to use their new features to cause pain.

Why not just add another permission ( PERMISSION_TO_TELEPORT )
then use the llMapDestination code - but remove the map.

( I know it is probably far more complex than that - but as said above I cant honestly see any new stuff being needed - except another permission value - just a different use of existing stuff )

But obviously it has a lower priority than new groups, statistical functions in lists, better snapshots, and a color picker.

Maybe a way to implement it without it being open to too much abuse would be to introduce a Teleport option to the radial menu you get then right clicking on an object.
Let objects have a "teleport target" in the same was as they have a sit target and the menu option only becomes available if the object's teleport target has been set.
This way teleport functionality wouldn't be open to abuse more than sitting and the existing teleport functions would still be able to work for security systems.

A function llSetTeleportTarget() would be the only enhancement needed to LSL and it could either work from global coordinates or from region name & region coordinates. Personally I would suggest parameters as follows:-
llSetTeleportTarget(Destination_Type, Region_Name, Destination Rotation_Type, Rotation);

Destination_Type would be an integer accepting the following values:-
TP_DEST_TYPE_GLOBAL (Teleport to a specified global position)
TP_DEST_TYPE_LOCAL (Teleport to a specified local position)
TP_DEST_TYPE_RELATIVE (Telport to a destination relative to the teleport prim)

Region_Name would be a string identifying the region name for TP_DEST_TYPE_GLOBAL and would be ignored otherwise.

Destination would be a vector identifying the region or relative coordniates of the destionation, depending on Destination_Type.

Rotation_Type would be an integer accepting the following values:-
TP_ROT_TYPE_ABSOLUTE (The teleported agent faces the specified direction)
TP_ROT_TYPE_RELATIVE (The agent faces a rotation relative to the teleport prim)
TP_ROT_TYPE_NONE (The agent's rotation is unaltered)

Rotation would be a rotation identifying the direction the teleported agent faces either an absolute rotation or in relative to the teleporting prim, depending on Rotation_Type.

Alternatively as 2 of these parameters are optional the parameters could be passed as a list.

I think that would be classifiable as griefing unless the owner could show it was a bug.

Perhaps there should be a short period (a few seconds) after teleport in which llTeleportAgent can't "see" the avatar?
If llTeleportAgent isn't immediate and with no dialog, at least for the cases I listed above, a huge number of useful techniques (like, say, linked doorways and non-euclidean builds in general) would be pointless.

That would be how I'd implement it, yes, with permission automatically and transparently granted for the cases in question. But the important point is that it should be able to use use llTeleportAgent to build stepping-disks, infinite corridoors, and other transparent gate systems.

That would provide absolutely no useful functionality for non-linear builds over existing sit-teleports.

It would allow for teleports over 512m. And surely that's the whole point, to be able to move quickly, easily and with minimal weirdness over long distances.

I wonder if there is a way to have one teleport script send a user a requestpermissionstoteleport and once activated, all teleport scripts on the land will have that permission untill the avatar steps off the parcel. Once the user returns, another dialouge prompt would occur.

To keep people from having to be asked this the first time someone steps through a teleporter, create a function that will prompt an avatar for permission to teleport without having to be linked to a teleportavatar function.

Hey, any chance we can get a teleport event? So we can trigger things when a script teleports an avatar? Any chance of having physics objects being teleported? Might make for interesting creations and events too, especially with a teleport event.

In regards to anti-griefing, another simple (to use, not necessarily to implement) option would be to have a throttle on teleport rates for either an object or an avatar, so, worst case, if you do step into a trap, you know that you will only be bounced around for 3 or 4 hops before you get a 30 second timeout in which you can act and get out of the trap / tp home / whatever.

Turns a relog nightmare into an brief annoyance.

Yeah, that would work I think. Enough time that if you're in a loop you can think "bah" and teleport home or something.

Additionally though, I think both the invisible but 'delayed' method AND the permission method would be good. The invisible method applies if you are wearing the object, sitting on it (llTeleportAgent would automatically unsit you) or on land owned by the object owner.
The dialogue method where you are told "Object X would like to teleport you to location X,Y,Z" applies for others, so that you can still have scripted quick teleports for say, vendors taking you to a main-store or such.

Infinite corridors are something I'd really like actually, think of the prims you can save with a little scripting genius

You already have that with landmarks. You get the world map popping up and you click "teleport" instead of having a dialog box popping up and clicking "OK", but the operations are the same.

If llTeleportAgent is just llGiveInventory(agent, landmark) without the ability to preview where you're going, what's the point? If you can make it happen without that extra dialog, then you can create all kinds of amazing new builds using non-linear space. Stepping disks, gateways into other worlds, portals, wormholes, space warps, optical illusions in 3d, ...

Exactly what I was suggesting. Require a short (say, 5-10s) delay after teleporting before llTeleportAgent could work on you again. That wouldn't hurt any builds (you can get the same effect of multiple teleports by teleporting straight to the destination), but would make it pointless for griefing. You wouldn't be "bounced around" for any hops, you'd have a maximum "blip rate".

You could even have a preference setting, so you could turn your "blip rate" down if you *wanted* to bounce around.