llAddToRegionBanList( key avatar, float hours, integer estate);
• Add avatar to the region ban list for hours. If estate is true then add to all estates.

llRemoveFromRegionBanList( key avatar, integer estate);
• Remove avatar tfrom the region ban list. If estate is true then remove from all estates.

This could save big estates from having 300 on their ban list as a script could check an external database and act accordingly. Any banned Residents could be added to the ban list for a specified time.

Extending llSensor to be able to scan a whole region for agents would help. This would mean that only one script would be needed for a whole region instead of many to cover the different hieghts and limits of 96m max range. The llSensor could return all Agents in the region no matter of their position.

I feel the above would help tremendously with the creation of better security and reduce lag in a similar manner to llRegionSay.

list the_ban_list = llGetEstateBanList();

That would allow scripted objects to view, add to and remove from the estate ban list, opening up the option of using scripted objects on different estates to sync up their ban lists.
This would be a GREAT boon to security. Not only could we use systems like www.SLBanLink.com to share bans at the estate level (thus requiring only one orb per sim, instead of one orb per parcel), but we could also start importing estate ban lists into scripts and external databases.

One could write an application that has orbs deployed in every participating estate.
These orbs check new arrivals, to see how many other estate ban lists they are on. Once they are on a pre-determined number of other peoples' ban lists, they are auto-banned.
Or you could code it to do other things, such as give a warning, or whatever.

The point is that llGetEstateBanList() opens up the possibilities for data-sharing in a BIG way.

It isn't as important as llAddToEstateBanList and llRemoveFromEstateBanList, but it is still very important.
IMHO, much more so than :

• llSetTerrainTexture(integer texture_number, key texture); Sets the terrain texture. texture_number could be defined constants.
• llSetTerrainTextureHeight(integer corner, float low, float high);
• llSetTerraformLimits(float low, float high);

llRebootSimulator() would be very useful for rebooting laggy sims or letting one's residents do that without needing to give them EM power.

list llGetTopScripts() I like the idea of, but I think this might need a llReturnObject to be truly useful.

It's a good thing, and not "ridiculous" to have to give someone the power to manage an island – an assistant, or the tenant – rather than to have the blunt axe of mass bannings – because local control – and real authentic local control by tenants, for example, of their own ban lists – means that

I've already had ample experience, for example with the sims New England, where the owner of the continent put in a friend's name to her master continent ban list merely because some other friend of a friend felt dissed by them – without any criteria, without any recourse.

So here I was, on land that I had paid for on a private island, that was supposedly "mine," being not allowed to control my ban list and entry and exit, and have to suffer the insane security-happy and arbitrary bans of a mass landowner "just because".

We definitely do not need to be putting more power into the hands of the few land barons and large venue owners and corporations of Second Life by allowing them to "throw" the client and get LL commands inserted on demand.

This sort of horrendous weapon deployment, sharing mass ban lists all over SL without sense or criteria or recourse, such as Angel Fluffy is proposing for Second Life, completely defeats the spirt of openness and creativity.

I can understand why people running rentals or who are harassed as furries or who want capture roleplay and BDSM games on their land want absolute, totalitarian control. Then...do that on your own land please, with your own tools, with those who consent to them. Don't export and globalize these tools to all Second Life islands, or sweet-talk the Lindens into incorporating this into Second Life.

Please, Linden Lab, I beg you: don't listen to the handful of landbaron security operatives here in this thread who all represent one faction. That this minority point of view could be casually incorporated into the climate as "granulated tools" without anyone being able to vote NO is one of the deepest flaws of the undemocratic authoritarian JIRA system!

Most of these mass shared ban lists you condemn previously are run on the basis of trust on other people's judgements about other Residents. Enough perceptions of unfair judgements would render people liable to stop trusting ban lists selectively.

Besides, there's a simple way to deal with unfair estate owner governments in terms of boycotting them: stop renting. stop paying the tier they don't deserve. stop visiting.

I'm terribly sorry, but I think this feeds into LL's long term plans for more governance controls to be handed over to residents, so either it or a variant of it would inevitably go through in the long run, whether you want it to or not.

-------
in case you haven't noticed, democracy in partial or non-existent form is a common trait of many IT projects with good efficiency. Too much democracy leads to 'cooks spoiling the broth'. People deserve a say in what features they want, but at some point, you need to say "Talk to the eyehand". Or nothing will change.

if you want a clear example of how people repeatedly vetoing with too many forms of appeal to hand affects software development adversely, ask any of your friends who work with Perl about the ETA on the next major version of Perl. Then get plenty of tissues for the tears of frustration and agony.

@Frans:
The estate ban/allow lists are amongst the very first things that get referenced when people teleport into private regions. Your proposal would effectively increase simulators workloads as they have to check parcel ban/allow lists for ALL tps into the island, rather than quickly choking off a TP attempt if a person isn't allowed explictly to access the region in question at estate level.

It's a nice idea, to be sure - letting land owners tp into their land holdings regardless of the estate ban listings. but this is probably not going to happen

@Prokofy
Your criticism is with the application of these tools, and not of the tools itself; it is not dissimilar to your problems with the open source client "threat." The problems you list that are present and could materialize need to be addressed in BanLink, and other such applications and uses of said tools. The fact is, SL is long overdue for these tools. I suggest you focus your efforts on either convincing Trevor of the danger and working on a remedy, or developing (or overseeing development of) a compatible system that has a more open dispute mechanism. I spoke to him during the planning stages of BanLink, and I was very impressed how careful he was being.

@Frans
Agreed.

The fiction that this proposal, Ban-Link, or GOMing of Ban-link-like functions that LL itself will do is going to "give more local control" is false – as tenants will still be utterly dependent on landlords unless landlords simply fail to use mass bans, or are willing to take numerous exceptions, petitions, and reversals – which they aren't likely to do in the name of "scale".

PatchouliW, it's a well-worn fiction that these systems are "run on the basis of trust on other people's judgements about other Residents." That is simply patently false, as incident after incident reveals. Like many coders, you are studying the system in the abstract, on how you think and hope it works, not how it works in actuality in the field.

You imagine that there are all these happy little people only trusting certain people from certain venues that they know consistenly are "fair". But nothing of the sort is going on. As Travis Lambert himself can testify about Ban-Link, everybody in the system takes EVERY LIST. They don't pick and chose because often they don't even know the people or their reputations – they simply grab every list of griefers they can grab, since they figure the more lists of banned people, the better! Fear of griefers is the psychology at work, not trust in judgement.

I've personally found over and over as I've encountered red ban lines and asked the owner why I am banned that they have no idea, have no idea who the people are whose list they grabbed, and no concept of "trust". They just grabbed lots of ban lists. And one person banning on the basis of "not liking your blog" can make thousands of people ban you not by trust, but by blind fear, which is really what is operative. Some enlightened owners, when consulted in live time, manually, might say, oh, that's retarded, I'm simply going to refuse to have people banned on the basis of personal disputes unrelated to land attacks and traditional notions of griefing, and I will unban you on your say-so – and take a second look at that particular venue's list. But most simply do not do that.

All you have to do to disprove your vaunted theory of "trust" PatchouliW is go and look at all the people who belong to Ban-Link, and grab every other list of every other Ban-Link menu. They don't even stop to consider that the diverse nature of venues, say, Shelter versus a rentals or a sandbox, might mean they shouldn't grab so promiscuously. But they do. That tells you it's a distrust system not a trust system.

If there is a critique of the use of a tool, and not enough public awareness and input on how awful it will be for all but a few landlords who wish to own Second Life, then it should not be deployed. The idea that you fix it after its uses is profoundly corrupt – it feeds into the agenda of those trying to control not only land but tool sets.

Leam,

Why is SL "overdue"? Because a handful of land barons and controllers say so? This is an entirely subjective notion.

Trevor has been subject to numerous appeals, suggestions, proposals, urgent requests – over and over, on Sluniverse.com, in person, on blogs. And he refuses to budge. The fear and hatred of griefing is so great that he and the distress griefers cause so annoying for venues like The Shelter that he feels it justifies draconian tools like this. What good is your discussion of the planning stages, when it is now already deployed, and people are complaining that it is too blunt an axe? All you have to do to understand that, Leam, is to be put on it yourself, by accident or on purpose, and try to get off it.

The idea that I can't critique a tool affecting the entire society of Second Life, that will have a profound effect on it, without becoming a coder myself, and developing a "compatible system with appeals" is strikingly ridiculous. Society can't be made up only of a tiny elite cadre of coders who decide everything about the world, and force those who disagree to become coders or kneel to their bidding. Real life doesn't run that way, and Second Life shouldn't run that way.

What's at issue here is not letting people under cover of night slip in profound tool changes that benefit only a handful of land barons and venue controllers with huge aspirations to control people.

SL is overdue for these commands because land barons need better delegation tools, the populace needs effective in-game courts, better blocking of trolls, et cetera. I would like to point out that while you accuse us of narrowly thinking in the abstract, you narrowly think about how it's applied to everyone as it applies to you. "Incident after incident," from your blog posts, nearly always involves cases where you have been banned because of your behavior or reputation. "Everyone" is not you just as "everyone" is not us or landbarons.

"Trevor has been subject to numerous appeals, suggestions, proposals, urgent requests – over and over, on Sluniverse.com, in person, on blogs. And he refuses to budge. The fear and hatred of griefing is so great that he and the distress griefers cause so annoying for venues like The Shelter that he feels it justifies draconian tools like this. What good is your discussion of the planning stages, when it is now already deployed, and people are complaining that it is too blunt an axe? All you have to do to understand that, Leam, is to be put on it yourself, by accident or on purpose, and try to get off it."

Prior blog discussions involved you telling me outright lies about Copybot and those involved, so I'm afraid I'll need some further clarification on this (in otherwords, source). I should also point out that when I discussed BanLink with Trevor, I outright let him know that I expected to end up on it someday. I had appeal discussions with him; how is it I came away confident of the system and you came away more upset than ever?

"The idea that I can't critique a tool affecting the entire society of Second Life, that will have a profound effect on it, without becoming a coder myself, and developing a "compatible system with appeals" is strikingly ridiculous. Society can't be made up only of a tiny elite cadre of coders who decide everything about the world, and force those who disagree to become coders or kneel to their bidding. Real life doesn't run that way, and Second Life shouldn't run that way."

The implication is, if moving a boulder down a hill is proving impossible, perhaps you should get another boulder. I didn't say you couldn't critique it. In fact, I feel you should constantly do so, but I question your knowledge of the topic at hand, given your past criticisms.

Society (e.g., our democracy) is made up of a cadre of people who know how to work the system: politicians. However, politicians are useless without the guidance and feedback of the populace. I don't mean to completely compare the two, but they are similar in that they are empowered enough (for various, different reasons) to make changes. I don't know, I find the concept of "if you don't like it, change it or make your own" to be pretty positive. I'm confused how you say "real life doesn't run that way" when clearly it does. Joe blow is not individually empowered to make change, so he empowers those who can.

"What's at issue here is not letting people under cover of night slip in profound tool changes that benefit only a handful of land barons and venue controllers with huge aspirations to control people."

I think you're being very paranoid about intent and you're stretching the hell out of "control people" to make a possible side effect seem like the purpose.

So I'm hardly the security-obsessive freak that is indeed paranoid and needing to aggregate and amplify and attenuate all ban lists everywhere to ban the heck out of as many people as possible.

This isn't a side effect; it's a reality we see all over the place.

Politicians are elected. They have to be accountable to the public or they are thrown out of office. Sure, they need to be knowledgeable and have expertises, and they hire legislative assistants in various areas of expertise to help. But they are elected unlike the core of people on JIRA who are deciding things here with no ability for the rest of us to vote "no"!!!

Life does indeed does not run that way. If I protest the war in Iraq, the Congressman who votes to prolong it either finds a way to accommodate this growing public sentiment, or he doesn't, but he doesn't say "Go and become a Middle East specialist, learn Arabic, and learn about missile systems before you can express yourself".

Life is not run by experts. It is run in part by experts and in part by consumers and thoughtful people who tell experts to go to hell when they run off the rails and cease to serve the public. That feedback loop, that corrective, that democracy is missing from the entire Second Life experience – and in large part because we can't even vote 'no," and such serious tool set commenting as we can do has been forced off the more user-friendly forums, and wedged into this ridiculously complex JIRA format.

I just spent half an hour even trying to find this very SVC 244 because a search on my name, on the word ban-link, and a browse simply didn't come up with it.

What's being proposed here is already possible for coders with things like libSL, or large land barons capable of paying said coders, so Prok's arguing that this gives them any capabilities they don't already have is specious. What this proposal would do is give this same capabilities to the masses. Prok would prefer to see it remain in the hands of a few elite, and anyone else be required to make these changes to their own land manually.

Prok loves to restrict people's rights. All of these are things we already have the right to do to our land, this just gives us new tools to exercise the rights we have as land owners. But, as usual, Prok is very much against allowing people do exercise their rights easily. Prok would prefer to deny us our rights to control our own land entirely, but, failing that, at least we shouldn't be able to do it using LSL scripts. That way, only those of us who can afford and/or code external processes to do this (as some of us have already done) will be able to.

That's the spirit, Prok! Keep these capabilities in the hands of just us ubercoders! We certainly don't want to great unwashed masses to have these same capabilities. I know that rubs very much against your elitist core.

This caper is very political and if it were really about some grandiose gesture of democracy for the common man, we wouldn't be seeing these land barons lobbying for it so hard.

If a few people have scripts that can mass ban on their own islands, that's their call. But by integrating this into the client, it merely makes it possible for a few more barons to mass ban the multitudes. What's really driving it, as was said by the OP, is the annoyance they experience of having to delegate island manager powers/officer functions in the group to people in order to enable them to use the ban on the various subsections of their empire. They want to mass-ban it and be done with it.

But that's precisely what runs counter to tenants and "island deed buyers" who are renters, essentially. It means instead of having to delegate the function to impose the mass ban, the master owner of the continent can just mass ban over thousands of sims if need be and never look back.

My objection in fact is made on behalf of the tenant/buyer who should retain full control over the parcel he is renting or especially BUYING, and not have some corporate faceless suit obsessed with security and buying up every device and list in town use such global banning that it starts to impact people's friends' sets.

The masses will never be using these functions to ban people. Why? Because they already have what we like to call "the ban list" duh on their land parcels and they use that, it's enough. All this would do is replicate security agencies and corporate-sponsored mass ban lists all over SL.

That's already a political statement, but let's pretend it's neutral and parse it.

o the motivation is to enable busy land barons with large holdings to avoid having to delegate ALL powers of their estates to an island manager – or tenant or sub-lessee – to insert what they wish to be their mass ban list across different holdings – or enable them to check top scripts etc. They don't like having to go to each and every individual owner or renter and give them powers of estate management to put bans across the continent in order to enforce what they wish to be their continent-wide ban, or to have them merely be able to restart the region or check scripts. It's a technique for having people own larger continents, but be responsible to them less and actually manage them less, by having people take a few of the more annoying chores off their hands – and therefore it means being less accountable.

o they want to granulate it so that they can delegate, on the one hand, but also still be able to override that person's power to control the ban list on the property and always be able to put in mass, global bans.

o therefore the loser is the individual tenant or buyer of an island property, who no longer has exclusive control of his banning, and now is subject to overrides by the master owner

o oh, this was always the case, you say? Yes, and that's what is wrong with the system now. When a parcel is sold, the buyer doesn't really control his ban list fully as the master owner can put up his own region-wide ban and override it. That's a big flaw in the system already, and this would merely deepen that gulf between rights of master owners and the buyers of parcels.

This is only useful for the Sim owners to deal with Griefer at mass. LL is already having hard time to keep up with dealing griefers everyday. Unless, Prok... you're willing to go take care of griefers everywhere everyday for all of us? I don't think so.

Just don't get yourself banned/hatered for something that you have no business with. It's no logic in that.

Gigs Taggart - I have suggestions that I think you should weight in. Everything in a list.

llEstateAccess([ List ])

list params
[ integer ACCESS_ADD_GROUP, key Group ] (To allow a group member enter in a non-public state)
[ integer ACCESS_REMOVE_GROUP, key Group ]
[ integer ACCESS_ADD_AGENT, key Agent ] (To allow a resident enter in a non-public state)
[ integer ACCESS_REMOVE_AGENT, key Agent ]
[ integer ACCESS_BAN_AGENT, key Agent ]
[ integer ACCESS_UNBAN_AGENT, key Agent ]
[ integer MESSAGE_ESTATE, string "message" ] (To send message to all estates)
[ integer MESSAGE_REGION, string "message" ] (To send message to one region that the object is currently in)
[ integer TELEPORT_AGENT, key Agent]
[ integer TELEPORT_ALL_AGENTS]
[ integer SET_COVENANT, key Notecard] (To keep covenant updated for owners who have more than 2 sims)
[ integer SET_COVENANT, string "message"] ( either way )
[ integer SET_VOICE, integer TRUE/FALSE]
[ integer SET_DIRECT, integer TRUE/FALSE] (allowing Direct Teleport or not)
[ integer SET_PUBLIC, integer TRUE/FALSE ]
[ integer SET_ACCESS, integer NO_PAYMENT | ON_FILE | PAYMENT_USED]
[ integer SET_REGION_TERRAFORM, integer TRUE/FALSE]
[ integer SET_REGION_FLY, integer TRUE/FALSE]
[ integer SET_REGION_DAMAGE, integer TRUE/FALSE]
[ integer SET_REGION_PUSH, integer TRUE/FALSE]
[ integer SET_REGION_RESELL, integer TRUE/FALSE]
[ integer SET_REGION_PARCEL, integer TRUE/FALSE]
[ integer SET_REGION_LIMIT, integer 1-100]
[ integer SET_REGION_BONUS, integer 1-10]
[ integer SET_REGION_MATURE, integer TRUE/FALSE]

and....

list llGetTopColliders() - Retuns highest 10 colliders with coordinates of object. Few of us vehicle makers gonna need that as well.

I have no objections to any of the script solutions suggested made by Gigs Taggart, Angel Fluffy, or Vincent Nacon.

Fear of abuse should not deter development. Just about every LSL feature can be abused. You can't have ying without the yang. Are you advocating then that we should remove every LSL feature that is abused? No llGiveInventory so we don't have to worry about self replicators? No llGiveMoney for fear of fraud? No llRezObject for fear of getting shot? Physics can be sent into a Deep Think. llInstantMessage and llShout can be used for Spam. llEmail & llHTTPRequest can be used for DDoS.

Giants and windmills indeed!

But then, I know some people can be a fool to trust such item given to them, so yes, should have permission call first.

This would be a double call for ensurance, same owner and permission call. Not sure about those who are granted as Estate manger though.

Whatever, I just want it now so I can deal with grieffer from distance.

Unfortunatly, Don said that the "estate" side of things will likely not be scripted, because it causes hits on central servers. The "Region" side of things, however, should be ok to export via LSL, but might be better dealt with through some kind of new fine-grained delegation instead.

For my purposes, either way works.

Top scripts and top colliders should both return something to the effect of integer num_top_scripts where you fetch an individual entry with something like llGetTopScript(integer top_script_num) to retrieve name/location/owner/actual script time info. This would let you iterate through an entire list if necessary. This list should be sorted top to bottom by script time so if you only want the top 10 worst script you can get them, or if you want more you can have those too.

This also allows more data per item than is sane within a strided list, and prevents the return of data you dont want. You can simply check for laggy scripts by polling for the number 1 entry at a fixed interval if that entry is below your script ms cap then everything is good and the server only needed to pull up one thing rather than 10 things every query. This is all assuming the server caches this statistics ahead of time rather than generating them on the fly.

I understand if people have issues with the action-based LSL commands, but at the very least I think everyone can agree to allow informational-only commands such as top scripts and total sim object counts broken down by person, etc.

I will also ad that the stop script feature shoudl be added so when a griefer attacks we can have an object in the sim stop teh scripts till we get there.

I would alos like to see a return by sim owner function so we can write scripts that only allow people on a white list to keep prims rezzed in a sim, and lets others only rez for a certain amoutn of time. I know tere is the return objects function with a timer, but for many having to join a group to rez vendors is a pain especially for vendors. I white list is so much simpler.

Give the sim owners more management tools and there will be less problems in our sims.