Feedback on proposed Teleport Home changes

Okay so this has turned into a large issue with some hot headed and very emotional feedback on both sides... i want to kind of step aside form that and list the basic problems with the function, with its removal, and with how this was handled overall really.


Okay so the function has issues... we've known its had issues for a long while now.. it crashes clients... it offers little warning or recourse.. it can be tossed in a 1 second repeat sensor on a 16sqm plot to watch wacky hijinks ensue.. etc...

So at some point *something* is going to have to be done about this... it *DOES* need to not be what it is right now, today... it needs to be changed, and its potential for abusive use needs to be drastically cut back.


On the flip side of this issue though... removing it completely is bad... very very bad... and i think there needs to be some serious discussion done here...

One thing i think LL didn't necessarily realize is that this is viewed, with good reason.. as the *SOLE* effective counter to griefing in SL today.

(Reasons i say that)



So what do we have left? the one tool that actually *does* work.. and has proven effective... send home via script...

This has been used by basically *ALL* of the mainland theme areas, as its effective, it can be scripted by a group so that all trusted members can use it, something which is NOT true of mouse-pie wheel things...

When someone has been sent home, by in large they have STAYED there, since coming back would be relatively arduous... unfortunately thats one of the main reasons its up for the axe


some jerk can leave it out there in a repeat sensor to just POUND people with and crash/annoy anyone flying overhead with zero warning and zero recourse...

so yes... that is *BAD*


but to just remove the tool... and literally.. the only effective defense SL has to offer to the majority of its users with very little warning, no initial calls for feedback... and no general discussion.. thats... that is far *worse*


now.. as per feedback here are some basic suggestions worked up among some active users, in just a few minutes with varying degrees of difficulty to implement understandably.

some of the ideas for changes:



anyway

there are FAR more ideas out there but overall i think this is just indicitative of a general overall hiccup... essentially LL didn't think this *was* a big change.. it was a small tweak to a single lsl function, nothin to get in a tizzy about... except... players obviously felt *very* differently about this...

theres a lesson or two here



anyway i hope this can be in the end for the best... But it has ended badly before.. the female sit is a good example of that that 1.5 years later has *STILL* not been really addressed from a real 'lets make things better for all sides' kind of perspective...

anyway.. eltee out.. hope this can help overall

I believe this to be THE most crucial part of all of this. Obviously this is a bug and needs to be fixed. Or if not a bug, its a poor handling of teleports on SL's side.

I agree with everything else. We have a Feature Feedback forum specificly for this type of thing.

Things like this have happened in the past, scripters have complained, LL has said "Ok, next time..", yet, here we are again. While we did get SOME warning, use the tools provided to give us better time to give input, PLEASE.


Edit To add: I've been one who have complained about the security scripts, but taking the function out IS NOT the solution.

A delay would be a nice alternative. Atleast temporarily if not long term.

I just want to pick on this eltee. 1 second repeats are not needed for this function to cause clients to crash or force people to relog. A single, isolated, teleport home can cause the same thing to happen in my experience - and with quite consistent regularity.

Interestingly I had a griefer visit me with a push gun today. I ejected them from my land, I muted them, I did everything I could. A Linden turned up and the griefer disappeared. Then later, guess what, the griefer returned and used his push gun on me from the neighbouring plot. So no, I don't believe that teleporting home would really make any difference here. This griefer came back later to continue what he'd started earlier, he made the effort

I agree that the ban height limit is totally pathetic but that still would not have solved my problem today. And nor would teleporting them home.

You can't say teleport home works, because the implementation is so awful that even a single legitimate use can cause people to crash or relog. The Lindens removing this simply says to me that it is a function that cannot easily be rectified and as such, must go. Which probably has a lot to say about teleports in general. I mean, they've not been exactly trustable in the last few months, have they.

from what i've seen a single use is no more or less destructive than clicking somewhere on the map yerself, an picking teleport... take that for what you will...

and as to saying it works.. its not flawless, its not 100%, prolly not even 50%, but when the other tools we have are not even 10% at best... its still the best of the lot

Why oh why can't the fix entail a 10-second, hard-coded warning prior to the function going off? We have similar delays in other functions, and deprecating it completely just strikes me as a terrible idea.

Same thing with llEjectFromLand. 10-second, hard-coded warning and cooldown delay within the script. What's not to like?

I realize that privacy is a big issue in Second Life, but this has struck me as the compromise that should be shot for. Deprecating the function directly means breaking countless security scripts, leaving residents to bear the burden of fixing and replacing all of them.

The result? Well, let's just say I would invest in the pitchfork and wooden torch market early.

Edit: Plowing happily along -


I agree with eltee on this. The problem is not "the implementation," but rather its strain on the asset server. Looping the function constantly as it is now throws several requests into the pipeline (sometimes double or triple on one agent), causing a crash. A delay would fix this.

Abusive teleports are a major strain in their frequency as well. Joe RandomGuy flies over a plot and gets the boot. Expand across 700-sim grid where roughly 5% of the population have some form of security script. A delay would fix this, vis a vis social engineering.

But teleports don't always work, do they? It strikes me that deprecating this function is partially covering that fact... and with the shift to Mono coming in August, I see this as a short-term fact and outright reactionary fix.

Reactionary fixes being the bad kind.

I think a delay and forced warning through the function would be the least invasive, most effective solution. Removing such a commonly-sold function will play havok on the economy unnecessarily. And that, to me, is a big deal.

I'll take that for what it is - teleports generally are not trustable and cause many people, still, to crash or relog. That's what I'm saying, the function is only as good as the underlying action, and the teleporting action (although I beleive it has gotten better) is not consistent. The problem is that when people purposefully teleport themsleves they have no one else to blame, when they're teleported forceably by somebody else, they do. Which is why I suspect this function is being removed.

As an addendum, one additional fix I've mentioned for some time is the ability to detect sensor scripts. This would allow autopilot scripts to figure out areas to avoid completely on their own, and solve a lot of the problem.

However, this sort of thing could be potentially abused, specifically in games. So it's a mixed bag.

The two are totally the same from where I'm standing. If the implementation of a teleport is causing a strain on the asset server that it cannot cope with then the implementation is not suitable.

Indeed. Hence suggestion for 10-second delay, similar to those enforced on llGiveInventory, llGiveInventoryList, and until recently, llGetNextEmail. All asset strain "fixes."

Of course, I believe you're referring to the implementation of the actual "crash" problem. I'd like more data from the Lindens to make this assessment, but I feel it's no different than a regular TP... and if you do, indeed, crash from it - you're given a 10 second recourse to get the hell away first.

This change greatly greatly hampers the concepts behind our Cabinhead project.

The intention was to restrict the island to users under 90 days old, and to allow instructors the full ability to remove problem users at any time, making Cabinhead an ideal setting for new user classes. Instructors will no longer have the level of crowd control that was to make running classes a much less stressful experience.

In addition we can no longer continue with our plan to make it a new user only zone, as there is no way to automate enforcement of this policy. Manual removal by instructors, even if they could remove them now that there are no tools available, just provides more possibility for tension situations.

The security system as written gave users older than 90 days 5 minutes warning before sending them home. It gave removed users 2 warnings to leave, and a 30 second lead time. It was more than accommodating as far as giving users a chance to leave on their own.

This function has been in SL since summer of 2003, why is there such a rush to remove it now that its being done without a replacement? I understand that there have been issues with abuse on the mainland, but removing this function without a providing a replacement function leaves many legitimate users open to stressful situations.

Replacement idea:

Have a 2 part function, part 1 warns of the coming TP, then a 30 second sleep, then if the user is still on the property a TP sent, followed by another 30 second sleep.

I must say I have found this function very helpful to me. If stuck somewhere, or locked in, I can use this rather than logging off and trying to get back into SL. We have had a few issues with relogs (3-4 hour attempts- solved now !). And wouldn't the misuse of this function be a suspension offence?
I know some of you remember when Teleporting was such a great tool, we had to pay by the metre to use it. Which led to people Inventing air travel Which led to free teleporting, which... I agree that details need to be worked out, but eliminating it is not the answer. Thank you for your time.
- Z -

According to the wiki there already is a 5 second delay after calling this function.

http://secondlife.com/badgeo/wakka.php?wakka=llTeleportAgentHome

Which, by my reckoning, already makes this one of the most delayed functions in SL (apart from llEmail as far as I'm aware). llGiveInventory = 3 seconds delay. llGiveInventoryList = 3 seconds delay. In fact, here's a list of delays according to the Wiki:

http://secondlife.com/badgeo/wakka.php?wakka=ScriptDelay

It's the 4th most delayed function in SL. You could delay it more, sure, but you're referring to a delay before th function executes rather than the current delays which occur after execution.

But I'm talking about teleporting in general leaving you in no mans land, crashing the client or causing a relog - either forced or requested teleporting - a 10 second delay would make little difference to this unless teleports were near 100% reliable. It doesn't need you to use this function, a single teleport can do it to you anyway when you click a teleport button.

To be absolutely honest, I don't understand the whining associated with this function. I've never been telported home while flying, I have been ejected half-way across a sim on numerous occasions.
As I see it, it's simple: if I enter your land, without your permission, you may send me away. No discussion.

However, having said that, a warning would be appreciated. It also has to be admitted that llTeleportAgentHome could be better. Some suggestions:

1) Why can the function operate on agents NOT on the owners land, so long as the script is. It should have the same limitation. You don't have any right to eject people from neighbouring land.

2) How about changing the function to require a message telling the agent they are being returned and why.

3) A short delay (2-5 seconds) before activating the teleport. Giving time to leave of your own free-will and/or read your message.

4) An enforced sleep (same as above) after the function to prevent over use.

5) Limit the range (although the functions needed to detect agants should be enough for that)

Another thought, if teleporting an agent home is soo bad, why isn't it reportable as a ToS abuse. And in some situations, like flying over property at 512m, shouldn't it be an abuse!

If only motor vehicles cause death on the roads, should we remove them from the roads?

You'd of thought so, wouldn't you. When I had cause to use it I quickly found out that llOverMyLand is extremely buggy near sim borders, telling you that an avatar is over your land when, in fact, it's returning true when the avatar is actually over neighbouring land in the next sim - go figure! Doing an llDetectedPos() you find out that the avatar's position has negative numbers in it which indicates it's not even in your sim



That's a good idea but would only work with a pre-delay



Yes, that's what Jeffrey is suggesting as well as I understand it. It still doesn't get around a single teleport having the capacity to crash or cause a relog though and, as I've said before, people don't have a hate figure (past the Lindens) if they've enacted the teleport, they do if they it's forced upon them - which is where the angst comes from.



Already exists, see my previous post on this thread.



Currently you're only really limited by sensor range and although it would be good to limit range, that may not be feasible over larger owned land masses.



Why isn't it? My guess is because LL know that the reason it causes so many problems is because it doesn't work correctly, because teleporting doesn't for many people. The simple solution? Remove it entirely. Saves any abuse reports for it that way.

This is a very, very bad idea that takes away from a landowner's property rights. Wholesale ejecting or teleporting everyone from one's property without any warning is wrong and should be a punishable offence - just as shooting down planes that fly over your house is in RL - but we should and must have some way to remove individual troublemakers.

Perhaps. The operative word is highlighted.

I feel the difference here is this delay should be before the function is called, not after. You seem to have noted this.



Here's the workflow I feel the function should follow:

1) Function invoked.
2) Function calls llOverMyLand with key given.
3) If TRUE, continue. If FALSE, silently fail and return from function.
4) Function uses key given to the function to llDialog user with warning.
5) Function sleeps for a set delay. In context of my description, ten seconds.
6) Function invokes llOverMyLand with the target id given, to see if agent is still there.
7) If TRUE, teleport agent home. If FALSE, send user llDialog thanking them for leaving.


Now, I can do this already - easily. The problem is many people don't bother to do so.

For sake of argument, this is exactly how to do it now:

FixedTeleportAgentHome(key id)
{
     if(llOverMyLand(id))
     {
           llDialog(id,"This land is protected. Please leave. You have ten seconds.", ["Okay"], (integer)llFrand(100000) + 10);

           llSleep(10.0);


           if(llOverMyLand(id))
           {
                 llTeleportAgentHome(id);
           }
           else
           {
                 llDialog(id,"Thank you for leaving. Please do not return.", ["Okay"], (integer)llFrand(100000) + 10);
           }
     }
}

Enforcing this level of restriction would be more beneficial, IMO, while being less invasive to boot. Ten seconds isn't a lot of time to "see anything" before the function punts someone. Conversely, you can cover roughly a sim in that space of time with default flight speed.

I'm not seeing any hassle with this implementation; however, I see major problems with removing it entirely. What do you think?

Allow AV's to use on self and only on self. Other than that, get rid of it finally! No good reason to have it.

I would say only have it if

A) person is on the ban list and you are not present
B) You are present to activate it.

No reason to have teleport home and a push script if you just "don't want anyone on your land" and you are not around to enforce it.

Yeah, then why did the last dozen time I used it on greifers was it so effective?

The problem isn't with llTeleportAgentHome, it's with its abuse and the abuse of llEjectFromLand and llUnSit.

Unintentional abuse, but abuse none the less.

As I see it, two things need be done. Priority is a matter of timing, IMHO:

1. Change the TOS to clearly define the border between use and abuse of these tools. Immediately enforce these rules. Warning will probably suffice. Suspensions almost certainly.
   
2. Give us land tools that work. Make it so people can get the privacy they want and the anti-greifing tools they need without having to use scripts. I'm happy to occasionally rebound from a bit of locked out land. Barely effects me. But to be unsat and tossed... that's just annoying as hell.
   

1 first only beacuse it's so much easier, but we do so very much need 2.

The way the script function works should be modified. Some people like the idea of keeping people off their land. Others think the whole function should be removed. I just think it should be modified so that the object says "Please leave this land within 10 seconds or else I will have to eject you" that way the person has a fair warning before they decide they don't like the function.

Amusingly, I just realized they're discussing exactly the fix I presented, roughly when I posted. Great minds think alike!

I strongly disagree with removing llteleportagenthome().

If it's crashing clients, the corrent solution is to *fix* the client so it doesn't crash. There is good reason that it should be possible to crash the client with calls from llteleportagenthome() or any other script.

Otherwise, there is no privacy in SL short of buying your own island sim, setting it invisible, and kicking everyone out. US$200/month is not feasible for many people, just to get a little peace and quiet.

For what it's worth, when I go anywhere, I travel at 1000m. This is safely out of the range of anyone's security scripts.

Chris Linden, you are hearing from a small but vocal minority on this issue who have vested interests in keeping the script, either for ideological or economic reasons.

I'm appalled that Cabinhead is going to use a bounce script even with a warning, as a means to keep their "helpers" over 90 days on an admit list, and everybody else they can't grab and usher into their economic networks facing a push back home. This absolutely sucks.

I speak as a landlord to hundreds of tenants on numerous sims who nightly IM me to complain about mistreatment at the hand of overzealous bouncescripters.

The use of the bounce script as an attack weapon to bounce without warning and bounce all the way home merely because you are flying around exploring is a crime. It is using a weapon in a safe zone.

All these very interested scripters can think about are their love of war games and various other projects they have a vested interest in either for financial or reputational reasons. But that's a minority of lots in the game. Most people want to have a residential or entertainment experience inSL free from the griefing that this "security from griefers" in fact perpetrates on others.

Linden Labs needs to step up to the plate and get rid of this monster. It is symbolic of a lot of what is wrong with the game -- people so obsessed with their right to swing their arm that they have forgotten about how that right ends when another person's face starts. They reach off their land to bounce and send home without warning, making many people all around them angry, frustrated, and simply prepared them to log off this game -- sometimes for ever.

I implore LL, on behalf of numerous tenants, owners, and neighbours on the sims where I work, to proceed with plans to remove this function from the game. If you have to cave to this hysterical lobby of a small minority of scripters with vested interests, than at least announce that bouncing all the way back home without warning is bannable and enforce that as a TOS interpretation with bans -- that doesn't require any scripting or programming work on your part but just an iron will.

I'd like each and every person sounding off on this issue to come and have the experience of being aggressive hit and returned in this fashion as we do every night, and then talk about it. Most are speaking about it as an abstraction they are furiously defending merely as a tekkie obsession, and not looking at the reality of the experience for most people.

What's also interesting about everyone sounding off on the tekkie issues is that here, they throw away the fiction that they are willing to consider having notification and not bouncing home, and throw away the fiction of considering "just one button for the avatar" to push to get "no push," but they start vociferously defending the push script home as a means of legitimate security against griefing.

It never stops griefing, which usually occurs randomly, and once to most of the people using the scripts. It is not an effective tool. And all it does is harass others exploring SL, and serve as a tremendous source of anger to neighbours.

Get rid of it.

If we start getting rid of every potentially abusable LSL function, we're not going to have many functions left. If the Lindens are saying that there is a certain set of rules under which this function must always be used, then the correct solution is to change the function so that it follows these rules, just as Jeffrey says. If the function is broken and may crash clients, then it needs to be fixed. Buggy functions aren't the scripters' fault. We can use only the tools we're given.