Discussion on a change to llTeleportAgent().

[Kyrah Abattoir]

1 minute ago, Mollymews said:

except when wanting to build a portal travel system that acts like a portal system as they are ordinarily expected to work by users. Walk/run/swim/fly into a portal and woosh! 

I mean as a requirement, that's just unnecessary busywork to require a collision when you're already the land and script owner.

[Mollymews]

i think as well that while we can discuss the implementation of how it might work, i think that basically it comes down to it being a departure from the existing permissions system, which is all about the social relationship that Linden has with its customers/residents, and the relationship that the residents have with each other.  The yes/no answer to this will come from the Product department I think

[Mollymews]

i want to add more about making decisions that break an existing social contract

if we were to decide to break the existing permissions social contract then what is the rationale for doing this ?

if we were going to depart from the permissions social contract then my view is that the departure should be with experience permissions. Linden have granted themselves this power. People automatically added without permission to Linden-owned experiences from which we can't leave

and I think the Product discussion should be about whether or not a person's presence on a parcel automatically joins them to the parcel owner's Experience for that parcel while the person is on the owner's parcel, cannot leave the Experience while on the parcel, and  automatically removes them from the Experience when they exit the parcel - a temporary membership

this is a major departure but the uptake in creating experiences has fallen short of expectations, for the reason that significant numbers of people reject granting experience permissions when asked, and parcel owners are loathe to eject visitors who don't grant them experience permissions. And I think that if we were wanting a rationale then it would be this

 

[Gabriele Graves]

Extracting "permission" in an underhand automatic way is not equivalent to that person giving consent.

The very idea of getting permission without asking explicitly via any mechanism that a reasonable person would understand as such is just a way to circumvent getting permission.  So let's not baste the turkey here.  It is not reasonable for people to expect that the instant they step foot over a land parcel border or TP to a private region that they can be subject to whatever the land owner wants.  That is so much horse-poo and it's an over-inflated sense of entitlement of exactly what your money is getting you.  Anyone who thinks this should show me where it says this in the TOS of service, explicitly.

The fact is you cannot have "automatic" and "the user gave informed permission".  The two are completely contradictory to each other.
The best you can do for "automatic" is to get the user to flip a one time switch that basically says, "I don't care, don't bug me" anything else short of asking is just subterfuge and dishonest.

[Tactical UwU]

I honestly don't see why this is necessary when we already have a system in region Experiences that makes the teleport-related functions a largely 1-time opt-in anyway.

All you need to do is run a llAgentInExperience call and you could even go as far as to require it. I have a security system checks this and will not give you a land pass if you don't use it. It's really not hard to set something like that up.

Anything short of that is an open-door to misuse and abuse.

[Qie Niangao]

10 hours ago, Mollymews said:

on the second, inter-region teleport

the delay time I think would be roughly within the same range as when we bring up the World Map from a  scripted slurl. Might be a tiny bit more time needed to gather some further parcel details once the data record is located, but I think the time to gather would be tiny compared to the time taken to locate the data record itself

I realize this may be a distinction without much difference in the cloud, but I've always thought of the spatial arrangement of parcel ownership on a region to be "known by" the sim, not a central service's data store (in contrast to World Map data). Hence I imagined a process where a little transaction with the destination sim would be needed to determine whether the teleport was valid, and that would need to time-out if it didn't get a timely response. Maybe instead every sim can have read-only access to the store of all regions' parcel ownership and layout... or maybe they always had that and I've had a defective mental model of how it works.

Now, to permissions, to restate what seems to have emerged from the discussion: The function would be permitted to operate on agents on the script-owner's land without needing any further confirmation (no need for sitting, no wearing, no dialog, and no collision nor other event). Presumably the script would still need to request PERMISSION_TELEPORT but it would automatically be granted for agents on a parcel with the same owner* but I guess revoked the moment they set foot on somebody else's land(sorta like standing from a chair revokes tacitly-granted PERMISSION_TRIGGER_ANIMATION), so this could happen pretty often. Maybe it checks to see whether the tacit permissions grant is still valid at the time it calls the function: confirming they're still on the owner's parcel.

Oh, also, because this is a land thing, need to spec how group-owned land is supposed to work. I'd prefer that the script must be owned by the land owning group to even try to use the function, none of this hokey stuff where there's a determination of an owning agent's group roles and abilities if they're connected to the region, as with so many land operations now. (Also no slack for scripts merely set to the same group as group-set land. Make it be that the ownership must match perfectly, it's just so much more predictable.)

I wonder if I'm taking this all too seriously. I'm really not sure this is a good idea from a UX perspective. I hate the way Experience permissions are requested but maybe, despite all evidence, users will eventually get over their reluctance if enough of the grid is locked behind Experience permissions. I think I'm coming 'round to @Soupy Nova's view: If they won't agree to the land Experience, send 'em home until they do; didn't need their laggy avatars anyway.

____________
* Not necessarily the very same parcel, I suppose. In fact, the script could be over somebody else's land, only the script owner must match the owner of the land where the agent to be teleported is located. I guess the script must be in the same region as the agent to be teleported.

[Mollymews]

5 hours ago, Gabriele Graves said:

The fact is you cannot have "automatic" and "the user gave informed permission".  The two are completely contradictory to each other.

The best you can do for "automatic" is to get the user to flip a one time switch that basically says, "I don't care, don't bug me" anything else short of asking is just subterfuge and dishonest.

been thinking about this a little bit. Along the lines of how to make granting experience permissions less scary for people unused to participating in experiences

suppose you (my visitor) were to visit my parcel (as not a member of my experience) and you got a system chiclet notification: "This parcel is "Experience The Mews" enabled. Should you still be here, 30 seconds from now, you will be temporarily added to this experience. When you leave the parcel you will be removed from the experience."

should you (my visitor) leave before the 30 seconds is up then you don't get added at all

basically an automated experience opt-out system. Stay beyond 30 seconds and we are opted-in while we remain on the parcel. We opt-out by leaving

would require a data flag to distinguish between Temporary and Permanent experience membership. Permanent being for those who manually join the Experience: staff, developers, tenants, regular patrons, etc

[Mollymews]

18 minutes ago, Qie Niangao said:

I'm really not sure this is a good idea from a UX perspective. I hate the way Experience permissions are requested but maybe, despite all evidence, users will eventually get over their reluctance if enough of the grid is locked behind Experience permissions. I think I'm coming 'round to @Soupy Nova's view: If they won't agree to the land Experience, send 'em home until they do

this is my two minds problem as well

scraping this proposal down to the bones raises the question. Why would we want to hack our way around the classic permissions system which is not a great model ? When experience permissions are a far better model. When we leave an Experience then all scripts that may have been granted our permissions previously are revoked (inoperable on us)

my second mind agrees with the posit. We need to make Experiences more attractive to the every day users in a simple straightforward way

[Qie Niangao]

11 minutes ago, Mollymews said:

basically an automated experience opt-out system. Stay beyond 30 seconds and we are opted-in while we remain on the parcel. We opt-out by leaving

I like this a lot.

It's not that implicit permissions grants in general are "subterfuge and dishonest" -- I bet implicit permissions are two or three orders of magnitude more common than explicit permissions dialogs. Almost everything we sit on gets PERMISSION_TRIGGER_ANIMATIONS, nearly everything we wear gets at least PERMISSION_TAKE_CONTROLS. I can't begin to imagine the annoyance of being asked every time; there'd be TPVs that just said yes to everything (except PERMISSION_DEBIT) just to make the UX tolerable.

But this isn't implicit anyway; it's opt-out. Good enough for me, and a vast improvement over the current kludgy Experience permissions dialog.

[Gabriele Graves]

25 minutes ago, Mollymews said:

been thinking about this a little bit. Along the lines of how to make granting experience permissions less scary for people unused to participating in experiences

suppose you (my visitor) were to visit my parcel (as not a member of my experience) and you got a system chiclet notification: "This parcel is "Experience The Mews" enabled. Should you still be here, 30 seconds from now, you will be temporarily added to this experience. When you leave the parcel you will be removed from the experience."

should you (my visitor) leave before the 30 seconds is up then you don't get added at all

basically an automated experience opt-out system. Stay beyond 30 seconds and we are opted-in while we remain on the parcel. We opt-out by leaving

would require a data flag to distinguish between Temporary and Permanent experience membership. Permanent being for those who manually join the Experience: staff, developers, tenants, regular patrons, etc

Molly, I know that you are only trying to think your way around to find a system that works for all but honestly I don't think there is a way and I don't see how this is any better, in fact it is worse than what we have currently with Experiences.

There are always problems with time-based stuff for a variety of reasons which means once again consent isn't freely given under those circumstances.  Opt-outs are pretty much cop-outs when it comes to anything.  Only with opt-in can you really be sure a person gave consent.

It basically boils down to this, it's about trust.  The land owner is asking the person to trust that they will behave responsibly.  However, the land owner that puts up a  timed opt-out like this or any other non-obvious automatic opt-in is going to come across as shady AF.  That will not inspire trust among people who understand what powers the land owner can exert.

Honestly, I would rather be subject to llEjectFromLand() to a nearby parcel or llTeleportedHome() for not agreeing to an Experience request in a timely fashion.

Let me give you an example of what inspires Trust for me.  I recently visited a winter christmas region.  I arrived, there was no annoying Experience requests and nobody trying to exert control over my avatar.  I was allowed to wander freely around in my own time without being hassled.  At one point I clicked on a telephone booth and it asked me for Experience permissions which, in my mind, because it was a telephone box (I know, corny-as) I presumed it was for teleports.  I decided not to accept the Experience and not use the teleporter.  I didn't get teleported home because of that, I was just allowed to carry on exploring.  I was just unable to use their teleporter.

That region owner, I trusted.

Edited January 15, 2021 by Gabriele Graves

[Mollymews]

14 minutes ago, Gabriele Graves said:

It basically boils down to this, it's about trust.  The land owner is asking the person to trust that they will behave responsibly.  However, the land owner that puts up a  timed opt-out like this or any other non-obvious automatic opt-in is going to come across as shady AF.  That will not inspire trust among people who understand what the powers the land owner can exert.

this is where we differ. I accept all Experience requests. If it turns out to be a uninspiring experience then I just leave it. Bit like when I turn RLV on sometimes. Some  RLV experiences can be meh and uninspiring sometimes

you are right tho,about mix n match. There could be a Experience property that applies to the parcel. Enable Auto-opt.  When not enabled then Experiences work as they do now so parcel owners can mix n match classic and experience scripts permissions as they want

Edited January 15, 2021 by Mollymews
typs

[Qie Niangao]

11 minutes ago, Gabriele Graves said:

... At one point I clicked on a telephone booth and it asked me for Experience permissions which, in my mind, because it was a telephone box (I know, corny-as) I presumed it was for teleports.  I decided not to accept the Experience and not use the teleporter.  I didn't get teleported home because of that, I was just allowed to carry on exploring.  I was just unable to use their teleporter.

That region owner, I trusted.

But we'll never know what wonders that telephone booth may have performed. Sure, probably it was just a teleporter, but it was never given a chance. And that is the failure of the Experience permissions dialog: More times than not, it spooks users who have absolutely no hint of what's on offer -- and given the scary dialog, I don't even bother describing anymore what my Experiences will actually do; there's no reason they should trust me when the dialog makes it look as if they're signing over their first born male heir.

Now SL got along fine without Experiences for a decade or so, and it acquired a lot of users with particular expectations. It's SL's "virtual Architectural Digest" use case, and it's fine: explore pretty stuff and pretty avatars and buy some clothes for our dolls and a nice dollhouse for them. Maybe if we're lucky, some of the stuff will minimally respond to our presence, but mostly that grid is one huge static 3D scene.

It's the very opposite of engaging.

Experiences were intended to enable more and deeper engagement through easier interactivity with a responsive virtual world. The problem is that the current Experience dialog fosters distrust -- as demonstrated in the interaction with the hapless telephone booth.

[Gabriele Graves]

I have had some further thoughts about this as well.

Obviously there are people who don't mind, may even want, to be subject to a land owner absolute control and there are obviously land owners who want to exert that control.  There should be a way to accommodate those people as well as people who don't want it.

All of this stuff, Experiences and this proposal come down to control.  Those who want it, those who want to give it and those who don't.  It would be better to have all of this in one place in my opinion.  RLV is a system that specialises in giving control to others.

I think LL should implement a kind of RLV-like system in the official viewer that has options to give land-owners or whoever, some kinds of control that don't ask for permission after that.  This kind of stuff and Experiences should subject to that system.  The land owners would be able to detect whether the setting is on or off and if off for them, be able to use the existing Experience permission request or any other permission request to ask.  Failing that, be able to eject or teleport the avatar off their land.  If the setting is on, no permission is needed.

Ideally, you would be able to specify a set of people or groups for On to be enabled for.

I am sure there are holes in this idea but at least it is a similar principle under one banner that incorporates control.


 

Edited January 15, 2021 by Gabriele Graves

[Gabriele Graves]

1 hour ago, Mollymews said:

this is where we differ. I accept all Experience requests. If it turns out to be a uninspiring experience then I just leave it. Bit like when I turn RLV on sometimes. Some  RLV experiences can be meh and uninspiring sometimes

Yes we do and this is why lots of different perspectives are valuable to help us understand the whole of the problem instead of the facets we can get our heads around.  I have never used RLV and never had anything that I wanted to do that would require it.

Edited January 15, 2021 by Gabriele Graves

[Gabriele Graves]

5 minutes ago, Qie Niangao said:

But we'll never know what wonders that telephone booth may have performed. Sure, probably it was just a teleporter, but it was never given a chance. And that is the failure of the Experience permissions dialog: More times than not, it spooks users who have absolutely no hint of what's on offer -- and given the scary dialog, I don't even bother describing anymore what my Experiences will actually do; there's no reason they should trust me when the dialog makes it look as if they're signing over their first born male heir.

I don't believe that this is a solvable problem.  It's the law of least surprise that should rule here...unless you want something surprising.  The devil of the detail is in how to possibly cater to the ones who do and those that don't.

5 minutes ago, Qie Niangao said:

Now SL got along fine without Experiences for a decade or so, and it acquired a lot of users with particular expectations. It's SL's "virtual Architectural Digest" use case, and it's fine: explore pretty stuff and pretty avatars and buy some clothes for our dolls and a nice dollhouse for them. Maybe if we're lucky, some of the stuff will minimally respond to our presence, but mostly that grid is one huge static 3D scene.

It's the very opposite of engaging.

Experiences were intended to enable more and deeper engagement through easier interactivity with a responsive virtual world. The problem is that the current Experience dialog fosters distrust -- as demonstrated in the interaction with the hapless telephone booth.

The problem is always people.  They cannot be trusted for the most part.  Sure, some individuals can be but others will ruin things for everyone.  This is why we have to have explicit permissions for everything.  It is an inconvenience for all concerned but it is necessary when there are untrustworthy people who will abuse any trust given and exploit any system, there simply is no other reasonable choice.  This is true for RL and SL for many things.

For the most part there are no good technical solutions to social problems.

I think we also have to start to recognise that SL is not a suitable platform for providing the kinds of games where you need to lock down what a person can do with their avatar.  It has never been.  There will always be limitations or it will fundamentally change SL forever and it will lose a lot in the transition.  There are more suitable platforms for those kinds of games and the people who need to have that level of control over the experience.

In my opinion, we also need to recognise that a lot of people come to SL to gain a kind of freedom of expression and possibly aren't as concerned about advanced immersion or environment responsiveness.  I don't think we can take it as a given that it is a feature that is universally desirable for all at any cost.

[Gabriele Graves]

2 hours ago, Qie Niangao said:

It's not that implicit permissions grants in general are "subterfuge and dishonest" -- I bet implicit permissions are two or three orders of magnitude more common than explicit permissions dialogs. Almost everything we sit on gets PERMISSION_TRIGGER_ANIMATIONS, nearly everything we wear gets at least PERMISSION_TAKE_CONTROLS. I can't begin to imagine the annoyance of being asked every time; there'd be TPVs that just said yes to everything (except PERMISSION_DEBIT) just to make the UX tolerable.

But this isn't implicit anyway; it's opt-out. Good enough for me, and a vast improvement over the current kludgy Experience permissions dialog.

I don't see sitting and wearing items as implicit as you suggest.  Sure a blue permissions dialog is not present, however the user has initiated an action (to sit or to wear an item), which is an explicit permission grant in concept because it can be given with full knowledge of what will happen and full consent.  The user knows full well (or at least can learn/discover) that no other permissions can be given along with that and have full confidence that payment cannot be taken from them for example.  That isn't as implicit as doing a completely unrelated action (i.e. cross a parcel border) and maybe, possibly at some unexpected time your avatar may (or may not) be moved against your wishes to various places at the land owner's whim.  It is difficult to believe you don't see the difference and yes advocating for the latter capability is a vote for subterfuge and dishonesty.

When something would be unexpected and possibly unwelcome, why would the honest action not be to ask permission explicitly?  Why does it inconvenience the land owner if a person wishes to be asked explicitly?  What possible reason could there be unless the land owner is worried that the user may not give their consent if asked properly but instead wishes to circumvent proper consent and do it anyway?

Edited January 15, 2021 by Gabriele Graves

[Qie Niangao]

"Implicit" -- I just needed some language to differentiate between being presented with the explicit permissions dialog and having the permission granted by some other action whether it's sitting, wearing an attachment, or (potentially) visiting somebody's parcel. Earlier I tried "tacit" but it seems clunky as an antonym of "explicit" and anyway, I daresay most "sitters" haven't a clue what-all that chair can do to their avatar and viewer controls, so if sitting is "explicit" in granting those permissions then I don't know what the word means.

Again, the underlying problem is that Experiences are a failure because they look so scary, despite being by far the safest permissions to grant since they alone can be easily and truly revoked. Folks do fear that payment can be taken from them by an Experience simply because the list of permissions is so long, technical, and unlike anything else in SL, even though of course they should be equally afraid of a chair or an attachment that asked for nothing -- which is to say, not afraid at all. (Speaking of which, sitting surely does expose the avatar to being "moved against your wishes to various places at the land owner's whim" -- that's how many teleporters worked for ages. And attachments of course can do all the llTeleportAgent()ing they like yet somehow we're okay with the possibility that an innocent-looking AO might suddenly go rogue and teleport us to the Cornfield.)

And so SL is stuck in the pre-Experience stasis of dwindling usage, slackening engagement, and the perpetual question of "what is there to do here?" Addressing that failure and giving Experiences a chance to have the impact for which they were intended is "what possible reason" one may have to reduce the scariness of getting those permissions.

Edited January 15, 2021 by Qie Niangao
(matching close paren)

[Gabriele Graves]

Well that is the nub of it then.  You can pretty much justify or frame anything whichever way you want but it doesn't change the fact that others may look at that for what it is.  Consider this though, this very course of action may cause more mistrust amongst others.  I myself am certainly not getting warm fuzzies or the urge to get all trusty over this.

Edited January 15, 2021 by Gabriele Graves

[Wulfie Reanimator]

I've only skimmed the current discussion but since everyone seems so hung up on permissions, I'd like to reiterate my opinion of what should realistically change, which I said on the first page.

Right now, llTeleportAgent requires permission AND it only works on the script's owner.

Instead, llTeleportAgent should be able to teleport anyone as long as permission has been granted as normal. None of these behavior changes to how permissions work are necessary, and only complicate the changes that could be done.

The "only teleport owner" restriction seems overly strict, even though there is undeniably potential for griefing. I remind you that scripts cannot hold permissions for multiple agents at once, and we have other functions that are arguably much more destructive, such as llGiveMoney (drains the account dry), as well as much more disruptive, like llInstantMessage (spam across the grid).

Teleport griefing can be escaped, those previous examples are not so easily undone if the griefer is determined.

I don't think it's fair that I would have to pay Premium in order to move people around.

Edited January 15, 2021 by Wulfie Reanimator

[Gabriele Graves]

5 minutes ago, Wulfie Reanimator said:

Right now, llTeleportAgent requires permission AND it only works on the script's owner.

I am not sure of the history of this.  Was it always like this or was it restricted to handle a particular issue?

5 minutes ago, Wulfie Reanimator said:

Instead, llTeleportAgent should be able to teleport anyone as long as permission has been granted as normal. None of these behavior changes to how permissions work are necessary, and only complicate the changes that could happen.

The "only teleport owner" restriction seems overly strict, even though there is undeniably potential for griefing.

I think I could probably agree with this.  I think it should either be limited to within the same region or the permission request dialog should state the destination region name.  Otherwise, it seems to me that if a person isn't sure about the request, they would deny it.

[Wulfie Reanimator]

2 hours ago, Gabriele Graves said:

I am not sure of the history of this.  Was it always like this or was it restricted to handle a particular issue?

I think I could probably agree with this.  I think it should either be limited to within the same region or the permission request dialog should state the destination region name.  Otherwise, it seems to me that if a person isn't sure about the request, they would deny it.

The function was initially proposed with this limit, and was accepted as-is.

To have the destination in the permission request would already be too much to change. The permission request is completely decoupled from the teleport attempt and llRequestPermission doesn't have a parameter for "reason." There is no way to announce the intended destination with current functions.

The only thing that should change, to make this a viable feature request, is to simply lift the "owner only" restriction. Anything extra, and we're looking at LL most likely not implementing it, or implementing it poorly.

We should not need to invent entirely new systems like "local permissions" (parcel-based) or "temporary permissions" (time-based) or require changes to other functions like llRequestPermissions.

Edited January 15, 2021 by Wulfie Reanimator

[Mollymews]

3 hours ago, Wulfie Reanimator said:

The function was initially proposed with this limit, and was accepted as-is.

To have the destination in the permission request would already be too much to change. The permission request is completely decoupled from the teleport attempt and llRequestPermission doesn't have a parameter for "reason." There is no way to announce the intended destination with current functions.

The only thing that should change, to make this a viable feature request, is to simply lift the "owner only" restriction. Anything extra, and we're looking at LL most likely not implementing it, or implementing it poorly.

We should not need to invent entirely new systems like "local permissions" (parcel-based) or "temporary permissions" (time-based) or require changes to other functions like llRequestPermissions.

this gets to the heart of it I think

If llTeleportAgent() requires classic PERMISSION_TELEPORT to be granted via dialog, which can be declined, then what does this do functionally that can't already be done with llMapDestination() which gives the person quite a lot information about the destination before they accept the teleport. And if llTeleportAgent() were to provide less information prior to it being activated then why would resources be expended on it

[Wulfie Reanimator]

8 hours ago, Gabriele Graves said:

When something would be unexpected and possibly unwelcome, why would the honest action not be to ask permission explicitly?  Why does it inconvenience the land owner if a person wishes to be asked explicitly?  What possible reason could there be unless the land owner is worried that the user may not give their consent if asked properly but instead wishes to circumvent proper consent and do it anyway?

Every case is different. Sometimes it's important that the teleport happens now and not 5 seconds later when they click the dialog. Sometimes it's also important that the user cannot refuse, but that's besides the point and something we can do with RLV (with the exception of LL viewer users).

For example, SLMC (Military Community) relies on a lot of "forced" features that could be considered griefing in a different context, such as avatar caging, pushing the avatar with llPushObject, blocking their view of the world, playing loud sounds and launching hundreds of prims at them as a legitimate part of the experience that cannot be replicated any other way. In these cases, combat is conducted by one group entering the "home sim" of another group (generally unannounced) and attacking its residents with guns, explosives, and vehicles. Simply being in the sim and leaving the protected spawn areas is consent to everything that entails, otherwise you should not be there. I'm not talking about roleplay, I mean pure combat -- shoot first, insult later.

I don't have a particular idea in mind that I would implement with llTeleportAgent that I couldn't do without it (perhaps something in multi-sim combat zones), but the point I want to make is that there is so much more out there that people are doing that could benefit from things we're "concerned might be misused."

But if I was developing with a specific combat-feature in mind and the target did not give me permission to teleport them, I'd probably just kill them to force them back to spawn until they do. This, because I don't have access to Experiences.

If I was a combatant with some kind of weapon/device with special features, such as blinking the target into a random location (and I had no access to anything they're wearing/sitting on), I could use llTeleportAgent for that. If they refuse the teleport permission, I'd just kill them to send them to spawn instead. This still has a lot of problems because of the explicit permission request, but at least it'd be possible.

 

34 minutes ago, Mollymews said:

this gets to the heart of it I think

If llTeleportAgent() requires classic PERMISSION_TELEPORT to be granted via dialog, which can be declined, then what does this do functionally that can't already be done with llMapDestination() which gives the person quite a lot information about the destination before they accept the teleport. And if llTeleportAgent() were to provide less information prior to it being activated then why would resources be expended on it

llMapDestination only works if the script is attached to the target avatar, or if that avatar touched the object in the current event. Unless you can get them to wear your thing, you cannot teleport them (potentially more than once over time). llTeleportAgent works for as long as the script has permission from the target avatar, even if they have already been teleported once.

My opinion boils down to this: Is there a strong reason for limiting llTeleportAgent to only its owner in its current form? If not, remove the limitation.

Edited January 15, 2021 by Wulfie Reanimator

[Mollymews]

6 minutes ago, Wulfie Reanimator said:

llMapDestination only works if the script is attached to the target avatar, or if that avatar touched the object in the current event. Unless you can get them to wear your thing, you cannot teleport them (potentially more than once over time). llTeleportAgent works for as long as the script has permission from the target avatar, even if they have already been teleported once.

is this not what experiences permissions are designed to do ? Grant one time with the ability to revoke, an ability which classic permissions do not provide

from a resident users pov this is the biggest issue for them with classic permissions, their inability to revoke a classic permission that a script has on them

 

[Wulfie Reanimator]

11 minutes ago, Mollymews said:

is this not what experiences permissions are designed to do ? Grant one time with the ability to revoke, an ability which classic permissions do not provide

from a resident users pov this is the biggest issue for them with classic permissions, their inability to revoke a classic permission that a script has on them

That is a separate discussion. Of course there are "better" alternatives, but not everyone can use Experiences and the owner of that Experience is responsible for any misuse, so allowing other scripters access to your Experience is not always viable either.

llTeleportAgent is not really an Experience function. It's been amended with a special exception and just happens to work well with Experiences because of the "all or nothing" approach.

The only difference between llTeleportAgent with/without an Experience should be the way permissions are granted.

The difference right now is that llTeleportAgent with an Experience can teleport anyone, while llTeleportAgent without an Experience can only teleport the owner.

Edited January 15, 2021 by Wulfie Reanimator