Jump to content

Discussion on a change to llTeleportAgent().


Recommended Posts

So as mentioned in today's server meeting, a change to llTeleportAgent() is being worked on apparently.

There were concerns brought up about what limits this function should have in regards to teleporting someone to somewhere not owned by the same land owner.

I think a destination should either be same land owner owned or public access or accessible to someone in the land group the destination uses if not public accessible.

I do see some good uses cases, but it would be a shame if the grief potential, even while land owner operated, outweighed the benefits.

What are your thoughts?

Link to post
Share on other sites
  • Replies 63
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

yes. Same with llSitOnLink. Personally I think Linden should remove all the text about permissions from the Experiences dialog. The text says nothing about force teleport or force sit. If it was my de

I do feel that I am repeating myself lately, land owner authority should not be negociable. I don't like llTeleportHome specifically because it is the only power we actually have, and as a result, t

How is "teleport home" a partnership exactly? I keep asking for milder options and people always scream that it will be abused, and as a result teleport home is still the only option and also the nucl

I think the griefing potential is majorly curbed by the permission requirement, and the fact that it cannot teleport avatars that aren't in the same region. (So you couldn't grief someone remotely.)

What I would want most is teleportation of anyone (with permission) within the current region.

From there, I'd want intra-region teleportation without permissions, but I don't think that's ever going to be possible without an Experience.

And least importantly (for me), teleportation of anyone (with permission) to any landmark.

Link to post
Share on other sites

some thoughts

the proposal is a departure from action permissions to beyond parcel security concerns

the implications of breaking action permissions in this way, means that an agent's presence on a parcel is permission for the parcel owner to apply an action to an agent beyond a security concern

i am in two minds about this. I get it from a parcel owner's pov, moving people to where the parcel owner wants them. But the whole point of permissions is that the person being acted on currently has some say in this via a permission request: either standard or experience

the way the system works now is that when a person refuses a permissions request then we, as parcel owner, can then view the person as a concern and remove them from our parcel

and I am not sure that being able to make permission-free portals that are not bounded to at least an implied permission would necessarily be a good thing

if this were going to be introduced then I suggest that llTeleportAgentToDestination(...) can only work in a collision event. The collision of agent with object being the implied permission, enabling portals to operate in the way that the person ordinarily understands them to. The object in this case being non-physical and non-moving. Being able to get teleported by a moving object (a bullet) should remain as a Experience-enabled action

 

edit add. And also in touch events. Agent touch also being considered as  an implied permission

Edited by Mollymews
  • Like 1
Link to post
Share on other sites

I am not in favour of adding more ways to teleport people without explicit permission.  I feel that after previous discussions that even llTeleportHome() is overkill and can unnecessarily impact a person's enjoyment of SL.  This potentially random teleporting people around without warning is worse and could make them leave SL altogether.  Especially the people who are here to explore.

There is no inherent way to know with this scheme that you would be on land with objects that do this and that is a big problem for me.  Perhaps if there was a way to tell that parcel was able to do this, something that had to be enabled that people looking in "About Land" from the sidelines could look for.  That would still leave private regions, so I guess those would have to be marked as well, so you could look before you teleport.

Obviously I have considered that some people may want to participate under these terms so...

Perhaps if the viewer had a setting called, "Allow random land owners to teleport me without warning" that could be turned on or off that would satisfy both sides of things.  That way people who want to participate in this are not going to have to keep giving permission.

I guess the future direction of that option could be "Allow land owners to do whatever the hell they want to my avatar without warning".  So there is that.

Edited by Gabriele Graves
  • Like 2
Link to post
Share on other sites

Further thoughts, as much as I dislike places that use Experiences, at least you are aware at some point that there is one being used before anything has an effect on you.  This is a good thing because it gives a heads up that there maybe things going on here you possibly don't like which is my cue to leave.  That part about Experiences is actually good though the information you get isn't anywhere near enough about what it will be used for.  This other proposed scheme is actually a step backwards for that reason.

  • Like 1
Link to post
Share on other sites

I do feel that I am repeating myself lately, land owner authority should not be negociable.
I don't like llTeleportHome specifically because it is the only power we actually have, and as a result, the only one we can use, even for minor transgressions.

I still can't see the "potential for griefing" everyone is chirping about when you can just "leave". Please provide examples.

  • Like 2
  • Haha 1
Link to post
Share on other sites

If I had to change anything...

I would make in sim teleports more of a move than a whole entire "teleport". I could think of a dozen uses in a game or combat zone for instantaneous teleport movement without the delay of having land again etc.

Griefing with the standard permissions version is almost non existent

With the experience version. Just leave the experience if someone abuses it.

In all the years I have been in SL since llTeleportAgent was introduced I have yet to be griefed using it.

If they want to change anything how about finally letting us rotate avatars via scripting without having to sit on something?. Or maybe finally come out with that idea they promised about letting us slow down and speed up animations via script. Or, now they have the new modern shiny amazon hardware....give us bigger region sizes to play with. 

  • Haha 1
Link to post
Share on other sites

I mean if we are on this subject. Lets just have a thread hijack moment and go...

-Bigger region sizes 512x512

-Improved scripting editor

-Revamping prims or introducing new prims and giving them basic mesh modification capability (points and verts)

-Split the viewer into two programs.

---One for the explorers, bloggers and fashionistas that contains all the photo tools, inventory etc features that is much lighter in weight.

---One for the developers that includes all of the above and a built in avatar animation studio, enhanced prims, improved scripting editor, lots of debug features, on (enhanced prim) texture painting. F-it we will just steal a whole idea from Roblox and call it SL Studio. Idk...

-Voxel Regions (Too much?). probably wouldn't work...

-New notecard object that lets you write to a notecard. Could call them Storage Cards. Idk...

-Lower the price of land again now you are saving more money. Pass some of that back to us..

-Global experience keys....been years since you promised and then forgot about this

Or maybe I have just gone mad......

As you were

  • Haha 1
Link to post
Share on other sites

this kind of change is not about griefing, is about user permission

SL is built on the concept of user permissions, that there is a partnership between landowners and their visitors and I think we need a really good rationale to do away with this partnership

looking at the use case from the old school perspective of partnership. Message: "The region is lagging. Could you help out please by going to our alternate landing area". llMapDestination()

portals tho I could see being a good thing. But to stay with the concept of partnership then the suggestion of implied permission. Walk into the portal and we will get teleported. People ordinarily expect this to happen when they do

  • Like 1
Link to post
Share on other sites
3 minutes ago, Mollymews said:

SL is built on the concept of user permissions, that there is a partnership between landowners and their visitors and I think we need a really good rationale to do away with this partnership

How is "teleport home" a partnership exactly? I keep asking for milder options and people always scream that it will be abused, and as a result teleport home is still the only option and also the nuclear option.

Edited by Kyrah Abattoir
  • Like 2
  • Haha 1
Link to post
Share on other sites
5 minutes ago, Kyrah Abattoir said:

How is "teleport home" a partnership exactly? I keep asking for milder options and people always scream that it will be abused, and as a result teleport home is still the only option and also the nuclear option.

teleporting somebody home is because we, the parcel owner, have a concern. Accordingly we remove the concern from our parcel

the effect of the proposal is that moving visitors within the borders of our parcel without permission is a convenience for the parcel owner

most people when given a llMapDestination dialog and a reason for it, will take it. Some don't and when they persistently don't work with us, the parcel owner, then they can become a concern

in the olden days llMapDestination popups at busy landing points used to be a common thing. Not so much these days

Link to post
Share on other sites

I can't see any option other than home.

Let's assume that region A has an agreement with region B that any people unwelcome in region A can be TP-ed to region B. But after a change of ownership, Region B decides not to have unwanted visitors and puts up the dreaded "you have entered private property" orb. So the people lobbed out of A then get bounced out of B, and usually end up at home anyway.

Home (or the nearest safe hub if home is unavailable) is the only destination you can be certain will a) be there and b) accept them gracefully.

Link to post
Share on other sites

The permission system doesn't work properly. Once you have given a permission to an object you can't withdraw it.
The experience system works fine here you can withdraw the permission every time.
So I would give an experience permission or map TP but not a normal permission to an unknown object. Just saying.

And an expansion to the TP home/eject? Will be used like unwanted TP offers I assume, just more effective.

Link to post
Share on other sites
12 minutes ago, Profaitchikenz Haiku said:

Let's assume that region A has an agreement with region B that any people unwelcome in region A can be TP-ed to region B. But after a change of ownership, Region B decides not to have unwanted visitors and puts up the dreaded "you have entered private property" orb. So the people lobbed out of A then get bounced out of B, and usually end up at home anyway

the proposal is that the destination parcel can only be same owner even when on another region. For the reasons that you mention

if not same owner then visitors could end up being ping pong balls. Parcel owner sends unwanted visitors to the neighbour's parcel. Neighbour starts sending them back to the parcel they came from. Boing boing boing

same owner prevents these kinds of things from happening, even if unwittingly

 

i will just add on a thing here about design.  When we want to perform these actions on our visitors then ordinarily we ask for Experience permissions. When the visitor accepts then we and they are good to go. When they don't  accept then our design falls back on standard permissions, knowing that our visitor is going to get a lot of dialog permissions requests. Something which they have chosen to be given, by not granting experience permissions

Link to post
Share on other sites
4 hours ago, Profaitchikenz Haiku said:

I can't see any option other than home.

What about somewhere else on the parcel? Something infinitely less agravating than being given the boot.

  

3 hours ago, Mollymews said:

the proposal is that the destination parcel can only be same owner even when on another region.

I'd be okay with that.

Edited by Kyrah Abattoir
Link to post
Share on other sites

Under this proposal a land owner could ping-pong someone all over the place constantly.  The hapless victim would have no way of knowing that this land owner gets their kicks this way.  People may not want to "be on your land" especially if you are doing this but the problem all along is "how to I avoid land and people like this" before you go onto someone's land?

Come up with a proposal like I suggested where a person can see exactly what they are crossing over into whether it be land parcel border or teleport (ie. on the map) and my objections would go away.  I don't want to go to places like that and I suspect many others don't either.  Give us a way to avoid you and you might have something.

Just because someone cannot see a problem, doesn't not mean a problem does not exist.  A person who has skin in the game often doesn't want to see an problem with it.
 

  • Like 1
Link to post
Share on other sites
6 hours ago, Profaitchikenz Haiku said:

I can't see any option other than home.

Let's assume that region A has an agreement with region B that any people unwelcome in region A can be TP-ed to region B. But after a change of ownership, Region B decides not to have unwanted visitors and puts up the dreaded "you have entered private property" orb. So the people lobbed out of A then get bounced out of B, and usually end up at home anyway.

Home (or the nearest safe hub if home is unavailable) is the only destination you can be certain will a) be there and b) accept them gracefully.

Often a teleport home is a logout for a lot of people and recently it is happening to me a lot where it never happened before.  That is why force teleporting anywhere sucks big time.

Link to post
Share on other sites
13 hours ago, Kyrah Abattoir said:

I don't like llTeleportHome specifically because it is the only power we actually have, and as a result, the only one we can use, even for minor transgressions.

llManageEstateAcess is a good alternative if you're an EM or EO for the region you manage.

Tbh, the limits put on place of llTeleportAgent are fair and can easily handled via an Experience. If land owners getting too out of hand (anymore than they are already able to) with it, you can simply not go to their land. I do believe it should be restricted to EMs and EOs though and not just parcel owners.

Link to post
Share on other sites

I'm not entirely understanding the proposal. Does it:

  • entirely obviate the need for a landowner's script to obtain PERMISSION_TELEPORT (which must be the case if it's supposed to be an alternative to llTeleportAgentHome)? or
  • merely allow agents who have granted PERMISSION_TELEPORT to be teleported by scripts owned by the landowner (rather than only by scripts owned by the agent being teleported)?

If it's the former, and intended to substitute for llTeleportAgentHome (and/or llEjectFromLand), that use case would be quite constrained by requiring the destination to be land owned by the same landowner, wouldn't it?

If permission is tacitly granted by collision-related events, that enables the "portal" applications where I'd use it, but collisions are pretty easy to arrange, so it's not really a significant hurdle beyond merely detecting the agent's presence as with llGetAgentList.

If permission must be explicitly granted, It wouldn't add much value over using an Experience, at least not for me. I guess it might have value for folks who own land but won't use an Experience. And the permissions dialog would look less scary than the fine print on the Experience permissions dialog (but that's really a problem with Experiences, not with llTeleportAgent).

Thinking of implementation, determining whether a destination belongs to the same owner should be easy if that destination is on the same region as the script, but personally I'm mostly interested in the function for inter-region portals, so I wonder how much overhead would be incurred to check land ownership on a different region. Especially if the destination region is lagging. Or down.

On Mainland, we'll always have microparcels (most of which only exist to grief) so unless the function requires an explicit permissions grant, I'd suggest limiting it to only work on parcels of at least 512 m².

Edited by Qie Niangao
Link to post
Share on other sites

Ok, having gone and read the bug report (duh, should have done that sooner), I realise I've misunderstood the issues. If the idea is that a landowner can teleport anybody on their land to anywhere else on their land, it makes sense to me. 

The permission popups are annoying in this case (and useless when somebody has TP-ed in and is bobbing up and down a metre above the ground still chatting in IMs to somebody else, oblivious to the popups, and not clicking on or colliding with anything to initiate the action ).

I see it as a valid action given LL implements a "landowner makes their own rules and can implement them" approach. The one grey area is where the person is TP-ed into a cage or trap, which is ( I think still?) a violation of the ToS. In that case it's up to the objector to actually object.

I think it must be limited to a destination in the same region, for both implementation issues and also to avoid confusion in those who have been TP-ed.

I can see it being useful not only for maintaining control over staged events where you don't want plonkers dropping out of the sky into the action, but also it would be a better way of enforcing the private-property rule by simply moving the trespasser back outside. In such cases I do think an explanatory message is required, which could be an optional argument to the function, such as llTeleportAgent(outsideTheHouse, "I'm sorry but that is private"); 

I'll vote for it (or, given the topical situation, I'll not vote against it).

Edited by Profaitchikenz Haiku
correcting the typos I made in the first edit when I corrected the typos I made in the post
Link to post
Share on other sites
9 hours ago, Qie Niangao said:

If permission is tacitly granted by collision-related events, that enables the "portal" applications where I'd use it, but collisions are pretty easy to arrange, so it's not really a significant hurdle beyond merely detecting the agent's presence as with llGetAgentList

 

Thinking of implementation, determining whether a destination belongs to the same owner should be easy if that destination is on the same region as the script, but personally I'm mostly interested in the function for inter-region portals, so I wonder how much overhead would be incurred to check land ownership on a different region. Especially if the destination region is lagging. Or down.

on the first then yes true

with collision restricted to non-physical and/or non-moving objects it would be pretty easy to technically circumvent this restriction if we had a mind to do so. Altho I think that such a circumvention would be seen as a community violation, warranting the removal of the device from the parcel by the police and/or an owner censure

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

 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...