Feedback on proposed Teleport Home changes

How does an age limit help prevent griefing? I've been griefed by AV's that were only a day old. On the other hand, it's possible for someone to have been around for a year but never have done any building or scripting. I'm not familiar with the Cabinhead project, but I'm of the opinion that SL should be a wide open place where everyone can explore and enjoy the creations of this vast community. I HATE being locked out of any place. I do respect people's privacy, but if nobody's around, what harm is there in my exploring their land? They might get some dwell points from it.

This is a little off-topic, but how is anyone even supposed to know about places like Cabinhead, where there are such restrictions? I would pay virtual $$ for a sim-by-sim listing that details purpose, restrictions, etc. so I'd know places I'm supposed to avoid.

Simply removing or altering the function does not necessarily alleviate the problem completely... The steps you've outlined result in TWO dialog boxes being popped up on the client of someone who's just flying over. These popups require user attention, and are almost as annoying to me as being ejected or TP'd. There is, after all, more than one way to grief.

For instance, I could write a script that even without the ability to teleport, pops up a dialog asking "Are you gonna get the f*** off my land???" over and over, blasts the user with IM's and chats, rezzes boxes around them, etc.

So, removing or crippling this function MAY have the opposite effect to that intended, and actually EXACERBATE the problem as people find new and original ways to protect their little kingdoms. The only way I see to fix this is to a) provide better land controls built right into the client and b) re-enable P2P teleporting so that you're not forced to fly over land where you're not wanted.

I am 100% in favor of deprecating the llTeleportHome.

As an alternative, you could have a confirm box "teleport agent X home", yes or no, that appears on the script owner's screen. If the script owner presses YES, then the teleport happens. If the script owner isn't online, presses NO, or does not respond in 30 seconds, then no teleport. (The script owner, not the land owner or script creator. The script would also have to be set to the same group as the land.)

That would enable the use of the function in scripts that are useful to for defending events and clubs.

(This would a start, but it wouldn't be enough. Push scripts that unseat you from your vehicle are almost as disruptive as llTeleportHome.)

Buster

To be fair, llDialog would likely not be what's ultimately used. So we're on the same page, an implementation by the Lindens would likely be in the form of that little blue "error" box that appears and cleans itself up.

And, to be extremely blunt, there are plenty more things to be offended by in Second Life than griefing with two Dialog boxes. I mean, seriously. Storm of dialogs, maybe. Two, too bad.

My question: Why can Linden Labs not enforce TOS policies on abuse of this function rather than removing it?

Is llPushObject next on the list?

Let's see. 32,000 Active Users per month... and fewer than 100 Linden Labs employees. Only a portion of those are Liasons (Read: CSRs).

Hm...

Suffice it to say, a compromise is in order. Same with llPushObject if it had no recourse - but it does in the form of sitting a non-physical object.

Im up for forcing a 10 second sleep befor the command checks your on the land and tp's you home. That on its own will stop a fast ammount of abuse.

Staffing issues don't make for good arguments. There are numerous methods within SL which can be used to grief in ways worse than llTeleportHome. If they can't manage their users, removing this is only going to show people that they're incapable of enforcing TOS in general.

Ive heard rumors of a "Per parcel shared memory system".
If this is true, there will eventually be functions that are specific to using it.
llTeleportAgentHome() could be one of them.

This would

1. Require the owner of the script to be the owner of the land it is on same as it is now.
   
2. Allow for scripted lists for things like, employees control, etc. same as it is now.
   
3. But doing so, It could have the added hard-coded warning and delay, and store its results in the Parcel shared memory. Thus not allowing multi threading.
   
4. Doing it this way should not require any changes to existing scripts.
   

Also please keep in mind that Teleporting via a request, LM, or simply clicking a location on a map is just as prone to crashing. And the difference with this function is ONLY that by using it, the crash-ie didn't willfully initiate the teleport attempt , and may feel frustrated by that especially when it fails in the "client crash" manner.
The ultimate fix of course will not be related to any "duct tape" methods.
But I'm confident that LL is doing a great job at continuing to increase the reliability of all things SL, with the happiness of there residents in mind.

Added to this though there SHOULD be a simple llTeleport(vector RegionCorner, vector Pos);
Requiring PERMISSIONS_TELEPORT.

This is probably the best solution, since it usually takes less than ten seconds to fly over a property if you are going about your business.

Ok. This discussion goes round and round. I'm going to post here on it to repeat what i said the other times as well, just in case someone did not see it.


This is not about one function.

This IS about the security functions of SL. Period.


Under no circumstances should USER END SCRIPTING be allowed to send someone somewhere without their forgone request. You can't force animations on people, there are rules to turn on and off damage with a warning icon, and I can attach things to your av without you knowing.


Period.


Now, what we DO need is a set of land tools that allow true security without breaking the sim and social structure.

We need built-in land tools for the following:

Secure land: Stops people from crossing unto your land up to a resonable height. Also should prevent POV shifts so that the camera is inside the land as well. Prims sent across the border should be returned instantly, as if a return time of .1 second to prevent probes and box-sliding into the land. Physics effect from outside the land do not enter
Fade Land: Makes all avs and prims on the land fail to be sent to clients that are not allowed to normally enter. The av CAN enter, but will see bare land. In addition, those inside cannot see avs who enter the faded land.


Now, these two options do not prevent people from dropping C4 and making an ass of themselves outside, or stop a 100 prim torus chain from crashing the sim.


So limit the CPU usage as well:

Allow 90% of the CPU power to be distributed among the land owners in an even fashion based on land ownership.
Allow 10% of CPU to go to wanderers who are travelling outside their land, for scripts on avatars.
Allow any 'slack' CPU to go to whoever needs it.

The CPU goes to scripts and physics, and would prevent overuse by limiting the CPU to what the SIM can handle.



So again, this is NOT about a script command. This is about a good way to allow security without stifling creativity and freedom.


Later all.

I dono, I've just had a thought, because someone said that 'a teleport home script that gives enough of a warning for people to clear out on their own would be ineffective against griefers'.

I was thinking of two seperate implementations - a script call that gives, say, a 30 second warning to clear out(and has a sleep afterwards of course, that goes without saying), and a pie menu item, accessable only by landowners, that teleports home, or to a nearby telehub as a compromise, immediately. In this way, if someone is being an immediate and aggregious threat/problem, the landowners can remove them with minimal difficulty, but no immediate teleporthome can be automated in a script.

Excellent points, all. However, what can LL do RIGHT NOW in the next release, and what takes longer. We need a quick fix if we can get it.

Your land tool suggestion:



I think makes perfect sense, if it could be done. 100% in favor of this! (Make it a proposition and I'll give it all my votes, and all my alts' votes as well!)



"This" problem, right. However "this thread" *IS* about one function. Specifically, should LL deprecate llTeleportAgentHome LSL function in 1.7. Regardless of the need for better land tools, where do you stand on deprecating llTeleportAgentHome without permission?

If I understand you:



You would be in favor of deprecating this function, or at least making it inoperative without a permission of some kind. Right?

Buster

P.S. Still haven't sold the cliff-side temple. Its almost the only thing I have left, but I like it so much I can't part with it. You are THE ARTIST!

Security scripts that send people home are troublesome to many folks (though I would rather wind up home than bounced around a sim). My general feeling is that we should eventually get rid of any opportunities for security scripts to cause undue difficulty to folks who are just minding their business and sightseeing or flying somewhere by helicopter, completely oblivious to whatever the security script is intended to protect. BUT I also realize that people need a better resort to griefing.

The single effective tool I have found for dealing with griefers is calling a Linden, having the Linden arrive and then stay around awhile. This in addition to diplomatic efforts has helped us to solve issues with griefers on multiple occassions. Perhaps if the Ban option were strengthened (to keep griefers off property up to the stratosphere and keep them from having the ability to lay, send or fly any objects onto your land?) that could take the place of troublesome security scripts.

I have had two nasty experiences with security scripts, once where I was bounced around in my own home sim between two different security scripts (feeling rather like a lunch sack in a game of keep away on a grade school playground). Another when, though we built a lovely landing pad for friends with Helicopters and planes, we were having a very tough time being able to actually land anyone at all because they were blasted by a neighbour's security script. (To that neighbour's credit she did try to add regular guests of ours to her list, but we found it too difficult and eventually scrapped the landing pad alltogether.) Let's make BAN effective enough that people will not need to keep the equivalent of an H-Bomb in their livingrooms as a reinforcement for the "police".

*wishes she had a Ban function on her office*

I would not like to see this function go away without a good substitute. Calling a Linden is just not fast enought to rescue an event from a griefer.

Oh the other hand, I do hate being on a long flight and getting bounced back home, then having to start over. A ten second sleep with warning sounds like a good compromise.

Would it not be easier just to restrict the use of ANY weapon or push effect ( you know what I mean) to restricted area designed for war games and such. Thus removing the ability for anyone to used them on your land or public land? Why are we in SL? Those who want to express their immaturity by annoying others should packup and go play with their friends, if they have any.

Or, as in Robocop, implement a Linden Automated Police Force that would rez-in instantly when called. Then the "LAPF" wold simply scan the inventory of the griefer and delete all weapons from it. that would be for the first offence. If the griefer re-offends, the account of the griefer should be terminated. SL should be able to provide security to users who don't want to play silly war games or be victims of griefers.

One issue with the current set of parcel tools we have today, is that the height limit for restrictions seems to be taken into account as a static value - and doesn't consider 'ground level'. This is a problem for anyone who has a parcel that doesn't start off at 0m. Another reason some folks resorted to using security scripts.

By 'Ground Level' - I mean, the highest point of ground on a parcel that can be terraformed. Most sims are +4/-4 in terraforming.

If Land-Ban is intended to extend only 30m in height, that 30m should be computed from the highest ground on the parcel. Making this sort of change would make land tools more useful, without harming casual flyover traffic.

This would also break legitimate uses of llPushObject (flight assist scripts come to mind, but there are others). The objection most of us seem to have is that getting rid of a troublesome function rather than fixing it is a bad precedent to create. Getting rid of even more functions to try to fix the overall problem is exponentially worse.


So you press a button and something shows up and deletes every item using llPushObject from an avatar's inventory? What if this person isn't a griefer? What if the person calling LAPF is a griefer and just managed to delete the latest project of a perfectly friendly avatar? There isn't an AI sophisticated enough to distinguish griefer from non-griefer.

Getting rid of functions and items indiscriminately isn't the answer. More tools, adequate tools, and proper and prompt enforcement of the TOS is the answer. There is ALWAYS another way for a person to abuse another person. If pushing goes away, they'll spam with chatting objects. If object chat goes away, they'll flood the world with millions of textured particles. If particles go away... you get the idea. If we take away every method of potential griefing as it occurs, we'll end up immobilized in the welcome area with chat disabled.

There is no good technical means of removing griefing from the game. Until the day when humanity is ruled by benign AIs (and we all pray that day is soon), humans have to make the call. Destroying LSL functionality doesn't help anybody.

This still sets up a 'flat city' sort of schema for most areas of you want to be effective in your bans. Chris referred to places where the ban as ineffective as "Estates in the Sky" - which is hardly the case. The ban height is lower than most buildings; I believe it was 20m, not 30m. In either case, even while in or on normal, rather low structures, banned avatars can still hover a few feet away from the people who they wish to bother.

On another note: Buster - you said we need to be sensitive to people who are in SL for "another experience" than ours. If this 'experience' is devoted harrassment, and getting a kick out of it; no, I'm not going to be accomodating of that. And I don't know why you think I should.

Kali: sorry, I did not make myself clear.
If i'm on my own land, and a griefer comes by and start using weapons of any kind on me, I want a way to make the griefer gone. Thats all. The only time someone (say avi A) could use such a function is when one (avi A) is on his own land, against someone (griefer)who is using weapon against (avi A). This could be a land option. You want your land to be safe, then no aggressive action against you should be possible.

Of course, I don't know enough about the workings of SL to know what is feasible or not.

You're absolutely right, Michi... I wasn't considering Island Sims, or 'Estates in the Sky' when I made the suggestion.

Another idea then (Actually this is one of the suggestions from prop 244 ) - but I'm not sure how technically feasable this is:

-Allow us to create a 3D bounding box where parcel restrictions are active

combine that with: Limit a maximum size of this 3D bounding box, proportional to the size of the parcel.

Thoughts?

bit of a problem with that heh... volume and area scale differently as sizes increase... area goes up by n^2 where n is the dimension of a given area... while volume goes up by n^3... this makes scaling how much you could effectively lock down or restrict on a given parcel very complicated, to the point probabyl few people would really be able to understand what was going and what would or would not protect them

How about a 'police force' of invisible Lindens who can wander around and take action against any griefers they see? Such actions, witnessed by official Linden staff could result in immediate banning, no exceptions. Heavy-handed? Yes, but I daresay, it would eliminate griefing entirely.

LL staff workload and hiring limitations.

I got it, but remember, anyone can make changes to the wiki if you see a mistake.