Now we REALLY need llTeleportAgent()

The latest update has broken most of the high-speed long-distance teleporters in-world, including my Superporter and Superporter II. My old long distance teleporter, which is limited to jumps less than 512 meters, still works. If there isn't a fix soon I'm going to see about coming up with a physical motion solution for Superporter II (or III).

But really, all these things are kludges. What we really need is llTeleportAgent(). Yeh, that would kill my teleporter business, but my teleporter business is the result of me wanting a good easily-configured teleporter for my own use... and llTeleportAgent() is the real solution.

Linden Labs even put the call in the compiler at one point, in beta. They NEED to implement it for real, and without a lot of annoying dialog boxes.

I concur. Two of the other routes to using a bonafide teleport
within a sim are unpalateble:

a) give an LM for the person to click on. Yes, this works. Over a period of time, it clogs their inventory with lots of repeats for the same LM. You shouldn't have to search your own inventory, or do daily pruning, to avoid this

b) use the big map. This is overkill for newbies.

llTeleportAgent() is very much needed

I'd buy that for a L$, if it was behind one of the permissions bits.

I'm afraid all alternatives are no go. Not possible to fly around even if above 4096m. Must sit on an object not to be rejected when flying over a prim-full parcel.

instead of llTeleportAgent() I propose llRequestTeleportAgent() :3 that way you cant add it to a gun and auto tele people places ^^

Reckon they'd have some kind of restriction on it, like they do on llTeleportAgentHome.

OK, the last time this came around, the suggestions were:

1. Only a script owned by you or the owner of the parcel you are on can teleport you without a dialog.

2. Nobody else can even teleport you with a dialog unless the parcel is set to enable third party teleports.

3. You can only be teleported once every N seconds. Additional requests either fail silently or are deferred... I prefer the "fail silently" option.

4. You can completely disable llTeleportAgent() in preferences if you want.

And since they have broken WarpPos again...

No, no further comment.

Isn't "llMapDestination" a solution to *part* of this problem? You can touch a scripted object that uses llMapDestination, hit 'teleport' and go?

llTeleportAgent is a powerful function.

On the good side, it could be used for :
* visual effects : e.g. builds which simulate sci-fi things like the Stargate
* security : e.g. routing non-verified avatars to a different location where they have to pass some extra test before gaining enterance to your parcel)
* ease of movement : e.g. when travelling around large estates or parcels

On the bad side, it could be used to create teleport loops and 'black hole' teleporters.

A black hole teleporter is a teleporter that scans out to 96m every 0.5 seconds, and teleporters anyone it finds to the teleporter's location. The teleporter is a scripted box, black on the inside. So... people are flying along, and suddenly they end up inside a box. By the time they've escaped the box... they're teleported back inside it again. They spend most of their time looking at 'teleporting...' screens before their client inevitably crashes or they lose connection and get logged out.
Then, unless they remember to login at home... they end up there again next time they log in

Limiting forced teleports to 1 per N seconds is one possible answer to this.

Another possible answer is that when someone is holding down the SHIFT key, any forced teleport on them sends them home, rather than to the destination given to the llTeleportAgent call.
This would enable people to break out of teleport loops quickly by using their SHIFT key, without having to rate-limit normal, wanted teleports in any way. During a forced teleport, the 'cancel' button should not appear and the warning :
"You are being teleported.
If you are stuck in a teleport loop, remember you can get out of it by holding down SHIFT."
should be displayed.

I have no idea what the Lindens think, but if I had to guess why they haven't implemented this llTeleportAgent function yet (apart from the fact they're so busy they haven't had a chance to) - it would be the fact that this function needs safeguards to prevent certain types of abuse.

Sorta

It's damn unwieldly though - a big map just to TP 100 meters...

I would think that llTeleportAgent can give a dialog similar to the one you receive when a friend offers a TP. It would be along the lines of:

"The object "CampusTransport" has offered a Teleport to:
WhateverSim 128,32,32

ok cancel"


.. hit ok and go. It's just a dialog coming from an object instead of an agent.

And I can imagine preferences where you can say:

* always TP me w/out confirmation if the object is owned by a group I belong to
* always TP me no matter what (I'm brave or naive
* always accept a TP from an object owned by a friend, or from some list of "known good" Sims

The initial implementation could have the 'always confirm' functionality. Add the preferences to make it more convenient later.

Remember, there has been talk about this function since at least December.

December 2005

----

btw, I had posted something about a llPinballTeleport() as a joke a few days back (apply impulse and bounce off of temporary bumpers) -- trying to lighten the mood. On a more practical bent, perhaps there is something to the idea of an impulse-driven transport... something that knows your mass, aims you at the destination, and gets you there quickly without making you feel like you have been fired out of a cannon.

No. The stargate system uses this, and it's such a poor replacement that I have YET to see someone come out of the Stargate one of our group members set up on the Coonspiracy after several months of it being there.

llMapDestination doesn't allow you to create non-linear builds, of any kind. Not the ones you listed, nor any of the other designs that we've discussed.

This has been debated and debated and debated to death. The summary of the results of that debate is in the very message you just responded to. Under the limitations described, a "black hole teleporter" is not possible, and there are few if any uses of llTeleportAgent that require rapid-fire teleports, so there's no reason to make them possible, and no reason to create a special "trick" to get out of a rapid-fire teleport.

We already have better tools for non-linear building within a sim than a teleport-with-dialog. Requiring a dialog for teleports by scripts owned by you or by scripts owned by the parcel owner would reduce llTeleportAgent() to nothing more than a slightly less annoying version of llMapDestination.

I've implemented this for teleports over 768 meters. It works quite well in-sim.