llTeleportAgent

Interesting. Most of the discussion about the security of llTeleportAgent has been based on keeping people from teleporting people who didn't want to be teleported. The flip side is important as well.

The simplest solution would be for the script to have the same rights as the owner of the script... if the owner could teleport to a location, then so can the script.

This would cover your points except for this:And I'm not sure that should be a valid exception. Some people set landing points to discourage people from poking around parts of the parcel, which is a good enough reason to give llTeleportAgent the same restrictions.

Torley, is it lost and forgotten now? If not for any other reason (many great uses posted here already, a llTeleportAgent() with PERMISSION_* and without any confirmation requirement at the time the llTeleportAgent() is called would cover my requests for llTeleportAgentHome(llGetOwner()) to work when task owner is not land owner, or llTeleportHome() for short.

Getting around efficiently and quickly is mandatory in an evergrowing and everlagging environment. Any idea how many "this'll have to do for now" workarounds there are out there now? Just think of the reduction of server stress this llTeleportAgent() will bring, because of doing away with outdated, lengthy, clumsy scripts that try to accomplish something in that direction...

I was contacted by someone who was concerned about an avatar who tends to fall asleep in SL, and hangs around in questionable regions without player supervision way too long. llTeleportAgent() could be (and imho would be) a life-saver for that avatar and many other avatars operated by players with the same problem. At least until "Free Will" gets introduced to SL, although Robin might argue that Will is freed now, but that's another game.

Can we get another firsthand confirmation, firsthand confirming the original firsthand confirmation, if possible with an ETA?

Here's the latest, from Linden Answers:

I see this is a rather old thread being dredged up, and maybe i'm dense, but it seems we can already script teleporters, so what would be the huge advantage of having a llTeleportAgent() function? In other words, what would it do that we can't already do, and why should I want it?

Argent Stonecutter wrote: "This would allow you to create a "doorway" in a house that led to another floor, eliminating space taken up with a variety of hard-to-negotiate staircases. You could even teleport to a skybox, letting you fit "interior" rooms into the build. A "cave entrance" leading "underground" could similarly be moved to the sky."

This is all possible, without this fuction. What am I missing?

It allows you to teleport a user without them having to first ask to be teleported by sitting on something. Obviously it needs limits like only being useable on your own land, or against yourself (ie your attachments can use it, perhaps as a part of a grid-wide game).
It also most importantly allows you to teleport someone anywhere in SL.

Currently all we have is llMapDestination, which is safer in that people see where it wants them to go, but it doesn't allow you to create seemless effects.
Imagine a place where you jump in a well on the ground, when you hit the bottom you are seemlessly teleported into a skybox hundreds of metres up. Or creating a 'never ending' tunnel from a couple of prims.

I'm thinking it should maybe still prompt the user to teleport them to another simulator, and for local use it should have some throttle so that you can't be placed in an infinite loop of teleports.
Once we eventually get teleports made dependable again you could have an entire simulator of indoor areas which are permanently at midnight (since it's better for indoors), climb to the top of the stairs and you emerge to another simulator of outdoor stuff, at whatever time in the day it is.

There are likely much better examples as well but I can't think of them off hand.

Ok, I think I get it now, thanks for the explaination. It does sound like somthing that would be useful. I currently frequent a build that is a series of interconnected skyboxes, joined by teleporters, so I can appreciate how not having to click on the teleporter to move around would help keep things immersive.

Throttle of unannounced TPs:
- Only works on your land to land in the same simulator that is also your land (by "your" I mean the scripter).
- For estates, you could TP through the entire estate (i.e. accross sim boundaries) if "llGetLandOwner" could be calculated.
- Agents sitting on objects are never teleported without warning.
-- eliminates issues of either teleporting the object or disrupting someone's flight/boating/driving

Throttles of "inifinite teleports":
Unfortunately I think this falls into the catagory of the Halting Problem--that a computer can't calculate whether or not any given computer program will halt. Given that, here's a few ideas:
- No more than 5 teleports caused by physics triggered events in a row without a prompt. I.E. Bottomless Pits--you get the idea, you can leave now. Prompt options: "Continue" (5 more TPs), "Stop", and "Ignore" (continue to cause TPs, don't give me a prompt).
-- This allows for the seamless underground spaces, etc. that we want--only one collision is needed
- No single script may teleport an agent more than 5 times without a prompt
-- Exceptopn: scripts owned by the agent (full permission scripts? Possibilities of maliscious use by selling a script that causes endless teleports to the wearer).

many throttles :/ bad

scripting badly need more power over user, sure it prevent griefing but it also fuckup tons of projects

Because we can't script teleporters that:

* Operate on volume-detect or sensor, to simulate a doorway, a corridoor, or a simulated gateway. You can only "teleport" on click.

* Operate reliably over 511 meters, without moving part of the teleporter, leading to occasional breakage.

* Operate over 768 meters without using physical motion. I have recently devised one that does operate in that range that's fast enough to use as a "teleporter", but only in very fast sims.

* Operate across a sim boundary. Actually, this isn't quite true... you can cros *one* sim boundary fast enough for it to be a "teleport", but only if you start out or end within 5 meters of the boundary, *or* you use physical movement and are willing to risk sim-crossing vehicular disasters.

You can't, for example, create a "stargate" (yes, I know about the "stargate network", and it's a clever trick, but it's no better than handing out landmarks). You can't create a virtual hallway, or a "zone gate", or stepping disks, or an "internal" skybox.

I've done everything that you can do without this function, with special effects like dark curtains to "tempt click" teleport initiation, and it's not good enough to do the things I described.

Since intersim teleports are cancellable, there's actually less reason to limit intersim teleports.

Teleports to other parcels in the same sim should be to parcels with the same owner, or to parcels that have a landing point set (in which case they'd go to the landing point). That would prevent teleports into other people's bedrooms.

Not really hard, because I think that even more constricting rules than the ones you suggest would be perfectly reasonable for "second-party teleports" (teleports by a script you don't own) without breaking their ability to maintain an illusion of contiguous space... and these throttles (really only *one* throttle, the first) wouldn't prevent an illusion of *infinite* space... you'd just need to time things carefully:

No more than two second-party teleports by the same agent (or scripts owned by that agent) within 5 seconds, no exceptions. Additional second party teleport attempts in that time are *ignored*, not delayed. This means you can't put teleporters *too* close together unless you're willing to retry the teleport, but the user gets plenty of time to respond to a teleport-loop.

No more than three "instant" second-party teleports by any agent or agents in 15 seconds... the third teleport is delayed just as in an intersim teleport, for a further 5 seconds. This way you get a chance to break a chained teleport loop, too, but if someone's got a volume-detect teleport on their landing point it'll still work.

If you hit (Cancel) in either an intersim teleport *or* a delayed second-party teleport, additional attempts to teleport you by that agent's objects will require confirmation.

You get a window like "Bumps, pushes,... " for "Teleports" so you know who to AR.

The timers and lists for any of the above situations can be managed by the client, since the client is a cooperating party in the teleport, and so don't consume sim resources.

The throttles I suggested explicitly do not fuck up any projects unless you can supply an example.

Argent: I think I understand your throttles. Mostly I agree. There is a problem with inter-sim teleports and canceling. I did once. All it did was remove the black screen and I got to watch objects unrez, the land change, and new objects rez in their place. It was kinda cool actually and I'd love to have every TP look like that (assuming we ever get back to that kind of rez speed), but it did not actually cancel my teleport.
Note: I've only ever done it once and I'm not sure how long after the initiation I clicked cancel. There is a point of no return obviously, but we need to a) remove the button at that point and b) push the point farther from initiation in order to be able to react to a sudden inter-sim teleport.

Damn, I've never gotten that. I've had the teleport cancelled, most times. Once very late in the teleport the port completed, I started moving around in the world, and then I got teleported from scratch a second time.

I've also wished that it didn't bother clearing the screen until it established the connection to the remote server and started the teleport. Intrasim teleports shouldn't clear the screen at all.

I don't like a limit on multiple teleports in a row... that would break the "infinite corridoor" effect.

I'm having a really hard time imagining why this would take very much development time. If we didnt't already have llMapDestination, maybe it would take a little time, but come on, the functionality is nearly identical to llMapDestination. This was announced over a year ago. It would be very useful. It should have been implemented 9-10 months ago.

No it is not. llMapDestination is probably just a call to the landmark system of "set a beacon at X,Y,Z"
Actually causing a teleport is the code inside that nice button on the map that says "move the avatar to X,Y,Z."

Wow you are right that is so incredibly different!

There must already be a message that the client sends to the server when teleporting to a new destination. It has to be in the client already. llTeleportAgent() like llMapDestination() would send a message from the server to the client to activate that request. It cannot be that hard.

Oh, and all that requires a verb change in the code, eh?
I bet not.
What about throttles built into llTeleport() such that griefing is minimized (i.e. works like llPush() does now in a fassion)? llMapDestination doesn't have any of that.