Land Owner Forced Teleport Home

[Lindal Kidd]

6 hours ago, BilliJo Aldrin said:

People complained about my hornet swarm pushing people to the property edge. I wonder if I should enable life and script the hornets to do damage, so that after so many "stings" you die and are sent home.

Talk about realism 😆

 

[AlettaMondragon]

On 9/25/2020 at 8:10 PM, Nick0678 said:

Now regarding ban lines they are practically useless when it comes to Mainland Regions due to the rules and conditions that Linden Lab has set in regards to their usage.

In the provided photo i am in a Mainland Parcel that has Group members access only enabled (=ban lines enabled) and although i am not a group member as you can see i am inside the parcel and on that persons platform (could be a skybox or whatever, the form of the object doesn't matter.)

 

That leaves the parcel owner security system with 2 options, either use llEjectFromLand  which in this case if someone has Movelock enabled is practically useless because the avatar will be back on the platform with 1 second or use llTeleportAgentHome and send me to my home location making it a little harder for me to come back each time that i am send back home.

If LL decides to remove llTeleportAgentHome then the only realistic option that this parcel owner will have when someone enters their Mainland parcel and doesn't leave, will be to file an Abuse Report and wait until a Linden will be available to come and set things straight (= more work for linden support personnel and more frustration for the parcel owner.).

Such commands exist for a reason and will never be obsolete.

 

There really isn't too much use of the way banlines work on Mainland, but it gives many people the (false) feeling of privacy and security. So much that they don't even care about any other land settings, so you can rez and keep objects on their lands even if you're not on the actual parcel. People can squat on such parcels easily, they just cannot log back into or teleport to the parcel. BUT if you aren't on the parcel at the time someone would enter (let's assume aircraft or random noobs first instead of malicious attempts like squatting and griefing), would you need banlines going up to 4096 or more meters? The whole concept is a huge failure, since banlines up to 50m are just as unnecessary when the landowner or those that they personally allow (group or whitelist) are not on the parcel.

Banlines could easily work up to any height solely in the allowed people's presence, activating automatically once they enter the parcel, and deactivating once they leave, on parcels set to restricted access, so undesired interactions with avatars would be prevented (well, actually it's still a ridiculous concept) when it makes sense, so when there's someone to protect.

Since you don't have to prevent interactions with strangers when you're not even on your land, that's when banlines are useless, whether they reach up to 50m or any height. That's when malicious attempts like rezzing griefer objects, or people trying to squat on your comfy, big, mostly empty parcel come into play. And the land settings are perfectly able to prevent any of those, except a really few cases (like a replicator attack).

Those that really think they need security orbs and banlines to work on their land when they're not personally present, are simply paranoid, can't use the available tools properly, and certainly try to compensate for some deficiencies, which results in the "I pay for my land, I can do whatever I want, and I'll use automated settings and devices to kick people from my land, trap their loud helicopters on the middle of my land, and collect as many as I can before my land gets filled up, even if I haven't logged in to SL since 2013, but my bank account gets drained to keep up my tier, or I actually log in to this day, but never spend a moment on this parcel" mentality. Thank goodness this is actually not the majority of people, only those with real problems.

In my opinion, it's really not the actual tools that mean any kind of problem, but the way some people use them. Anything can be misused, and many ignorant people manage to do so. What's even better, they're totally fine with it.

In your example with movelock vs eject, if you get banned by name, you won't be able to stay on the parcel. If you happen to, by some weird glitch, and the owner of the parcel wouldn't have the TP home option, you'd have to log out eventually, and wouldn't be able to log back onto the parcel, and after a sim restart which would log you out, same story. Or you'd simply get bored and TP out yourself. However, the ability to manually TP home an unwanted person is convenient (for both the landowner and the unwanted person) and the most effective and reliable way to get rid of them, so it would be a shot in one's own leg to remove it.

Actually, without a direct TP home function, they could still enable damage and kill you shamelessly, maybe after throwing you around with pushers for a few seconds/minutes for fun, but this was already mentioned in this topic, so a sidenote is enough for it. So there aren't just your two options to get rid of someone.

[AlettaMondragon]

On 9/25/2020 at 8:36 PM, Pussycat Catnap said:

Anything above 0 is too much time for any situation in which you actually want a person removed.

In any situation you want a person removed, you should be able to do so by pressing a button yourself, you don't have to set the orb to do that automatically in every situation.

[Nick0678]

12 hours ago, AlettaMondragon said:

Those that really think they need security orbs and banlines to work on their land when they're not personally present, are simply paranoid, can't use the available tools properly, and certainly try to compensate for some deficiencies, which results in the "I pay for my land, I can do whatever I want, and I'll use automated settings and devices to kick people from my land, trap their loud helicopters on the middle of my land, and collect as many as I can before my land gets filled up, even if I haven't logged in to SL since 2013, but my bank account gets drained to keep up my tier, or I actually log in to this day, but never spend a moment on this parcel" mentality. Thank goodness this is actually not the majority of people, only those with real problems.

 

Well let's not start calling other Second Life users and in this case a specific group of Linden Lab Premium members as "paranoids".

In case some people don't understand it Linden Lab is a corporation and Second Life is a product. That means all those Premium Members are paying customers not freeloaders and have purchased the right to have that piece of virtual land and use it always in accordance with the TOS.

 

Of course if  Linden Lab doesn't want their money because they "buy the land but rarely login and/or have a security orb always on", it can easily stop taking those real US Dollars from them and redistribute their lands.

In regards to the rest of your post those are some interesting views and solutions.

---------------------

I case the Security Orbs or the llTeleportAgentHome feature get removed (which they won't and we are theoretically talking here), all those people are welcome to have a home in the Private Regions home rentals market. Usually most Region Covenants and Rental Agreements are formed in such ways to cover peoples needs for privacy, security and always with respect to their hardly earned real money that they choose to pay in order to have a nice SL experience.

[AlettaMondragon]

1 hour ago, Nick0678 said:

Of course if  Linden Lab doesn't want their money because they "buy the land but rarely login and/or have a security orb always on", it can easily stop taking those real US Dollars from them and redistribute their lands.

Honestly? If they pay, they pay, I really wouldn't care either. They pay for the service even if they aren't inworld, so that part is fine. However, on mainland, what happens on their land will affect at least the direct vicinity of their land, and other people, so they are responsible for it. Especially rights come with responsibilities, and it applies to services and use of services between a provider and customer. It just depends on the provider how they want to enforce their own terms. LL doesn't have terms regarding inactivity, so reclaiming lands that are paid for but the owner is inactive isn't an option. Just don't think simply by paying for premium and their tier (there are many large parcels on mainland with the owner absent since 2010-2017) they are clearly supporting LL and SL. If they failed to at least set up their lands properly, it can cause damage, and extra work for LL, again and again.

[Qie Niangao]

Inactive owners are relevant here because if they never visit the parcel anymore, they'll never notice a change in what access control measures are available: If llTeleportAgentHome() no longer did anything, they'd never know.

What's more, I suspect it would be years before a substantial majority of landowners who regularly use their parcels would even notice if llTeleportAgentHome() stopped having any effect. Sorta doesn't matter, though, because some certainly would notice and have the functionality deeply rooted in their expectations about how to manage visitors.

That's what I think was truly ingenious about the Belli constraints on access control measures: even though they weren't so constrained when Belli first opened, the change came quickly enough that there weren't already established expectations about the now missing controls.

By analogy, if Mainland had changed years ago to disable some controls such as llTeleportAgentHome(), the product would be more successful now -- but it does not follow that changing those controls now would still have a positive effect, after buyer expectations have crystalized for years.

[Pussycat Catnap]

I decided to get rid of the old security orb I used by a company no longer in SL that... took about 1mb of script memory to use between two objects (a configure box and an ejector box. The ejector being deeded to group on group land).

I wrote this tiny script, that does NOT need to be deeded to group unless you also want to ban people:

 

list approvedNames = [
    "Governor Linden",
    "Pussycat Catnap"
];
integer findApprovedName(string thisPerson)
{
    if (llListFindList(approvedNames, [thisPerson]) != -1)
    {
        return TRUE;
    }
    else return FALSE;
}

testMemory(integer bumpUp)
{
    llScriptProfiler(PROFILE_SCRIPT_MEMORY);
    integer usedMemory = llGetUsedMemory();
    llSetMemoryLimit( (usedMemory + bumpUp) );
    llScriptProfiler(PROFILE_NONE);
}

default
{
    state_entry()
    {
        llSensorRepeat("", "", AGENT_BY_LEGACY_NAME, 23.9, PI, 1.0);
    }
    sensor(integer detected)
    {
        integer agentNum = 0;
        testMemory(5500);
        for (agentNum=0; agentNum<detected; agentNum++)
        {
            string thisAgent = llDetectedName(agentNum);
            if (!findApprovedName(thisAgent))
            {
                llSay(0, thisAgent + " has been sent home.");
                key ejectedPerson = llDetectedKey(agentNum);
                llTeleportAgentHome(ejectedPerson);
                llAddToLandBanList(ejectedPerson, 0.2);
            }
        }
        testMemory(1500);
    }
}

The first difference is this one uses up 8kbs.

But...

This is a teleport home script, with no warnings and little delay (1 second at most).

As some have noted, you often don't get the delay. That's because it's just checking every time delay and then shoving anyone not on the list out.

To give a person an actual wait period of X seconds, I would have to track them in a 2 variable objecty: key and count. add 1 to the count every second until count was X, then zap them...

- This can make a script start getting complex and hit a stack heap error unless you do a lot of management to avoid that, because LSL is very bad with list management...

I think that is why the old one I had used 1mb of memory... it had to do things to avoid stack errors.

 

Also note that I've set a radius. 23.9. That's because it's inside of a 48m box - so it scans ONLY the inside of that box.

- again the brand I used to use let me set coordinates for 6 directions: x,y,z in +/-... and that is NOT how sensor works, so I suspect it was running 6 sensors all at the same time to scan out from itself in each direction along a limited arc...

- Most security orbs just take either a radius or the parcel.

 

Note that I zap them with:

llTeleportAgentHome(ejectedPerson);

And then a 0.2 hour ban (that's a 12 minute ban). The ban is to avoid instant returns - but because a ban bans for the whole parcel I don't want it permanent. I could set it lower too... 0.1 would lead to 6 minutes. In testing I used 0.02, or 1 minute, on my alt).

 

Instead of using:

llTeleportAgentHome(ejectedPerson);

 

You could use:

llEjectFromLand(ejectedPerson);

- this just tosses them outside of the parcel to a nearby height (I'm not exactly sure).

 

llTeleportAgentHome(ejectedPerson);

does NOT require deeding to group even though the lsl wiki says it does. I haven't tested

llEjectFromLand(ejectedPerson);

 

If you wanted this to be on a 15 second timer, just use:

llSensorRepeat("", "", AGENT_BY_LEGACY_NAME, 23.9, PI, 15.0);

- but do note that if someone arrives in second 14, 1 second later they get zapped. To avoid that needs a more complex script tracking individuals (not too complex, I've got a visitor logger and a script use meter that both track people, but they come in a lot bigger in kb usage). Basically just a lit that has something like:

list peopleOnWarning = ["you resident", 5, "them resident", 3, "some fool", 14];

and the sensor adds one to the value each second, then if the value is ever >= X, it instead zaps them.

Otherwise every scan, if a name found is NOT in the list, it gets added with a value of 0 as well. The LSL wiki talks about using stepped lists like this - but if this thing gets more than a handful of entries your script will crash from a stack heap error... so you might want to early 'force zap' the highest numbered people if the list has more than 10 people on it...

 

You might also want to put in a line like:

llRegionSayTo(ejectedPerson, 0, "You are not allowed here and will be teleport out soon");

to it somewhere...

 

 

[Mollymews]

9 hours ago, Pussycat Catnap said:

I wrote this tiny script, that does NOT need to be deeded to group unless you also want to ban people:

just a FYI.  For llTeleportAgentHome to work, the script does need to be owned by the parcel owner. Deeded to group if group owned parcel

agree with you that simpler scripts are better than complex scripts for doing simple things

 

[Pussycat Catnap]

10 hours ago, Mollymews said:

just a FYI.  For llTeleportAgentHome to work, the script does need to be owned by the parcel owner. Deeded to group if group owned parcel

agree with you that simpler scripts are better than complex scripts for doing simple things

 

That's what the documentation says.

But on group owned land it was still able to teleport people home without being deeded.

It does need to be owned by someone in the group with 'eject' powers I believe. I've yet to test it with an alt lacking such to see if I've found a bug...

What got me motivated here was the realization of how 'bloated' the orbs I've been working with are... but also... I just wanted to show the 'under the hood' of this whole topic.

I personally feel the best solution would be to limit "llTeleportAgentHome" so that it can ONLY be called from inside of 'sensor' as I have.

 

- That prevents parcel wide zappers. because sensor is called by things with limited range. People would then have to pick a space to be policed.

Then we get into the whole debate about time limits, and if there should be a minimum height.

My stance on those...

no time limit if called by an object above 2000m. 30-second limit is called by an object below.

- but setting this up code wise would be a little more difficult, requiring a few changes to LSL...

 

(the easiest is to make a new function:

llTeleportAgentHome(key, delay)

where if the second argument is missing, it is presumed to be 30.

and if the function is called by an object below 2000m, 'delay' is set to 30 if it was below that.

- and then the delay is tracked on the backend of sl

 

Edited October 1, 2020 by Pussycat Catnap