You need to understand that while the fix breaks all these phased chair items, the bug itself breaks EVERY sensor based item in Second Life. There are a lot more of those than there are phased chairs.

You refer to it being possible to sense everyone on your land even if they are using a phased chair, but in order to do so you need either a network of sensors, or an object that continuously moves around sensing repeatedly in order to get the desired effect, which is a much laggier system. If you've ever seen a "full-sim scanner" in action you'll know why this is an absolutely disgusting alternative as those things cripple script performance.

And you are a content breaker. Don't come here and advertise on this page.

Saying that the "bug" (which is a highly debatable term, as many of us believe it to be a feature) breaks, as you say, "EVERY sensor based item in Second Life" seems to be a bit of an outlandish statement, especially when you do not provide details explaining how you believe it does so. And were it really true, would we not have have heard a million complaints about it throughout the years?

Why do you feel this feature is a "broken behavior"? Why is your "fix" a much better solution than simply leaving it be? Exactly how does the feature break "EVERY" sensor-based item in SL? How does your "solution" ensure privacy, especially in light of the fact that as implemented, your "fix" allows a griefer to freely attach unwanted sensors to an avatar which follow said avatar all over SL, and allow the griefer to use various weapons against the affected avatars without any means of defense? And what exactly does the comparison to a "full-sim scanner" have to do with this feature?

While using these and other emotionally charged words like "disgusting alternative" and "cripple script performance" is certainly entertaining, by not really explaining yourself and the technical basis for your beliefs, your argument seems, well, meaningless.

So please, by all means, "educate" us.

@Tessa Wycliffe:
"Why do you feel this feature is a "broken behavior"?":
Before this was fixed you could do the following:

• Set up a sensor based script that reports items within its sensor range
• Sit on a "phased chair" that is outside the sensor's range, but places you within its range
• You won't be reported
  This is broken behaviour as it is NOT correct within the parameters of a sensor's definition (it should report EVERYTHING it is asked to that is within its range).

"And what exactly does the comparison to a "full-sim scanner" have to do with this feature?":
If this fix is removed then in order to detect an avatar using a phased chair you would have to create a network of sensors, a moving sensor, or some combination thereof.
"Full sim scanners" are products which scan the contents of a simulator by sending out "probes" which move around the sim using sensors to detect avatars and reporting their locations back to the scanner itself. They are incredibly laggy; there are many such devices which (using default settings) can be placed into a simulator and cause script perf to go up by 20,000 or more. That is a MASSIVE amount of scripting work being caused by a single item. Do you want every security device maker to employ such measures just to detect people using a product which exploits buggy behaviour?

We're talking about requiring a horrible work-around to detect avatars using broken behaviour to hide themselves.
The issue here therefore is not that the broken behaviour is needed, what is needed is a way to hide yourself from malicious objects.

Darling Brody wants this fix reverted so she can continue to sell an "anti-griefing tool" which is just as easily (and much more often) used to harass people in public places. SVC-1462 is much more reasonable, since it'd be available to anybody without requiring them to spend L$ on Brody's weapons or knowing how to exploit an LSL bug, as well as regulated by land and estate owners.

Haravikk said:

@Tessa Wycliffe:
"Why do you feel this feature is a "broken behavior"?":
Before this was fixed you could do the following:

• Set up a sensor based script that reports items within its sensor range
• Sit on a "phased chair" that is outside the sensor's range, but places you within its range
  • • • • - You won't be reported *****

Asterisked for emphasis

"Phased Shields" became useless about the same time llGetObjectDetails was added as a scripting function. Once someone has your name (which can be aquired via sensor, listener, etc.) you can not go anywhere in a sim or an adjoining sim (within 96 meters of the first) and be safe.

As for protecting against being orbited. LL provides a tool for that to every resident. Just rez a cube and sit on it.

And thank you very much Thraxis, the same solutions that scripters can use to "fix" their scanner-based products to work with phased-chars can also be used by griefers to attack people on these chairs as well. Fixing the sensor bug has done nothing to make anyone on phased chairs more vulnerable.

1) Post with more clarity to avoid confusion
2) GetObjectDetails has not been used by griefers as of yet, if it has then it is not being heavily used yet
3) All noob garbage does not use GetObjectDetails, so phased is still a viable defense

Since you've cherry picked which of my questions to answer, can I assume that there is no answer to the others?

Your definition of the feature as a "broken behavior" is still incomplete and very bothersome, because it is still quite simply subjective. What you believe, others will not, and vice versa. And to exert and exact a result affecting thousands of others just to conform with a subjective thought is reckless at best.

I highly doubt that the common security orb maker will ever need to concern themselves with trying to detect phased chairs moving through protected homes. That's operating under the mistaken assumption that everyone wants to use a phased chair to become a peeping Tom. This is patently absurd, as most homes sit unoccupied most of the time, and even if not, what's going on inside is too deathly boring to even care about. Do you get excited at the sight of two cartoons "boinking"? I doubt many others do. Even so, if one was so inclined, one could quite easily use the simple, extremely cheap (as it's included in the client) camera to spy on housed avatars, rather than spend $2500L or more to do it. Do we get rid of the long range camera next?

And how can one "not be reported"? You see someone going against TOS, you report them, phased chair or not. What's the big deal?

But the biggest hole in your argument is that if an orb or other tool scripter cannot figure out how to write an efficient program to detect phased states, you believe that is the fault of the operator of a phased chair regardless of its use rather than the scripter. You're blaming the hammer because it does the work that the operator causes it to do. That's the operator's fault, not the hammer's. Place the blame where it truly lies and quit trying to break other users' tools simply because you don't know how to program for phased states. Will you try to ban any and all things that don't work within a rigidly defined set of parameters (and as defined by whom, exactly?) that you feel they must?

I think I understand your main concern. On the surface it's about accountability, yet ultimately it's about control. Yet you are essentially asking Linden Labs to deliberately break a lot of existing, expensive tools in order to accommodate your desire for control and lack of programming ability.

@Schwartz Gustafson:

You say "Darling Brody wants this fix reverted so she can continue to sell an "anti-griefing tool" which is just as easily (and much more often) used to harass people in public places." You have facts and figures to back this assertion up? Darling has over 1000 customers of QC. How many of them are griefers? And exactly how much time does a griefer use QC to grief, rather than Belias, or Ownage, or Lilith, or any of the countless other combat HUDs available, many which have true griefer features that QC does not?

@Thraxis Epsilon:

If phased shields are indeed useless, why create a "fix" then? And fine, sitting works for orbiting. But what about other attacks commonly seen in most any sandbox? The orbit or push is only used by the newbie griefer. More experienced, malicious griefers use sim flooders, avatar deformers, chat and inventory spam, followers, and other things, more than they do orbits, and they are just as bothersome and in some cases even more so than a simple orbit.

@ALL:

Above all, if some petty griefer is so inclined to grief, they will find a way to do so regardless of how many features one tries to disable. It's been a cat-n-mouse game since the beginning of time, and will continue to be so till the end. One can grief simply by moving around rapidly and bumping every avatar in sight. One can grief by typing certain words and phrases in simple chat. In the never ending quest to eliminate so-called "problems", you will eventually destroy so many features of SL that it will become a sterile experience for the user, and they will find somewhere else to play, and Linden Labs and SL will fall into the dust it rose from. Is that what folks really want to have happen here?

sitting on a wooden block is boring, I like having the ability to enjoy Second Life without worrying about someone putting a follower on me while i work.

@ Websnake

I second that.

"Your definition of the feature as a "broken behavior" is still incomplete and very bothersome, because it is still quite simply subjective"
In computing terms a bug is basically anything that causes a piece of code to operate in a way which prevents, circumvents or otherwise hinders what is considered to be normal operation of a system.
In this case, sensors are "the system", normal operation for them entails detecting things within their detection range. The bug therefore allows people to circumvent this clearly defined normal behaviour by allowing them to be undetectable to sensors.
"Hacks" such as llSitTarget() and warp-pos are not bugs as they do not actually circumvent any clearly defined limit. In the case of llSitTarget(), you are still sitting on the object, just at a much larger distance than anyone expected, but no-one said it had to work within 10m or anything. Similar for warp-pos, the only limit is that PRIM_POSITION may not move an object by more than 10m, but if you put PRIM_POSITION in more than once you get a cumulative effect.

"And how can one "not be reported"? You see someone going against TOS, you report them, phased chair or not. What's the big deal?"
Read my earlier comment to Websnake, the word "report" is not exclusive to abuse-reporting, and if you read where I said it it should be perfectly clear. I get the impression a lot of people are skim-reading comments and misinterpreting them as result. Please read things twice if it doesn't make sense instead of immediately replying with whatever springs to mind.

"But the biggest hole in your argument is that if an orb or other tool scripter cannot figure out how to write an efficient program to detect phased states, you believe that is the fault of the operator of a phased chair regardless of its use rather than the scripter."
There ISN'T an efficient way to detect phased-states, heck, most of the "work-arounds" won't even work with 100% of phased-items. The way it works is that the phased item places you a distance from the object such that the object and avatar can NEVER be within a single sensor's range at the same time. The result is that it is impossible for a sensor to EVER detect someone on a "phased" item under the old behaviour, because sensors couldn't detect child-objects if the root-object was outside their range.

"I think I understand your main concern. On the surface it's about accountability, yet ultimately it's about control. Yet you are essentially asking Linden Labs to deliberately break a lot of existing, expensive tools in order to accommodate your desire for control and lack of programming ability."
Linden Labs has already done it, fully aware of the issues. It is regrettable that people have lost money, but it's the fault of the item creators who charged such ridiculous prices for items which relied on what was clearly a bug.

@Darien Caldwell:
SVC-1462 is hardly a "red herring", nothing within it amounts to anything remotely close to "god-like", all it does is give users the invisibility that we should have. You can make yourself invisible on Yahoo Instant Messenger, do you honestly believe that that is somehow "god-like"?
As for the argument against "newbie" items, it only takes is one griefer to get their hands on a free script that uses llGetObjectDetails() to track someone, and start distributing it for free and the phased chairs become useless again anyway. All undoing this fix will achieve is the re-introduction of a bug that doesn't actually protect you from griefing. All the griefers need is to get your key once and they can target you.

Defence:
1. stop yourself being attacked in sandboxes when building (turn off select distance limits in Client menu)
2. avoid follower traps
3. come back to the sim you have been orbited (or other attack) from by a griefer and observe/retaliate - note retaliate could mean ejecting them and banning them within ToS).

Griefing:
1. Launch attacks while phased so undetectable, unless opponent is using more than one sensor to detect the griefer (can also be done via weapons that fly around searching for AVs)
2. Observe others undetected, ie. surveillance (you can also do the same thing with a listen relay and/or alt camming)

So, bearing in mind that being phased itself is not a weapon, it simply allows you to be hidden and the griefing uses can still be done via other methods and other legitimate uses are being broken (such as teleporters) I believe that limiting llSitTarget is of only minor effectiveness and not worth the cost.

Although by no means scientific, every time I've been griefed it's always been idiots who have a freebie weapon and have no idea about phasing. When I have been attacked by a determined griefer they have simply seeded the sim with spam and hunting cage weapons and the like then left.

"legitimate uses are being broken (such as teleporters)"
llSitTarget() has NOT been limited (all my teleporters still work). The bug isn't that sit-targets can be really far from the object, the issue is that sensors don't take sit-targets into account when scanning. SVC-125 called for sensors to be fixed and it seems that they now are.
The only "legitimate" use was in evading primitive griefing tools, but that was flawed as it doesn't really help much and only underlies the need for better tools to defend yourself with, such as the one that SVC-1462 is proposing.

Ah, but while I agree with your points, you're reinforcing my argument.

Since most griefers use simplistic weaponry (in my experience) they won't have the means to use anything as well thought out as llGetObjectDetails(), and the griefers who do have some understanding (or better tools) in my experience seed a sandbox with a load of hunting drones anyway or some other wide scale attack, not pick out individual targets.

If a well thought out proposal for an alternative defence feature was implemented at the same time as this feature being removed I would probably have no issue with it - however since the feature was scaled back and we have to get any such additional defence approved separately all that's happened is make griefers lives easier since they can still attack and stay out of sensor range by using other means.

Also, your suggestion SVC-1462 won't work, it would just be turned off by every land owner, just like Push is.

"Also, your suggestion SVC-1462 won't work, it would just be turned off by every land owner, just like Push is."
I commented in the issue itself but as a summary; land-owners have no reason to turn it off, as their items aren't affected. For sandboxes (where all this trouble seems to occur) it would pretty much become a necessary feature anyway since people wanting privacy from scripts would complain to the landowner to enable it.

As for griefers, I don't know much about the weapons they use, so I suppose my question would be: what would be a more common occurrence, someone using sensor avoidance to avoid a griefer, or someone using sensor avoidance to violate someone else's privacy?

Something tells me it'd be the latter.

@Websnake Nightshade
It is good to finanly see someone who understands the way it works and what it can and cant do. So much mis-information is posted by hysterical people who have been frightened by rumors. I honestly think people should have to pass a scripting test before they are permitted to comment/vote on scripting topics in the JIRA. All too often the facts get lost in the opinions, and good features get broken.

@McCabe Maxsted & Others
You cant use a phased chair to violate someone else's privacy. This was the part people didnt understand in the original JIRA issue. I am sure this lack of understanding was the reason people voted to have it fixed.

A phased chair will NOT hide your name tag or make you immune to land tools like Ban and Eject.

A Phased chair will only prevent scripted objects (mostly free griefer toys) from being able to harass you.

This provides you with privacy from being bothered by other peoples scripted objects. Be it a notecard giver, or an anoying follower object, you should have the right to choose if you want to interact with scripted objects. The Phased Chair was the only thing that gave you some control over this.

A properly scripted Land Security device will still be able to detect someone using a phased chair. For example my "Prim Bin" product is able to detect and eject people on a phased chair without using llSensor or llGetObjectDetails! Anyone who is already selling a scripted security device who would like to know how to do this need only ask me, and vote YES on this issue of course.

This function is just as usefull and widly used as the hack called WarpPos, which also breaks a rule. "No object can move more than 10m at a time". WarpPos is a bug. WarpPos is a hack. WarpPos adds desperatly needed flexibility to LSL, and so do Phased Chairs!

Darling

Phase Functionality is almost exclusively a peaceful, passive, protective or defensive technology.

Phase functionality not only helps protect users against unwanted physical attacks in SL but also helps protect user privacy. Many times we prefer not to be "scanned or monitored or followed" by someone or anyone. Many times we do not want to be "watched." Seldom do we ever want to be "stalked" or "sexually harassed." Sometimes it is nice to be able to evade a trouble maker without being forced off a SIM because someone else is acting like a jerk or griefing or assaulting. Having access to phase functionality enhances our possiblity for a greater degree of privacy and safety and enjoyability of our SL lives while elminating the threat to most attacks by using Ghandi type passive response!

Apparently, certain FOR PROFIT product sellers are trying to remove Phase Functionality from SL because they feel financially threatened. Their arguements are biased and self serving and personally I find it extremely offensive that they would attempt to extingush my rights and freedoms in SL for the benefit of their personal gain.

Lindens... please listen. Phase Functionality is a very beautiful thing that is a tremendous passive aid to many SL residents. It's not a perfect thing and many of us who have used it know of it's discomforts and quirks. Rather than take it away, it would be nice to explore how we can make it even more functional and available to the residents of SL.

I am a tier paying, land owning long time resident of SL and I feel absolutely no threat or discomfort from any resident who uses Phase. I love the world and have many good friends here. Phase is a tool on the shelf that's nice to have when needed. Please do not fall for the biased squeaky wheel profiteers who would have you change the world because they now encounter a technology or use of technology that they could not patent or lock up or box or sell exclusively.

Zee Kuu

• Phazed Chairs

Things that were broken or would be broken by SVC-1475

• llSensor based security systems
• llSensor based combat systems
• llSensor using games
• llSensor based traffic analysis systems

@Darling Brody
"Anyone who is already selling a scripted security device who would like to know how to do this need only ask me, and vote YES on this issue of course."

bribe people to vote for your issue? That's pretty damn petty.

You say "As for griefers, I don't know much about the weapons they use, so I suppose my question would be: what would be a more common occurrence, someone using sensor avoidance to avoid a griefer, or someone using sensor avoidance to violate someone else's privacy? Something tells me it'd be the latter."

But the continuing and repetitive problem here is, that's just pure and wild speculation on your part. And there is so much generalization and speculation surrounding the issue here and in SVC-125, including charged language designed to deliberately evoke an emotional response in an attempt to sway the issue. To enforce a policy and/or programming change based on speculation and sweeping generalizations is just plain wrong.

All we really need are the facts, and votes, to determine what people really want to see in SL. No more wild speculation, please. It doesn't help matters at all.

@Thraxis Epsilon:

How exactly would these things on your second list be "broken" by SVC-1475? Because once again, "broken" is in the eye of the beholder. What one considers "broken" another considers a feature. Had these things truly been "broken", then surely there would have been tons of complaints from years before SVC-125 was enforced.

And your accusation that Darling's offer to help security scripters is a bribe, is in itself a cheap shot and so far off the mark that it is simply laughable. What good would the offer of help be unless SVC-1475 were implemented, reversing the effects of SVC-125 which in the majority opinion should never have been implemented in the first place?

@All and Linden Labs:

It continues to be exceedingly clear that more people who care about it want this feature restored, more than there are those who want it to remain broken by the "fix" done by SVC-125.

1. Anything Haravikk says is bias, keyboard slamming, and tl;dr.

2. This page is about to have 100 votes unlike 79 on the one that broke it.

3. If you are bawwing that this crap is gonna break your security systems, you could try something like... UPDATING THE SCRIPTS TO 2008. Or shut it down if you haven't already.

4. This is not gonna break sensors. They will be as crappy as ever, and if someone wanted to play a game they'd have to get off of the phased vehicle.

Thank you to those who voted for good and voted for defense. Those that support psyke need to spend an hour in a linden sandbox or stop typing. Enjoy your spacemonies.

What harm could a phaser script possibly do that a normal prim couldn't do? You could be in some game where you may HAVE to be able to be sensored; like a combat arena - but they could just as easily sit on something to avoid being killed.
The sensor avoidable prims are used primarily as a TOOL. To avoid being greifed at sandboxes and such. I can hardly think of many occasions where they can be used as anything less.

It is not like someone who is phased can avoid bans and ARs and such like that, so really this is being overlooked.
Unbreak phaser, its a tool not a greifing utility.

the short version:

• This so-called bug does not introduce any issues reguarding land privacy, as owners (and those in a landowners group, if the land is group owned), can still see who is on a parcel without the use of sensors. This includes security systems as well.
• The "fix" completely RUINED a number of high end defense systems.
• There is now zero defense against followers and other assorted tools known to anybody who's been through griefer 101. (Sitting on a prim works, but you lose your mobility. Not an acceptable alternative)
• In short, the golden rule is DONT BREAK CONTENT. I'm somewhat put off by the likes of Psyke, Haravikk, etc, who have a financial interest in this issue, and pulled a deus ex machina with JIRA instead of figuring out some clever way (and i'm sure one still exists) inworld to improve sensor functionality.

Please reverse the "fix".

@Tessa - "All we really need are the facts."

Okay, so what are the facts then? I'm honestly curious, is there a strong legitimate use of this exploit or not? The only times I've seen it used have been to violate someone else's attempts at privacy, so that's where I'm coming from. Some people posted a few uses above, but really, don't want a notecard? Click discard, or mute. Paranoid about being physically attacked? Use a non-physical vehicle, or sit on a prim.

@Joker - If you're being targeted, you should be talking to the sandbox administrator; if no one's on hand, you can move to any of the numerous other sandboxes out there, in particular one with scripts disabled. Then you wouldn't even need the phased chair in the first place. As for followers, why not just sit on a prim and shoot up to 200m out of sensor range? They're not hard to avoid.

Anyway. Yes you CAN use a phased chair to violate someone else's privacy, and it's pretty obvious how. The problem you're having is more that the same system people use to verify their privacy (among other legitimate uses) is also being used by griefers to attack, in which case I'd say you're better off addressing the means by which people grief using legitimate functions rather than restoring an exploit. Considering you also sell griefer tools (http://slexchange.com/modules.php?name=Marketplace&file=item&ItemID=234851), however, I can see why that might not be preferable for you.

• llSensor based security systems
  (Will not be broken if scripted properly, and are still broken now anyway.)
• llSensor based combat systems
  (This is what we WANT to hide from! Griefers using scripted weapons!)
• llSensor using games
  (What would be the point of that? The scorebord will not see you, so you will never win the game! Also Phased movment is not very smooth. You wouldnt be able to play the game properly anyway. moot point.)
• llSensor based traffic analysis systems
  (Not true. They would count you before you had time to rez a phased chair and sit on it. moot point)

@Ammo Infinity
The issue that broke this had less than 50 votes at the time the lindens implemented the fix. Obviously someone is trying to inflate those figures in responce to this JIRA issue. Or perhaps some people misunderstood and voted there instead of here.

@McCabe Maxsted
You cant use a phased chair to attack with. It is not a weapon, it's a chair! Phased is a passive defence, not an offence. It can not violate ban lines and it will not evate properly_scripted land security devices.

Phased chairs are not a very good platform to launch an attack from either as most cheap/free weapons don't work when your using a phased chair.

Your personal attack on my credibility using a link to a weapon I made is ironic because you posted a link to exactly the kind of weapon that a Phased Chair would protect you from!

NOTE VERY WELL : If you bring personaly issues into a technical discussion again the way you did when you posted one of my products I will take it personaly. I DEMAND you show me the same respect I show you. If you choose to attack the person instead of addressing the tecnical issues, you do not belong here.

----------------------------------------------------------------------------------------
Side Note: "Griefer Tools" do not exist. They are a myth spread by people who do not understand it is the person who makes a choice to be a griefer, and has nothing to do with the tools they own.

I like being able to build with my friends, so shooting up to 200m with be tedious.
Also usually the sandboxes that have issues are Linden sandboxes - that takes around a day or two to get action done.

Can the two ideas be distinguished at this point? The title implies that any solution will do, but then the description demands a revert of SVC-125.

I'm just going to note this ambiguity in the description, for now.

I do not agree.

Prior to SVC-125 we had a choice to be off sensor using a phased chair. While a land owner's privacy was maintained because they could still prevent us from using a phased chair on thair land.

This is not a request for a NEW feature. This is a request to unBreak a large list of products owned and used by a huge number of people.

It is true SL needs scripted privacy from sensors and collisions, however I have not seen one new feature request granted, and we are not going to see one until after mono is rolled out. Therefore the best short term fix is to restore the original function until such time as it can be replaced with something better.

While I am an active creator and able to deal with changes to LSL and the effect those changes have on my products, there are plenty of products out there that will be broken, and stay broken because noone is around to update them anymore.

Then you need to consider there is no replacment for the functionality phased provided. I am not just talking about going off sensors, I am talking about avoiding scripted junk! Leaving the area is a totaly unacceptable resolution to the problem.

I have amended the request to clear this up for you and removed your notes. The main issue clearly states my point of view and does not need your commentory on my communication skills. That is what the comments below are for.

Darling

I'll import this for further investigation in relation to SVC-125.

Thank you for re-visiting this issue.

I am able to make myself available to yourself and others who would like to gain a better understanding of what "phased chairs" are really capable of, and more importantly, what they are not capable of.

I am also more than happy to demonstrate how quickly and easily you can detect and eject unwanted visitors over private land who are using a phased chair, simply by getting the keys of those people with objects over your land.

See "Prim Bin" for an example of a commercial product that detects and ejects people using a phased chair. It dose not use llSensor at all, and is able to protect the entire parcel of land, not just 96m. It was originaly designed to remove people from land who are littering it with prims, but also has the side effect of being able to detect avatars using phased chairs too. Ironicly I made it before I made my phased chair!
http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=261676

I hope the script gods will see the elegance of a passive defence like sitting on a specialy crafted prim.
–
Darling

ps. The "gentle-but-firm reminder" was definantly needed here. Thanks again.

http://docs.google.com/View?docid=dgc37f6x_6fcjp44hk

FOR IMMEDIATE RELEASE

Contact:
Psyke Phaeton
Psyke's Defense Systems

Griefers: Scripted Protection and Scripted Attack Debate Is Needed
====================================================

Tuesday, February 12, 2008

(Second Life) Psyke's Defense System (PDS) and Psyke Phaeton recognise the rights of all avatars to have the ability to avoid griefers and their negative influences.

The current debate shown in the JIRA http://jira.secondlife.com in issues SVC-125 and SVC-1475 which seem to be conflicting are in fact not conflicting at all.

Both sides of the debate want protection from trouble makers. Both sides want the same thing. The problem is that the old solution for non-private land, conflicts with the solution for private land.

PDS specialises in protecting private land and uses the scripting method llSensors() http://wiki.secondlife.com/wiki/LlSensorRepeat to do this. The problem with this, prior to the fix of issue SVC-125, was that llSitTarget() http://wiki.secondlife.com/wiki/LlSitTarget could be used to avoid the llSensor() giving griefers the ability to access land they should otherwise not be able to. PDS has a responsibility to it's customers to make sure this problem is resolved.

This problem became increasingly apparent and caused Psyke Phaeton to raise the issue in the JIRA in March 2007. At the time the issue was called "Unknown scripting method allows evasion of llSensor". It was not until October 2007 that the method used was made known to Psyke. At this point the title of the issue was renamed to "llSitTarget allows evasion of being detected by llSensor" and people in "Psyke's Scripts" group who used PDS security orbs were made aware of the problem so they could vote to have the issue fixed if they wished.

It was not realised at this point that people were also using llSitTarget() to avoid griefers who were using llSensor() based scripts to annoy and attack them.

So the situation was that griefers and victims were both using llSitTarget() and llSensors() for attack and defence for legitimate and illegitimate purposes. It should be obvious now that the problem is not with these two script commands but with the griefers themselves and there is no need for both sides of the debate to be fighting about whether SVC-125 should be "unfixed" or remain fixed. What is needed is a new approach that helps both private land owners and non-private land owners and users together.

"People on their own land should always be able to detect another avatar within range of their own llSensor() scripts and people should always be able to avoid llSensor() scripts from non-land owners as an option", Psyke Phaeton said.

The only question that remains is where this option should be placed. One idea is to allow avatars to decide whose scripts can see them. Another is the traditional method which would have it as an option in the land settings, such as "Allow Scripted Sensors".

"The community should debate the scripted griefing and scripted defense issue and then present a proposal to Linden Labs that solves the problems of all sides of this debate, the private and non-private land owners and users", Psyke said.

ABOUT: Psyke's Defense Systems(R) was founded by Psyke Phaeton in 2003 after interest in his HomeSecurity(TM) Orb began to increase. The HomeSecurity(TM) Orb is now in use on thousands of land parcels and simulators in SecondLife to protect people and property from unwanted intrusions where standard SecondLife land banning is inadequate or unsuited.

Your security orbs can be enhanced through LSL, without the fix from SVC-125. On the other hand, the function of Phased Chairs can not be restored while the SVC-125 fix is in place.

You should also note that SVC-125 highlighted a failing in your security orb scripts, it did not break them.

I am posting LSL code below that demonstrates my point. It fixes the failings in your security orbs without the need for the SVC-125 fix. It is a shame you couldn't implement something like this yourself. Should you need further assistance in LSL scripting, I would be happy to help you.

–
Darling

[code]
/////////////////////////////////////
//
// Name: Enhanced Avatar Detection for Private Land (Example)
// Author: Darling Brody
// version: 0.02
// Date: 12.Feb.2008
// Notes:
// This is an example script of how you might go about
// detecting avatars in the area even if they are phased.
// This script only uses long established functions and no hacks.
// This script was producted and published in support of JIRA issue SVC-1475
//
// Copyright : This script may only be used if your documentation gives credit to the author.
//

list visitors; // holds a list of visitors detected in the area

//////////////////////////////////////////////////////////
// Enhancment to detect phased avatars over private land.
//
EnhancedDetection()
{
integer loop;
list PrimOwners = llGetParcelPrimOwners(llGetPos()); // make a list of prim owners for this parcel
for (loop = 0; loop < llGetListLength(PrimOwners); loop = loop + 1) // loop through all the prim owners on parcel
{
if (llListFindList(visitors,[llList2Key(PrimOwners,loop)]) == -1) // this person is not already in the list

}
}

//////////////////////////////////////////////////////////
// Display results in floating text for proof of concept
//
Display()
{
string Output;
integer loop;
for (loop = 0; loop < llGetListLength(visitors); loop = loop + 1) // loop though all the detected people in the area

llSetText(Output,<1,1,1>,1); // Display Output over prim
llOwnerSay(Output); // Send output to Owner

// Best way to test is to sit on a prim and move it to 700m.
// You will get the Text message telling you where you are.
// while other people will see the floating text output change to show your new location.
}

default
{
state_entry()

sensor(integer count) // regular sensor detected someone in the area
{
// regular sensor script to collect names of people in the area (nothing special)
visitors = []; // clear the old list ready for the new people detected
integer loop;
for (loop = 0; loop < count; loop = loop + 1) // loop though all the detected people in the area

EnhancedDetection(); // Call Detection of Phased Avatars
Display(); // Display the results of the Scan
}

no_sensor() // this is required when the only person around is a phased avatar.

}
[/code]

I find it amazing that your work around uses a script that needs to poke local parcel to scan if an avatar is seated over that parcel, uses a call that delays the script by 2 seconds and doesn't address an issue of a horizontal offset of the avatar(along X or Y axis) from the prim they are sitting on.

Moreover, first, you comment on how good of a job Torley does to keep this tread on track, then flame Psyke for allegedly not having good coding skills.

How do you propose one scans for offset avatars (ones which sit on a prim outside of a parcel, yet appear to be physically on it)? Nested for x, for y loops? After such costly scan, if an offset is present, by itself it negates ANY of the built in parcel security settings (such as ban, eject, unsit, teleport agent home, even llOverMyLand), since the avatar could be sitting on a prim NOT over parcel's location.

no vote on this, its a fix and working as intended.

• • • Explination ***
      For a horizontal offset to be effective in avoiding a sensor, it needs to be at least 97m long.

Island Problem : A horizontal offset seriously limits movment as the prim you are sitting on can not move off the edge of the world. This means you will not be able to access a 96m ring around the edge of the region.

Mainland Problem : On the mainland you have similar movment problems caused by ban lines. A sit target can not pass through ban lines. Any attempt to do so will knock the agent off the prim they are sitting on. Region crossings while sitting more than link-distance from the root prim is risky, and hard to avoid with such a long horizontal offset.

Conclusion : These problems make it impracticle to produce a product using a horizontal offset to avoid sensors. Any attempt to make such a product is likly to result if the creator being flooded with complaints from people who run up against these problems.

• • • End Explination ***

My above script is a proof of concept script that clearly shows that the reliable vertical sit offset method can be detected through existing LSL script functions.

My script only scans the parcel every 10 seconds, so a 2 second delay is unimportant. A 10 second scan cycle is a responsible value to use for land protection. If you need it faster you can remove the delay by threading scripts.

Darling

1. Close this page.
2. Close secondlife.
3. Uninstall secondlife.
4. Learn a code other that LSL
5. ?????
6. Profit

The ????? could be:

Create your own online world and enforce your demands on whoever enters.
Create a video game.
Create a web browser.
Create an OS that doesn't fail.

I don't mean to speak for Darling (and Darling, please forgive me if I'm overstepping my bounds here), but I believe I understand her "shame" comment, as she's spoken often on the QC channel about LSL programming comprehension and skills. And perhaps Darling, as many in this whole wide world are, and where English is not necessarily their first language, is not as precise in her phrasing as would be desired by some, which can lead to awkwardness and misunderstanding.

I believe she meant "shame" simply because it truly is a shame that a lack of understanding caused the reversal of a feature that broke many security HUDs and scripts, a feature that customers clearly want. And that SVC-125 came about by far fewer votes than those who want the feature. And that SVC-125 was led and carried off by product competitors who apparently do not want to (or cannot, due to misunderstanding or a different programming skill level) change their own products to take phased chairs into consideration.

My own feeling, and perhaps this is shared by Darling and others, is that it truly is a shame that the jira system is sometimes used to try to slam and eliminate competitors. A change from a simple "vote for" to a "vote for or against" in the system would greatly level the playing field, and make it much more fair and possible for SL customers (who are king, as they are purchasers of SL products) to get the features they desire out of the products that they purchase.

And it remains exceedingly clear that the number of people who have voted to restore the phased chair feature eliminated by SVC-125 far outweigh the number that voted to eliminate it with SVC-125. The customer clearly wants phased chairs to be available to them as an option to avoid griefers, not only in public sandboxes, but elsewhere in SL. Why expend this much energy fighting the customer? It's like SCO suing all their customers, and look where they are now: in bankruptcy. It's not to say that's where this is leading, but it is a good illustration which clearly shows that product makers cannot disregard and even attack their customers and their desires.

I agree more with the title of this than the functionality change, people should be able to choose whether they can be scanned via LSL but not by reversing this, it should be a Be scanned by scripts option either on your profile section or in your options with a default to unchecked which would make LSL scanning essentially opt in. Yes this would break a lot of automated security scripts but honestly if your trusting LSL to do your security work for you then you aren't that bright, LSL cannot replace humans when it comes to securing your property or whatever partially due to it's inherent limits and partially because of the limits LL and the SL environment has placed on it.

Oh, by the way, this issue is now getting attention in the press: http://foo.secondlifeherald.com/slh/2008/02/its-only-a-phas.html

The basic Linden Scripting Language Guide published by Linden Labs (and included in every copy of SecondLife, it's there in the install directory), defines llSensor() as follows:

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

"llSensor(string name, key id, integer type, float range, float arc);

Performs a single scan for name and id with type within range meters and arc radians of forward vector. Specifying a blank name or NULL_KEY id will not filter results for any particular name or id. A range of 0.0 does not perform a scan. Range is limited to 96.0. The type parameter should be an object type constant value. If anything is found during the scan, a sensor event is triggered. A maximum of 16 items are passed to this event. If nothing is found during the scan, a no sensor event is triggered instead."

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

SVC-125 reported that objects using llSitTarget() could cause this function to work in an undocumented fashion, specifically causing this function to fail to work. Prior to the fix instituted in SVC-125, it was possible for llSensor() to trigger a no sensor() event event when it should have triggered a sensor event and returned certain information. That this was a bug should not be considered "subjective." SVC-125 fixed a bug that caused llSensor() and llSensorRepeat() to function in a manner that was very different from that which was documented by Linden Labs.

SVC-125 has validity beyond "griefing" and security applications. llSensor() and llSensorRepeat() are used in a large number of devices in SL. For instance, the popular air-combat add-ons that allow planes to engage in simulated dogfights, TCS and CCC, use llSensor, as do many other recreational games.

SVC-125 fixed the llSensor() and llSensorRepeat() functions so that they now work in the manner stated by Linden Labs' own documentation. It is unfortunate that some products may work differently now, but the fact remains that the only reason that they "worked" prior to SVC-125 was because the llSensor() and llSensorRepeat() functions were not returning the proper values according to Linden Labs' documentation.

If you do want a privacy function, I'd strongly encourage creating a new JIRA proposing how this should work, and treating it as a new feature, not a bug. A script function allowing you to opt out of scans from objects not owned by the parcel owner or yourself seems reasonable. It wouldn't interfere with home security orbs, and would solve opting out of griefer object detection.

If you want it, consider asking for that, linking it as related to this issue, and voting it up.

Dear Soft Linden.

First sorry for my English, will try to write as best as possible.

Since SVC-125 was applicate, I can not go any more to Linden sandboxes for tests my builds without have a prick on my head ( by non resident avatars ) Was a very bad surprise, not very nice really.

Linden sandboxes are hell since Sensor() evasion are locked, so no thank you to Linden developers team for this choice without more debating before. All my defense tools from my inventory since 1 year are now OUT. Around 15 tools payed with my French visa card to Linden Labs are now out of order.

When I do not remember problems I try to understand the start : PDS privacy orbiter tool do not run if avatar use llSitTarget() function.

PDS is really my best enemy in SL before 'prick over head', before griefers : it orbited me lot of times without any reason, without any check if warning box was received, displayed, clicked. Sensor() evasion was my best tool for build for check my scripts on sandboxes without griefers problems, is finished.

PDS orbit anybody with undocumented functions , explain is a secure private system without inform that is possible to set privacy with land settings with a very regular and official and documented way.

Rules are really now changed for me.
Actually we have 79 votes for SVC-125 and 129 votes for abort this fix, take time for thing about this.

I'm probably not very clean about my explanations, sorry for that. Contact me by email if needed.

Rules are changed, it remove my firewall from my (SL)life.

Best Regards,

Wen.

Walk away.

There are thousands of resident run sandboxes all over the grid. Moderated to keep trouble and spamming out. I personally return any annoying followers that appear in ferox.

The linden sandboxes are old, stagnant, and abandoned by anyone who has the power to change that. Why do you cling to them so ?
Ferox welcomes anyone who wants a nice quiet place to build. : )

You say "Darling Brody wants this fix reverted so she can continue to sell an "anti-griefing tool" which is just as easily (and much more often) used to harass people in public places." You have facts and figures to back this assertion up? Darling has over 1000 customers of QC. How many of them are griefers? And exactly how much time does a griefer use QC to grief, rather than Belias, or Ownage, or Lilith, or any of the countless other combat HUDs available, many which have true griefer features that QC does not?

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

May I point out that QC has an anonymous orbiting module, and a module that spams the target with urls until they crash.

Soft did not say that. Soft agreed with the post which said

the only reason that they "worked" prior to SVC-125 was because the llSensor() and llSensorRepeat() functions were not returning the proper values according to Linden Labs' documentation.

Emphasis on not returning proper values. Linden lab wrote the language. And their documentation is how it should work. Deviation from that is a bug, not incorrect documentation.

You appear to have missed the entire point of what I posted, so I will reiterate for you and for any others who misunderstood:

(when I say llSensor() here, I am also referring to llSensorRepeat())

Linden Labs designed LSL. They designed it to have a number of functions, and documented these functions and how they should work in a guide that is included in every copy of Second Life. One of these functions is llSensor(). Linden Labs documentation is very clear on how llSensor() was designed to work. llSensor() was always supposed to detect an avatar if the avatar was within the scan's range, regardless of whether they were sitting on an object that was outside of the scan's range. All that Linden Labs did, in SVC-125, was fix the code so that llSensor() now works the way it was always intended to work. According to what Linden Labs has written regarding LSL's official functions, there was NEVER supposed to be a method by which an avatar could evade a sensor if the avatar was within the sensor's range.

Phased chairs were using an undocumented exploit, just as Darling Brody's QC "Crash" function used an undocumented exploit to intentionally crash a target's client. Should Darling also start a JIRA complaint regarding the loss of the "Crash" function because Linden Labs (in her own words) "intentionally broke it." (here I am quoting from the Quantum Core User Guide).

(Incidentally, I never quite understood how the "Crash" function could be used for anything except griefing, but I digress)

The LSL Guide is very clear in how Linden Labs intends for LSL to operate. It is quite clear that the llSensor() function was always intended to operate in such a manner that it will detect an avatar on a phased chair. My guess is that the reason it did not do so, prior to the SVC-125 fix, was because non-avatar objects obey linking rules that in most circumstances will prevent them from having one prim in scan range and one outside. Avatars, of course, may be offset far beyond the normal prim linking limits (which is good, because it allows sit-teleporters to work) and my guess is that the earlier implementations did not take this into account.

Finally, if I may make one request: Earlier today I was in the Rausch Safe Zone when Wendy Umarov orbited me multiple times in retaliation for my post here. Attacking an individual who is in a SAFE parcel is not acceptable behavior, but more importantly, doing so in retaliation for writing a JIRA comment in abhorrent. Individuals should not feel that they will be targeted for retaliation if they express their opinions here. Doing so is a threat to the JIRA process itself, and I would request that ALL individuals here please refrain from engaging in acts of intimidation in an effort to quell dissenting opinions.

Warkirby, i love how you tell people to WALK AWAY from sandboxes. What happens if they don't want to? Would you want to randomly move away everytime someone started constantly griefing you? I highly doubt it. IF you did, i bet you will be moving alot.

And to lindens. If you don't really plan to revert the fix so we can keep griefers away, then maybe you should patrol the LINDEN sandboxes?

And if you don't really wanna patrol your own sandboxes, maybe you should allow return fire?

Personaly I dont think a privacy function will be implemented because it really will break sensors, and people will complain that there is no way around it at all, unlike phased chairs which has an easy script fix posted here. There is the even simpler fix of just moving your sensor object around.

@Everyone & Soft Linden

A bug becomes a feature when it becomes widly used enough to make a negative impact on the SL community if it is removed.

A perfect example of this is the WarpPos hack, and what happened when it was broken last year. (all the prim movment based teleporters broke)

The main difference is how much more obvious the broken warppos was to non-scripters. Phased chairs still appear to be working, until your targeted by a weapon that otherwise would not have been able to effect you. Then the creator of the phased chair receives complaints from their customers.

There have been over 2000 Quantum Core's sold in the last 6 months. I wonder how many more people have the phased chair from omicron and others who have been selling for years longer than me?

I would like to remind people that this is not about me. It is not about my products either. It is about the existing customers of many creators who are upset at something usefull getting broken. As the customers don't have a complete understandong of how it works, it is up to the creators to speak for them.

@WarKirby Magojiro
Do not mislead people, there is no URL spammer in the Quantum Core. There is also no anonymous orbitor in it. It has an orbitor that dosnt show up for the same reason Phased avatars didnt show up, "other scripters made an incorrect assumption."

@Jahar Aabye
I know you want to make this issue all about how much you don't like my products. You need to understand "This JIRA is NOT ABOUT MY PRODUCTS. This JIRA is about a harmless passive defence used by many creators in many popular products." The only ralavat part of my product to this JIRA is the PNPV and EPNPV defences.

How about you provide information that is on topic and NOT misleading?
Your example about dog fight simulations in planes is misleading. You cant use a phased chair at the same time your sitting on a plane, because you can only sit on one thing at a time. Please stop trying to obscure the real issues with manufactured problems.

As for your inappropriate public allogations against Wendy in this JIRA. It shows how dirty you are willing to get to discredit someone who does not agree with you.
Did you ever consider you got orbited because you were in a combat region, safe zone or not, things happen to us all there. You don't see anyone else crying they got orbited because of the JIRA. Maybe you should do something safer with your SecondLife, like manufacturing furniture?

Darling.

This is very different from the WarpPos scenario. WarpPos is fairly straitforward, and not really a bug. A single instance of llSetPos() has a limit in how far it can move an object. WarpPos simply strings together instances of llSetPos() until one has moved a desired distance. This is not really a bug in that it is not unexpected behavior.

Conversely, having an llSensor() function trigger a nonsensor() event when an avatar is within range is most definitely unexpected behavior. The llSensor() function is very clearly defined by Linden Labs. All that SVC-125 did was ensure that the llSensor() function works as intended.

As you say, phased chairs do still appear to be working. In fact, they work exactly as expected in LSL. There is nothing in the expected (ie documented by Linden Labs as being the intended outcome of LSL functions and events) behavior of these items that should allow an avatar to evade a sensor. llSensor() was supposed to have passed info on these avatars to the sensor() event from the beginning, everything so far written by Linden Labs confirms this. It is only that they were marketed as being able to evade sensors that is the problem. Again, if you read through Linden Labs' documents regard LSL, written by the very programmers who developed the language, you will see that phased-chairs were not an intended outcome.

Similarly, at one point a damage-enabled onject on damage-land that extended into non-damage land could still "kill" an avatar. This is clearly a bug, as it is clearly documented that avatars can only be killed on damage-enabled land. If people sold items that exploited this bug, should that have prevented Linden Labs from fixing it?

As for the dogfight simulators, you seem to have missed the point entirely. My point was EXACTLY that they are unrelated to phased chairs, but that they ARE directly related to this JIRA (and to SVC-125), because they involve sensors detecting avatars who are sitting on the root-prim of an object, My point was that llSensor() has a lot of uses outside of griefing or killing people in Rausch.

If you want another example, I work at a sim that requres that all participants wear an issued game HUD while in the playing area (at ground level). We use a system of sensors to detect if there are people who are not wearing a HUD, and ask them to teleport to the waiting area. If they do not do so, they are teleported home. This is done to ensure that people do not disrupt the game. We fully expect, based upon the documentation of the llSensor() function, that our objects will detect any avatars within scanning distance. Can you show me documentation from Linden Labs that indicates otherwise? You mention the size of your customer base, we have over 1500 members and pay Linden Labs the full island estate tier of USD $295 per month. There are countless other groups and individuals who rely on scripts that use llSensor() for a number of tasks. They had based these scripts upon the written documentation by the Linden Labs programmers who designed LSL. Their understanding of how these scripts would work was based upon what Linden Labs had written.

*******************************************************************************************************

Nowhere is the inability for llSensor() to detect an in-range avatar who is sitting on an offset prim endorsed by Linden Labs as an official, supported function of the Linden Scripting Language. That a script using llSensor() SHOULD detect an avatar within a specified range and return information to the sensor() event call is most definitely officially endorsed by Linden Labs as an officially supported function of the Linden Scripting Language.

**********************************************************************************************************

(incidentally, I only brought up the Wendy thing to remind people not to take these debates in-world....I'd like to avoid being "accidentally" added to the default "foe" lists of any product updates, as my animator was)

Do not twist my words. The emphosist was on the word "appear", as in false appearance. People using a phased chair have no clue it is not working until they are assulted.

Quote: "As for the dogfight simulators, you seem to have missed the point entirely. My point was EXACTLY that they are unrelated to phased chairs"

I didn't miss the point at all. Your dragging in totaly unreliated rubbish to derail any meaningful discussion.

Quote: "If you want another example, I work at a sim that requres that all participants wear an issued game HUD while in the playing area (at ground level). We use a system of sensors to detect if there are people who are not wearing a HUD, and ask them to teleport to the waiting area. If they do not do so, they are teleported home"

Yes, and I am sure you and the other "people" at Pure Combat will be able to make use of the script I posted to detect people who are using any kind of sit-shield, phased or not, anywhere in the region. And I expect credit when you do so, as per the script's requirments.

Quote: "You mention the size of your customer base, we have over 1500 members and pay Linden Labs the full island estate tier of USD $295 per month. "

I don't have the equipment to get into a pissing contest with you over who has a bigger "whatever". And it is irralavant anyway, as I have said many creators make use of this feature, with thousands more customers who have a reasonable expectation to have their products function the way they have for the last 4 years. It is the height of arrogants to think paying the teir on one sim makes you more important than all those people.

Quote: "I'd like to avoid being 'accidentally' added to the default 'foe' lists of any product updates"

If it happened to you, I doubt it would be an accedent. People get upset when they are black mailed. The way you do business is a criminal offence in my country.

Darling.

Sure, everyone who uses the llSensor() and llSensorRepeat() functions could add your workarounds to their scripts, adding lord knows how many thousands of unnecessary instructions per second and unnecessary lag. But why should we go to such lengths, when Linden Labs has told us from the get-go that the llSensor() and llSensor() repeat functions will return up to 16 instances of the specified type (AGENT, SCRIPTED, PASSIVE, or ACTIVE) anyways? Why exactly should we all be forced to use an extra sensor script to accomplish what the Linden Scripting Language is supposed to do in a single function?

My point is that the promises that Linden Labs made to us, their customers, are more important (to Linden Labs, at least) than the promises that you made to your customers. Phased chairs are clearly not a supported feature of the Linden Scripting Language. The ability to detect up to 16 avatars within 96.0m is clearly a supported function of the Linden Scripting Language. It is certainly unfortunate that your customers, and many others, were not made aware that these phased chairs only worked because of a bug that caused llSensor() and llSensorRepeat() to return faulty information. Had llSensor() and llSensorRepeat() always worked as intended, phased chairs would never have been possible in the first place.

If Linden Labs already has a single function that should do the detection, why should everyone be forced to use a much less efficient method?

All that SVC-125 did was fix the llSensor() and llSensorRepeat() functions so that they now work as they have already been documented to work. As Soft Linden said, if you want Linden Labs to alter how llSensor() and llSensorRepeat() work, or if you want to add official, supported methods for an avatar to avoid llSensor() and llSensorRepeat(), then you should start a separate ticket, and people can have an (hopefully) open discussion about whether that is a good idea and what the best method of implementation would be.

Aside from the fact that many people bought products erroneously believing that they relied on documented, official LSL functions instead of taking advantage of a minor bug in the code that everyone should have known would be fixed eventually...why exactly should Linden Labs revert the SVC-125 fix and return things so that llSensor() and llSensorRepeat() no longer return accurate data?

As for what individuals should do if they find that their phased chairs now no longer provide adequate protection from grief attacks:

If individuals find themselves being griefed, harassed, assaulted, etc by another individual, and there are no individuals with landowner abilities to remove the offender, they should immediately file an abuse report with Linden Labs, documenting the name of the offender. If they are being attacked continuously by an object, they can also click a button on the abuse report page and then click on the object, which will send additional information to Linden Labs. This has the advantage of ensuring that they are filing the abuse report against the offender and not accidentally naming an innocent bystander, as well as providing Linden Labs with information about the objects used for griefing and their creators. If people spent less time making follower objects and (not very) "anonymous" push attacks, the SVC-125 fix would not be as big of a deal.

Perhaps to offset the potential danger posed by griefing now that the phased chairs no longer work, Linden Labs should consider UUID-banning griefing objects as they are reported, as well as perhaps IP/MAC-banning their creators? That certainly might help alleviate the concerns that you and others have expressed as being a major reason for wanting phased chairs. If the threat is that severe as to warrant a request for Linden Labs to re-break a code fix, then surely stepped-up enforcement on the part of Linden Labs is something that we could all support.

Jahar, no one should have to if they found a way to avoid griefers.

Also, the people who paid money for their phased vehicles want their money back.
They deserve their money back.

Maybe you should refund it?

For those people watching who don't understand the sub-text here. Jahar Aabye just refreshed his blackmail. He wants me to stop selling weapons and disable all of the ones already sold, under the threat of him and his friends flooding linden labs with abuse reports naming me as the creator of what he calls a "griefer device". You see he is involved in the guns market, and HUDs cut into his sales.

Quote"everyone who uses the llSensor() and llSensorRepeat() functions could add your workarounds to their scripts, adding lord knows how many thousands of unnecessary instructions per second and unnecessary lag. "

Did you even read the script? It triggers once every 10 seconds, which is more than fast enough if your caching keys. Not only that, it dosnt have the range limit of llSensor so you dont need more than one object to scan the entire parcel. Far to many people think like you, and have fast sensor cycles in multipal objects, no wonder SL is so laggy.

Darling.

Linden Labs defined the llSensor() and llSensorRepeat() functions. There was a bug that caused them to failt to return the expected values. Linden Labs fixed this. Other than the fact that you sold items that took advantage of that bug, you have yet to give one good reason why Linden Labs should revert that change.

Telling people to file abuse reports if they are griefed is not blackmail. Advising them that the abuse report includes a function that allows them to click on the offending item is not blackmail. Hell, by that definition, the Support section of the SecondLife.com website is guilty.

People who have filed good-faith complaints against you have a habit of winding up on the default "foe" or parcel ban lists of the products you distribute. Your repeated ad hominem attacks here seem to fall along the same lines.

Maybe instead of blaming everyone else, you should accept responsibility for your own actions. Kerik Rau had nothing to do with SLX pulling your device, but as a result of your actions, he's banned from god-knows how many parcels in SL, the owners of which mostly have no clue who he is or even that they've banned him. My animator had to start a new account after you "accidentally" included her name on the default "foe" list of your product (and incidentally, cause serious damage to what is, at the moment, my sole source of RL income due to disability).

So now that Linden Labs disabled your phase shields, you lash out at me. For no reason other than because I put up a JIRA comment about the llSensor() function in an effort to keep debate on-topic (a comment that Soft Linden agreed with).

When Havok4 breaks your orbiters, who are you going to blame then? Are you going to file another JIRA requesting that Linden Labs rescind their push limits? I'm surprised you haven't filed a JIRA against them for "intentionally breaking" your client-crasher...well, probably because that actually was both against the ToS and illegal in the USA (DoS attacks are a felony). Lord knows what the "Fault" function that they recently "broke" did.

JIRA is for bringing attention to undocumented and unexpected behavior of various program functions. As this ticket concerns behavior that is fully expected and fully documented by the very engineers who designed the Linden Scripting Language, available with every copy of Second Life, and given that your defense seems limited to ad hominem attacks and ridiculously unsupported accusations, I think it would be best for this ticket to be closed.

But anyway... Lindens. This thing has 130 votes on it. And seeing as 70 something got it broken, then maybe this is enough to throw it back up. So you know. We can get around without having over 9000 followers put on us.

Also, if you close this without a linden marking it, i will reopen it.

Kerik Rau told me personaly that he did it. I'm not the only person he told either. You need to stop making stuff up to support your paranoid opinions.

This is not about MY phased shields and I have not lashed out at you. This is about customers! The customers who ask myself and other creators the same question every day, "How come the shields dont work anymore? Can you fix them? Please, I really need them, I can't work in the sandbox without them."

It is easier for you to spread your mis-information and make this into a person flamewar, than to come up with some real facts and comprehend the scripting methods being used.

—
@ everyone
WarpPos is a perfect example of a one scripted function being able to bypass a documented rule. The documented rule is that no non-physical object can move more than 10m in a single jump. Yet we can build up a string of smaller jumps and feed them into llSetPrimitiveParam as a list to bypass this documented limitation, and have an object move huge distances instantly.

If we are to remove all script side-effects we will loose usefull things like warppos. Of course your not interested in the warppos bug because it dosnt protect people from the products you make. Your motivated by financial self interest. I am motivated by my customers. I give them what they want, and I fight to protect their investments. You on the other hand will try to break, ban, or change anything you think is a threat to your cash cow.

—
@Rex Cronon

I agree with you about the documentation. I would take it one step further and say that some undocumented side effects have become standards and should be added to the documentation as a feature. Besides warppos, another great example is casting a string to a key to pass an extra string of information through the key field of llMessageLinked. It should not work according to the documentation, but it does. It is widly used and would be a disarster if it was broken.

"3.3.1.1. Implicit Casting

LSL only supports two implicit type casts: integer to float and string to key. Thus, any place you see a float specified you can supply an integer, and any place you see a key specified, you can supply a string."

But even taking that into account, that is very different from what we have here. Phased chairs were not a workaround to a limitation, and Linden Labs did not do anything to affect how PHASED CHAIRS operate. Phased chairs still operate exactly as they always have, you sit on a nonphysical vehicle, the sit offset is such that you are in one place and the vehicle is far away. Nothing that Linden Labs did changed this.

The issue here was not about bypassing rules. The issue was that a function, llSensor(), was supposed to detect avatars who were within the scan's range. LL's documentation claims this, Soft Linden confirmed this, and while Rex seems to believe otherwise, no one has yet shown any evidence for why this should not be the case.

What I think many people may not be understanding is that prior to the fix instituted in SVC-125, scripts that contained llSensor() and llSensorRepeat() were BROKEN, due to an error in the Second Life server software. Contrary to Rex's unsourced and unsupported assertion, if you look at the LSL guide, it's fairly clear that llSensor() was intended to detect avatars within scan range:

"
A.219. llSensor

llSensor(string name, key id, integer type, float range, float arc);

Performs a single scan for name and id with type within range meters and arc radians of forward vector. Specifying a blank name or NULL_KEY id will not filter results for any particular name or id. A range of 0.0 does not perform a scan. Range is limited to 96.0. The type parameter should be an object type constant value. If anything is found during the scan, a sensor event is triggered. A maximum of 16 items are passed to this event. If nothing is found during the scan, a no sensor event is triggered instead."

so if I have a script like so:

**********************************************************************************************************

Default

sensor(integer detected)

no_sensor()

*******************************************************************************************************************

If I touch the object, and there is an avatar standing 30m away, what should happen?

According to Linden Labs, the script should trigger the sensor() event, and pass information to that event. Then this script should perform the functions in that event, telling me your name.

If the script instead triggers a no_sensor() function, despite the fact that the avatar is standing well within the scan range, then the script is returning the wrong information. The llSensor() function is operating in a manner that is clearly unexpected. Phased chairs aren't "workarounds," they're accidents of a coding error that causes the llSensor() function to return bad information under certain odd conditions.

When scripts containing llSensor() and llSensorRepeat() return bad information, the result is that these scripts are BROKEN. They are not operating the way they should according to the official documentation. LL fixed this with SVC-125. If LL were to revert that change, as you are asking them to, then it would break scripts containing llSensor().

I fail to see why undocumented side effects should, in this case, be given PRECEDENCE over documented script functions. This isn't about my scripts or your scripts or anyone else's scripts. This is an issue that affects the LSL language as a whole, that affects scripts throughout SL. Intentionally reverting a fix to a documented LSL function solely so that some users can benefit from a side-effect of a documented function being broken and returning bad information is a very bad idea.

Ok, now on to the more ridiculous stuff, just because I can't let certain false allegations go uncommented:

*******************************************
"Your motivated by financial self interest. I am motivated by my customers. I give them what they want, and I fight to protect their investments. You on the other hand will try to break, ban, or change anything you think is a threat to your cash cow."

********************************************

Actually, leaving phased chairs working would have been better for me, financially, since I had just released an "anti-phase" bullet, and being as it was the only one on the market, would have been quite beneficial for me. My position on this topic is based on the belief that documented LSL functions ought to function as documented. As a scripter, it is important to me that Linden Labs not re-break documented LSL functions, causing them to return bad information, simply because it benefits some users.

However, leaving that aside, my motivations are not relevant to this discussion, and neither are yours. I could just as easily point out that you have a very large financial interest in this issue. However, this too is irrelevant. Even if I did have a financial motive, it would not, in and of itself, negate the points that I have made, just as any financial interest you have in this issue does not negate your points. Those who believe otherwise need to take a few undergrad-level courses in logic.

**********************************************************************************************************************

"It is easier for you to spread your mis-information and make this into a person flamewar, than to come up with some real facts and comprehend the scripting methods being used. "

*********************************************************************************************************************

This is, oddly enough, exactly the point that I made above. I have repeatedly discussed the llSensor() and llSensorRepeat() functions, quoting Linden Labs, and tried to focus the discussion onto the scripts themselves. I have repeatedly asked you to explain why these two functions should not return a sensor() event if an avatar is within scan range. I have repeatedly asked why returning a no_sensor() event when an avatar is within scan range, when LL's documentation says otherwise, should not be considered a bug. I have asked repeatedly why scripters should be forced to use a workaround script, rather than having llSensor() and llSensorRepeat() return the correct values that they were supposed to in the first place.

So?

I'll repeat again

have repeatedly asked why returning a no_sensor() event when an avatar is within scan range, when LL's documentation says otherwise, should not be considered a bug.

I have asked repeatedly why scripters should be forced to use a workaround script, rather than having llSensor() and llSensorRepeat() return the correct values that they were supposed to in the first place.

If Linden Labs already has a single function that should do the detection, why should everyone be forced to use a much less efficient method?

Aside from the fact that many people bought products erroneously believing that they relied on documented, official LSL functions instead of taking advantage of a minor bug in the code that everyone should have known would be fixed eventually...why exactly should Linden Labs revert the SVC-125 fix and return things so that llSensor() and llSensorRepeat() no longer return accurate data?

This ticket is asking Linden Labs to revert fixes to the llSensor() and llSensorRepeat() functions. You opened this ticket, but you have discussed phased chairs, warppos, your customers, my business, "blackmail", various other conspiracy theories, etc.

You have not discussed llSensor() and llSensorRepeat() at all.

Why shouldn't they detect an avatar within sensor distance?

kthxbai

Frankly, after having used them, written them, and ultimately discarded them due to the limitations of movement they present, i can see no reason at all why the voices of a minority of residents should prevail over the fixing of a bug.

There is no reason at all why a sensor should fail to sense the presence of an avatar within range.

As for the case presented by those claiming that these "phased" vehicles are a method of avoiding follower objects, perhaps SL would be a better place if those people AR'd the owners of those objects and simply moved out of sensor range, leaving the sensor based follower without a target.

Selling something that relies upon a bug is not good practice. Leave the fix.

it breaks too much content.

(no, i'm not selling a phased chair. and i rarely use one... but sometimes it's very useful)

2. Phased chairs are more useful than you think. And until lindens patrol their own sandboxes, they should be left in their working condition and not removed by content breakers. Really, if you can't update your scripts to work around it. You lose. And you will be a liar if you call yourself a scripter.

I do however doubt this fix is going to be removed at this point, more likely an alternative solution will be investigated, the votes on this issue appear to have levelled at roughly two-times SVC-125. However I'd like to note that a lot of votes here come from advertising the issue, and from people who purchased items that relied on a bug, so I'm not sure how well these should be considered seeing as how a lot of these people are voting to "un-break" their items, rather than considering the actual issues (the items were based around a bug, and better tools are really needed to combat griefing).

Tthe issue's title is a bit misleading when I think about it. We never had the ability to "choose" to be scanned by sensors, we only had broken behaviour. Sure this behaviour could be used to work around sensors, but should it have? Really we should have had an actual option, buggy behaviour is no substitute for an actual feature.
I suspect that a good percentage of the votes (likely the majority) want a way to hide from sensors, or are annoyed because they can't hide from sensors, which is what the title suggests this issue is about.

I think you will find the original fix was pushed through by people with a self interest in making their security products detect phased chairs. The issue was listed by the maker of a security product and voted on by his customers.

This new issue was listed by the maker of a phased chair, with customers from MANY different brands of phased chairs voting to have the fix removed.

The difference being "they wanted the fix so they didnt need to add additional scripting to detect phased chairs". VS Those of us who "use it for passive protection cant re-script our products to restore the lost ability".

My reason for adding this JIRA is simple. We can not restore the level of protection phased gave us any other way. If it was a simple matter of rescripting it, I would have posted a fix for phased chairs instead of posting a fix for security orbs.

Bottom line is that all content can continue to work if this JIRA is passed and the phased function is restored. Security orbs will continue to be able to protect land using my script, and builders can work in peace on a phased chair in the sandboxs. Anyone apposed to solving everyones problems is just an antaganist.

@Darien Caldwell
Well said.

Darling.

This new issue was listed by the maker of a phased chair, with customers from MANY different brands of phased chairs voting to have the fix removed.
"
*****************************************************************************

A: How do you know that those voting on SVC-125 were solely his customers? Many of us voted for that issue because we felt it was an important bug in how llSensor() was supposed to work.

Furthermore, the only people who "pushed it through" were the employees of Linden Labs who made the fix. Unless you have some evidence that Seraph Linden had some sort of special financial interest in security orbs, and I have seen nothing to suggest this, why bring this up? This is a non-sequitor argument intended to confuse the issue by creating an appearance of impropriety in the enacting of SVC-125 where none exists.

******************************************************************************
"
The difference being "they wanted the fix so they didnt need to add additional scripting to detect phased chairs". VS Those of us who "use it for passive protection cant re-script our products to restore the lost ability".
"

*****************************************************************************

I was going to call this a straw man argument, but it actually leaves unanswered the question of why exactly one should expect to need additional scripting to detect a phased chair. I expect to need additional scripting (WarpPos) to move nonphysically more than 10m...but I don't expect to need additional scripting to detect an avatar who is within 96.0m of an object containing the function llSensor("","",AGENT,96.0,PI);

As for the second part, I have to agree....a while back I had so much difficulty getting rid of this follower that spewed out so many blue particles that my client could barely process anything and my FPS plummeted...had I not been running on low particle settings, my client almost certainly would have crashed. But I doubt that a phased chair would have helped me, seeing as how the creator of that device also has a workaround to sense phased avatars.

Just for full disclosure here, Darling, since you've already accused me of having ulterior motives: Were your follower devices, prior to the SVC-125 fix, capable of tracking and following an avatar who was sitting on a phased chair? After all, that's why you already had a workaround, isn't it?

If so, how does bringing back phased chairs offer protection? All I see it doing is giving you a leg up over the makers of other follower devices that can't follow people on phased chairs.

Of course, this is STILL tangential to the main point, which is that the ability to avoid a sensor was never a documented, expected ability of phased chairs.

***************************************************************************************************************
"

My reason for adding this JIRA is simple. We can not restore the level of protection phased gave us any other way. If it was a simple matter of rescripting it, I would have posted a fix for phased chairs instead of posting a fix for security orbs.

Bottom line is that all content can continue to work if this JIRA is passed and the phased function is restored. Security orbs will continue to be able to protect land using my script, and builders can work in peace on a phased chair in the sandboxs. Anyone apposed to solving everyones problems is just an antaganist.
"
*******************************************************************************************************************

Rescripting phased chairs won't work, I agree, but that doesn't mean that another method could be created to give some level of privacy. Perhaps, for instance, a limit could be placed on the number of sensor calls a script can make for a given agent UUID within a certain period of time, thus making followers less practical. After all, I think we can all agree that the problem is that there are people who make and distribute and use these objects. If we were to limit their effectiveness, we wouldn't have to intentionally revert a fix and cause an LSL function to return bad information.

Unfortunately, this particular JIRA would cause content to fail to work. It would require people to use your script to return information that is supposed to be returned by a standard LSL function. All scripts currently relying on the standard llSensor() function would be broken unless they added your script. And that would only apply to situations where those objects were used on the owner's land. Legitimate content using llSensor() on other land would still be broken.

And again, I'd like to point out that Andrew Linden, Corey Linden et. al. were very clear in the LSL guide about the llSensor() function. Last I checked, you were Darling Brody, not Darling Linden, so you do not get to rewrite the LSL Guide. If you would like Linden Labs to change the definition of the llSensor() function, you should file a JIRA asking for that. This is what Soft advised you to do about a million comments ago. But it's not like his last name is.....oh, right.

But Its not just her code. Its code that exists to work around the phased chairs. An actual scripter would be able to put it together. I don't see certain people on here as actual scripters since they have been here. Wasting all this time spewing BAWWW all over everyone when they could have taken some percentage of a 30 minutes to write this into their scanners so they can get back to using it for griefing purposes.

The jira against phased chairs was nothing more than an attack. A slip of a card to reopen a path for professional griefers. Any other excuse is invalid and a lie.
—
I feel that no one is gonna implement this anyway. Therefore someone should write a jira about how these security bots are responsible for derailing simple flights across the grid.

I do not sell security orbs; I have one I coded myself for my home but which I do not sell. I do not buy other people's security products.
My interest (and I hope, the interest of many other users of the JIRA) in having SVC-125 addressed was that the issue indicated incorrect behaviour in sensors. A sensor should work as described (if an object is in range of a sensor and of the requested type, then the object is returned in results), SVC-125 was the results of a scripter, who worked with a lot of sensors, finding a bug in that behaviour, which turned out to be the result of an optimisation gone wrong.
I /could/ add your proposed fix to my script, but at the cost of greatly increased script complexity, less memory and more work for the simulator, I am understandably reluctant to do so. I produce scripts to be as high-performance as possible while using simple, clean code and implementing features that I find extremely useful. What you're suggesting is that I should sacrifice all of these goals so that sensor behaviour can be broken so that your chair(s) work again?

The fact is that this issue represents a "fix" for a particular brand of products of which you have vested interests (you bought or produce phased chairs), which will re-break a much larger number of products which are now behaving correctly. You are therefore campaigning for the WRONG thing, what you need isn't working phased chairs, as they've ALWAYS been broken on account of abusing a bug, but a way of protecting yourself from sensor based attacks.
SVC-1462 is proposing such a solution, and other people are more than welcome to post other proposals and link to this (that's what the JIRA is for after all). For anyone who is here purely to lash out about money lost due to purchase of a product made by someone exploiting a bug, it is obviously much too sensible, your quarrel lies with the people who made a product relying on obvious buggy behaviour, not with the fix for the bug.

@Ammo Infinity:
Seriously, all your comments now are purely to make personal attacks against anyone who opposes this issue or voted for SVC-125. You are not only not posting anything of value, you are also not helping Darling Brody's proposal in any way.

You are clearly incapable of seperating the issue from the person. You continue to take the discussion from technical issues to personal attacks on myself. I will no longer be reading or replying to any of your posts, as my attention is clearly only encoraging your behaviour.

@Haravikk Mistral
Same goes for you. Unless you can defend you comment about me hand scripting all the existing security orbs as being a valid technical point, with a good reason why you felt the need to single me out personaly.

@Everyone
Looks like the people who dont like phased chairs want to make this into a personal flamewar to cover their lack of facts. Don't let them win. Ignore them and post only facts in support of this issue.

Darling.

I singled you out because you are the one who is proposing that every security orb be "fixed" using the "simple" script you suggest. This is technically unfeasible as a large number of security orb vendors no longer exist, many have no infrastructure for deploying updates to their products (since security orbs are simple enough they shouldn't need it), and there are certainly a lot more orbs out there than phased chairs. The simple script change you are suggesting suddenly isn't a simple fix at all, not to mention the added complexity it would add to security scripts.

I do NOT dislike phased chairs, what I dislike are bugs; the fact that fixing this bug breaks phased chairs is unfortunate, but they should never have relied on this bug in the first place as it is blatantly obvious broken behaviour. The result is that what I can see are a load of people who capitalised on this bug in order to sell "solutions" to people, rather than campaigning for an actual solution to the problem.

You show an incredible bias here; you expect voters to ignore all evidence AGAINST this issue? So people should just make uninformed decisions about everything and trust that because you said something, it's obviously right? Voters should just trust that the people who are raising point after point against this proposal haven't a clue what they're actually talking about? This makes it sound like you're against the fundamental ideas of freedom of information, freedom of speech, rational thought, and personal opinions.

Anyone who has voted on this issue without thinking about both sides of the argument should seriously consider removing their vote until they've thought about the issue(s) involved first, uninformed voting only has a negative impact on the JIRA that we do not need.
I don't want people reading my comments and immediately deciding not to vote because of what I say, unless they've first read the proposal and understood the problem.

But don't forget that this is cutting into those who simply need it simply for protection. People who don't really care how much profit the maker collects.

There isn't anything else like this out there at this time. Without this protective content, many users now have to deal with tons of followers. Spengbab boxes, optic nerve monsters, and whatever spam filled crap noobs can come up with.

I want you to remember this as you profit on your security crap until it prevents grid wide movement all together.
Remember it as you sit in your private sandboxes.

There's no way we're punishing people who relied on the function to work as documented. Filing a bug and getting the scanner fixed was the correct thing to do. Any workarounds and hacks are for people who tried to build on top of a bug instead of reporting it, not for programmers writing correct code.

If you want to opt out of being scanned, see my comment above about making a request for that as a new feature.

I'd advise anyone that wishes to hide themselves from sensor based devices to look at SVC-1462. I know I sound a lot like I'm just advertising my own issue here, but no-one else has posted a potential solution that I've been able to find. Do feel free to post alternatives and link them where appropriate if you feel there is another way to solve this issue (without re-introducing a bug).

You're welcome to join us in our private sandboxes. Ferox is open to the public : )

Little point replying to me here, as i wont be coming back to the JIRA.
I dont like to knowingly waste my time.