llTeleportAgent will only TP the object owner?

[Jenni Darkwatch]

According to the wiki (which i realize isn't necessary in the final state), llTeleportAgent will only be able to TP the owner of an object? Is that correct? Its counterpart, llTeleportAgentGlobalCoords doesn't have the same note... so to for example create a public global teleporter we'd have to use the latter function.

Could anyone clarify that?

[Innula Zenovka]

That's certainly what the two entries seem to be saying.  I don't think it makes a great deal of sense to have one work for anyone and one work for just the owner (in fact, I don't  see the point of having it only work for the owner, anyway). 

But until it's turned on somewhere on the main grid, we won't know, I guess.

ETA -- I see the note was added by Strife, not Huseby Linden.  I've left a note on the function's discussion page asking where the information came from, though Strife normally knows what he's talking about.

ETA 2 -- Strife has drawn my attention to the full edit history, and the restriction was, in fact, originally added by Huseby, not Strife.   So I guess Huseby should know.   But I think it makes the function pretty pointless -- if I want to tp myself somewhere, I've got plenty of other ways to do it.    It's tping other people (without RLV) that's what's needed.

[Jenni Darkwatch]

I think it'd be a bit silly if it's owner only, especially considering that the function still requires a permission request... but who knows. It would make it a bit less useful. The inconsistency is what struck me with the note, making me believe it may be erroneous, or possibly a temporary restriction based on the teleport exploit a few weeks ago.

Is the function available in any of the sandboxes on the main grid? That'd allow testing at least.

[Fnordian Link]

The owner-only restriction does seem rather odd.  The majority of teleporters are intended for use by many more avatars than just the owner so it certainly seems like a lot of effort to create a function with such limited use.

And given that the teleport function requires the user to grant permission, it's hard to understand why this limitation has been added.

Does this restriction make sense to anyone?

 

[Innula Zenovka]

I'm hoping it's a temporary precaution, after the debacle a few weeks ago, and that things will be relaxed after they're sure the perms are workign properly.

[Will Webb]

In my experience, now would be the perfect time to panic and overreact, lest we get stuck with this implementation ;-)

-- edited to remove comment on use of landmark, as llteleportagentglobalcoords takes care of that

[Jenni Darkwatch]

---

Will Webb wrote:

In my experience, now would be the perfect time to panic and overreact, lest we get stuck with this implementation ;-)

---

There's a workaround of sorts, albeit a pretty **bleep**ty one. In theory, for small groups, it ought to be possible to give people an attachable object and just send the TP coordinates to that. Of course, unless some grid-wide standard emerges this would not be feasible for anything else and agreed, the function as it is defined right now is pretty close to worthless.

[Will Webb]

Hadn't thought of that; a server-client attachment system would solve the issue at least for RP groups and such.

[Innula Zenovka]

It's certainly workable for RP groups.   The RLV Relay provides a sort of model.    But it's hopeless, of course, for such obvious applications as destination board TPs for groups of sims, which I know a lot people had been hoping to use it for.

I really hope it's just a temporary measure while LL squash the remaining bugs with permissions and close off potential griefing exploits.

[Will Webb]

"You can never overestimate the out-of-touchness of companies with their customers" or somesuch :-)

Assuming a worst-case, I'm hoping an open standard will emerge for server-client solutions, or at least enough APIs to integrate seperate server systems into one client attachment.

 

Honestly though, since I haven't heard anyone from LL even *breathe* the "It's just for the beta" line, I'm not holding out much hope; they've been known time and time again to worsen performance and other systems with arbitrary limits.

llSetPos limit at 10m? Let's just call it in a while or for loop.
Sensor limit at 96m? Let's just spam sensor "drones" that move up and down and lag a sim to death with their updates.
No llName2Key? Let's just build an external database and spam sims with scanners that transmit their recorded names and keys to the outside server.

Most limits, no matter how well intentional, get bypassed by the ingenuity of SL builders and scripters (as long as they are willing to stick around to deal with those limits in the first place).

[Jenni Darkwatch]

The thing I dislike about the workaround: Yet one more script/attachment to lug around.

I'm with you on having my doubts about LL lifting that limit for the average scripter. Obviously, based on the Linden Realms game, there's a way around that limitation. Whether residents will ever be able to get around it? Only the Lindens know, and they're not talking - as usual.

[Ewan Mureaux]

I really cannot fathom why this is limited when a permission request is made. 

 

I also don't understand the blog post that references Linden Realms then introduces a function nothing like the one shown in the example of Linden Realms.

 

Is there a JIRA link to have this function made actually useful or are we being stuck with ridiculous looped calls to move people around?

 

 

[Jenni Darkwatch]

Yeah it's a double-whammy. With the temp attachment, it would not be THAT bad. But temp attachments are specifically excluded. Sooo... the function is pretty crippled right now. I did create a walk-through inter-sim door. It requires _either_ a rezzed object on both ends, owned by the person using the door... or a HUD.

The question then is: Why on earth even ask for permission to TP? That's not going to prevent griefing, because it doesn't give the user _any_ hint where the TP is supposed to go to. And for giggles I tried it... you can essentially cripple someones avi by just spamming TPs once you got their TP permission.

[DanielWildcat]

Having this function only work on the owner is pointless! It should work with any avatar as long as the function is used by the land ownwer on the land for avatars on said land..  Why would permissions be required for a 1 person teleporter? Not only that, it is very spammy and nor does it give an error message to any other avatars that attempt to use my teleporter..

These functions should probably be renamed to llTeleportOwner and llTeleportOwnerGlobalCoords since, "Agent" implies ANY agent. 

 

 

[Rolig Loon]

You may or may not remember the fiasco when the function was introduced.  It did exactly what it was supposed to .... teleported anyone who triggered it.   Unfortunately, as Jenni's post just above yours indicates, the permissions system made it an incredibly nice griefer tool, so it was pulled within 24 hours of the time it was first released.   So, we have an emasculated version and will have to be satisfied with it until the *new, improved* permissions system is released ..... some day.