I think this sort of issue like many other LSL quirks such as WarpPos should be left alone... meddling with it this late in the "game" is going to break a lot of legitimate uses of llSitTarget()...

And if you have ever been the victim of a sustained follower attack, a CNPV is a very handy tool to have.

As an additional note... most users of such sensor evading non-physical vehicles crash a lot....

This behavior is out of line with the rest of the functionality of llSitTarget and where an avatar is. In every other case (Ban Lines, Chat, etc) act upon the avatars real location. Due to the potential privacy violations involved, I do not believe letting this bug go is appropriate.

Just because someone has exploited a glitch in the system to make a product does not make it an acceptable bug.

I would like to know how it was done using sit targets, in order to better understand this exploit, but barring that it seems that this is a usefil tool only for greifers and others who want to spy on other avs. I was able to alk and listen on channel 0 right above the ground over my head, and though everyone thought it was hilatious the potential for troublemaking with this exploit is great.

I haven't seen any other use for it but that. Please kill this bug/exploit somehow.

By positioning the prim/vehicle 150 meters away and the avatar 150 meters away in other direction, a sensor still would not be able to detect the avatar.

I refer to these items as Off Radar Chairs. Buy yourself a half way decent radar and you will be able to detect these people without any problems.

I sell an off radar chair and a radar capable of detecting them. There is already an ingame fix for this. I am making this issue closed. The scripters of SL have resolved the problem.

There is no security issue. You can still see their name tag and issue an Abuse Report against the person if they are doing somthing wrong.

If your scripted security device is unable to detect them, talk to it's creator about having them update their sensor methods.

Darling (dont panic) Brody

This is not a bug, it is just the natural evelution of one idea leading into another.

It has existed since the begining of SL and will break a lot of content if changed.

Anyone bothered by off sensor chairs should get an updated sensor script to detect them.

If your solution is this type of thing http://forums.secondlife.com/showpost.php?p=137645&postcount=6 you are dreaming. If it is not that please provide the solution rather than simply claiming one exists.

I'll ask the right Lindens to check this in their next internal triage, to see what they think of it.

There is NO security issue associated with this.
-----------------------------------------------------------------
You can still see them.
You can still see their name tag.
You still see their green dot on the mini map.
They can't violate parcel land entry permissions. ( they are knocked off the chair if they try )
All they can do is avoid the feebie devices that offer people a hug.
There are already improved sensor scripts that detected people using these devices.

It will break content
---------------------------
Changing this would break more than half of the teleporters in SL.
Sensor objects can already move 200m up to detect these agents.
Increasing sensor range would create too much lag.
Sensors can only return 16 agents out of 80 in a region, that is a bigger problem!

Darling.

I think that there needs to be a rationalisation in general of the LSL responses to an av sitting on an object, but in the meantime, the practical effect here seem to be purely to allow people to annoy others by appearing to be in places where they are not.

When someone sits on an object that has had llSitTarget() called upon it, then the sensor is unable to detect them if the OBJECT they are sitting on is outside the sensor's range. This would imply that because the avatar is temporarily part of that object, that the sensor can only detect them if the object can also be detected.

No-one is proposing that llSitTarget() be changed in any-way, but that sensors should be able to detect avatars regardless of whether objects they are sat on are outside the scanner's range or not.

ie - I'm sat on an object, it is outside the scan-range, however my avatar is within the scan range. Therefore I should be picked up by llSensor() and llSensorRepeat() functions.

I'm assuming this is an issue because the sensor is looking first for objects (unlinked prims or linked sets) within the scan-range first, but this will be done by the object's root-prim. Then it is looking at any linked sets it detects to see if any of the child-objects are what it was looking for. When an avatar is sitting on object they become a "child" of that object so are only detectable if the root prim (the object they are sat on) is detectable.

This presumably also means that a large linked-set, with a room prim on one side, is not detectable either if the other side of the object falls within a sensor's range, and the sensor is looking for primitive on that side.

WarKirby Magojiro ,
Security Orbs are not "broken" by this. They were "not" scripted to take this into account. This function of the sit offset has been with us since the begining of SL. All the security orb needs to do is periodicaly jump up 200 meters into the air to detect these people using a sit target to mask themselves from sensors. I am sure this is within Psyke's scripting abilities to do. You can also get the owners of prims over your land and checking if they are in the region for another way of detecting someone without the need for sensors at all.

This function is used extensivly in defensive devices for protection in combat from HUD attacks and some kinds of bullets that can not be blocked any other way.

So the choice is break the defensive devices beyond repair ,or re-script the security orb to take into account something that existed at the time it was originaly scripted, but was overlooked by Psyke at the time.

Darling.

WarKirby Magojiro ,
Security Orbs are not "broken" by this. They were "not" scripted to take this into account. This function of the sit offset has been with us since the begining of SL. All the security orb needs to do is periodicaly jump up 200 meters into the air to detect these people using a sit target to mask themselves from sensors. I am sure this is within Psyke's scripting abilities to do. You can also get the owners of prims over your land and checking if they are in the region for another way of detecting someone without the need for sensors at all.

This function is used extensivly in defensive devices for protection in combat from HUD attacks and some kinds of bullets that can not be blocked any other way.

So the choice is break the defensive devices beyond repair ,or re-script the security orb to take into account something that existed at the time it was originaly scripted, but was overlooked by Psyke at the time.

Darling.

If your avatar is within sensor range, it should be sensed.. That's the clearly documented purpose of the llSensor function, and any deviation from that is a bug, no matter how you look at it.

Is the avatar position detected if the object is within range, but the avatar is not ?

It's as though a child-object is only detectable if the root-prim of a linked set is detected first. Think of it like this:

The sensor first scans for objects (ie entire linked-sets, or unlinked individual prims) within its sensor range. It then presumably goes through the linked set looking for individual child prims (or avatars in our case), checking to see if they are matches too.

It's a fairly sensible optimisation, but in this case it won't work as expected. A special case could be made for avatars which might be easiest, as getting it to work correctly for all objects could either be very costly, or require fairly large changes. I'm interested to see though if perhaps havok 4 might be able to provide some feature for doing this.

Think of it more along these lines; a sensor can ONLY detect a root-prim, or children that are attached to a detected root-prim. It does not seem to detect children on their own unless the root-prim is within range.

In our case the object is a root-prim, and the avatar sitting on it is a child. So all it has to do is sit on an object with a sit-target further than 96m away and the avatar can be on someone's parcel without a sensor being able to detect them.

I see darling brody that you like exploiting bugs in SL. Perhaps this explains your comments.
http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=261671

I did some investigation into this and found that your comment accurately describes how the sensor works (and thus why the observed buggy behavior is occurring). I'll see about getting this fixed.

My thinking is that there might be a way to somehow structure a search based on bounding box rather than what is (presumably) object centre-points. The exact structures used to represent items in the simulator, such as physics structures are not my expertise though so I don't know how feasible it is. Perhaps an item can be marked by centre-point and by a "size" rating which is the bounding box volume. If an root-prim's centre-point is within Xm, or it's "size" is greater than X then it is eligible for return by a sensor, and is passed for a second round of checks to see which prims in the linked set are actually valid.

This behavious is relied on to hide avatars from the sensors of weapon HUDS and anoying follower objects. There is a HUGE number of devices that rely on this for protection. Please do not break content >

Psyke Phaeton,
The URL you provided is for a Rausch weapon that can detect avatars who are hiding in this manner. So you kinda proved my point about being able to script around it. On a personaly note: getting personal like you just did is not cool.

Harleen Gretzky
Sideways sit targets are not reliable for this kind of sensor evasion application because you can be knocked off the prim if there is a No Access parcell between the agent and the prim.

Haravikk:
> Problem is is that if a special case is made for avatars only then it doesn't prevent sensors being unreliable for object applications, okay it's an improvement certainly, but there may be a way to fix it for cases (avatars and child-prims of objects).
I'm not familiar with this problem area so I'll forward along your concern, but I'm happy to work on this issue if it is indeed problematic. Thanks for noting it.

> My thinking is that there might be a way to somehow structure a search based on bounding box rather than what is (presumably) object centre-points.
Your suggestion is excellent. Using a bounding box is a fairly standard way of managing complexity in these sorts of systems and I will look into whether such a thing could be incorporated as an optimization (I don't see any immediate drawbacks to using bounding boxes and this could lead to significant performance enhancement) in the future.

The approach I'm using to resolve this bug is a bit less ambitious since this I am just looking at a short term fix (versus an involved internal rearchitecture), due to the timeliness of this issue. Fortunately, my fix will actually be faster than the prior implementation. All said, there will not be any repercussions to performance from this fix.

And the url Psyke posted, was more about other things you're exploiting. Damage in no damage zones. Anonymous orbiting. Things which should not be possible.

I want a phantom avatar then! if I cannot have a phased one!

http://wiki.patrioticnigras.org/wiki/Aggressive_Follow

Havok 4, even with its avatar movement restrictions, will not resolve this issue. The bump will be enough to jerk the camera around and make the interface unsuseable in follow mode.

In fact, not even stopping collisions will restore the perfectly legitimate functions this hack has come to serve. Traps that occlude agent cameras, URL / IM / Map spammers, and auto-impersonaters all rely on llSensor() to find the keys of thier targets.

If anything llSensor detection should be restricted at the option of the user, with the ability to stop sensor detections hardcoded into the client.

Offset "phasing" is like the warpPos: a clever use of scripting that improves the system.

This is as much a political issue as it a technical one. There are easy workarounds for offset / phasing. The Jira system should not be used as a crutch for the lazy.

And it should be noted that residents who commented negatively also have things to gain. Because in fact, thousands of scripted devices use llSensor. Just as everyone has something to gain from the fixing of almost any bug. The fact that an avatar is not detected when they are in sensor range is clearly a bug. If you want to avoid being sensed, you can just, yknow, not BE there?

The easiest way to avoid things like that is to go somewhere else. And we shouldn't HAVE to work around a bug. Workarounds are a temporary thing until the issue is fixed. And this bug has been causing problems for years. It's time to stop using workarounds. Soft agrees, and has already coded the fix, in response to massive community demand for it. There's no sense whining about it now. Attend havok office hours and ask Andrew linden about a phantom mode.

The only thing this fix will change is that avatars who were not detected by sensors before (despite being in the radius) will now be detected.

Using llSitOffset() for defense is an anti-noob measure now.... it's useless against 'modern' scripted weapons....

As to the issue of evading private sim protection bots.....
Man Trapping and unmonitored tp-home bots should be an AR offense even on private property.... use the red tape.... I don't like being TPed and automatically harassed for flying a magic carpet in a sim when no one is there.....
_HS

Aside from that, Han is right. llGetObjectDetails easily surpasses any need for sensors in such cases. Sensors are needed for things like visitor trackers, security systems, etc, where you have no idea who might be there. If someone is attacking you, it's easy to find out who, for the most part. (and where it isn't, it's likely a bug) and then lookup their key o use llGetObjectDetails.

for a simple way to get someone's key, send an IM to name2key Flow inworld, in this format "n2k <agent name>".

name2key Flow is a bot created purely for providing a name to key lookup service. problem solved.

You wanna fix it? Make it so the AGENT is constrained to the "edge of the world." The only thing that will break is griefers who misuse the EOH and it's clones.
_HS

With the destruction of these scripts you throw us to the noobs and anyone who cares to grief.

They're using throw away accounts that are less than a week old.

If you have land concerns limit av age, don't break my damn non phys that is at best immature and irresponsible ban them, or kick them but don't go breaking content that inst your simply because you can thats not what jira was intended for.

Grow up and make a get object details based sensor with an initial array to detect av names thats how everyone does it in case you were wondering... : /

Why not report a REAL bug like disappearing after you go above a certain height or prims ghosting, or the fact that you can crash a sim in havoc four by simply copy-dragging physical prims into a stack.....

As for this "quick fix" its starting to sound like warppos all over again and its probably gonna wreak more havoc than its gonna solve especially since the device its breaking isn't malicious in the first place nor is it a commonplace freebie

Lindens i ask you please rethink this and don't take away my ability to defend myself from grief since i no longer have live help and no one seems to listen to my abuse reports AT ALL anymore.

This has been my method of protecting myself from grief without linden intervention for a long time now and ESPECIALLY since i don't have the proper means to contact a linden to stop said grief nor do i want to burden a linden for something i just evade with the proper tools.

disgruntled but hopeful
Crimson

You don't like the warning to get off private property? What's wrong with respecting another's privacy? If I stumble/fly or fall into a parcel that tells me to get out...that's what I do. But I have had my vehicles hopelessly trapped in someones nasty red tape and then I get a object return to lost and found maybe days later. I hate the red tape. Neener neener neener.

This is just a war of words between those of you who have been using the BUG to harass and grief others and those that are the victims. What the hell happened? I thought it was a done deal and the issue was fixed.

Kudos to WarKirby for his blatant arrogance. "This is content which needs to be broken" is a line I definitely wouldn't have predicted from anyone with an ounce of empathy, so I guess that says a lot about you. The only time I might ever agree with such sentiment is if said content was destroying the grid or otherwise ruining the game.

This cheap method has been around for ages, and is pretty much exclusively used for avoiding grief. Even in the case where some jerk might be using it to avoid a security device, they still can't put their avatar over land they don't have access to. As was mentioned above, it's become mostly meaningless anyways, with llGetObjectDetails and the ability to make the new search functionality give access to keys from names, although the latter is not something most people know how to do on their own.

Anyhow, let's see what they decide to change.

Just so everyone is clear.

If you put an object 200m in the air, with a <0,0,200> sit target. When sitting on it, your av is offset down 200m. IF you call llSensor near that av, they do not show up on sensor. To sense them, you need to sense near the object they're sitting on. This is a problem, becausxe that object can be in a different sim. You should not have to sense in a different sim to find an avatar in this one, nor should you have to sense many metres away for an object when they're hovering in front of you.

The behaviour that's changing, is that sensing near the av will now detect them, as it's supposed to. This is clearly an unintended side effect of a sensor optimisation, which fails to take into account the special case status of avatars. And as it stands, it allows people to circumvent security systems.

This will NOT change the behaviour of llSitTarget. As has already been pointed out, to work around the current behaviour requires several sensors at long distances. This places more unnecessary load on the sim. Psyke makes security orbs which are a mass consumption product. Every one of his thousands of customers suddenly multiplying their sim load would not be a good thing.

It's simple logic that if an avatar is hovering 2m in front of you, they should be detectable with a sensor. The fact that this isn't the case is a bug. Content which relies on bugs is likely to be broken at any time, and is unwise to create products based upon. In addition, this bug causes problems for other content which utilises sensors.

The fact that something has been around a long time does not mean it is not a bug. the unseating while changing clothes was around for years too. This IS what jira is for. It brings longstanding bugs to linden attention, and allows the community to vote on those which are most important. 71 votes is unusually high, and clearly a lot of people want this fixed.

And again, please stop with the personal attacks. Psyke's products are designed to keep people out of areas, to make up for deficiencies in land controls. They generally use LL provided, TOS endorsed functions like eject, and teleport home. While some people do set them a bit oversealously, the use of these things is not griefing. It is exercising the basic right of a landowner.

A landowner has the right to deny acess to their land to anyone, for any reason. This does sometimes mean people can be an asshole about it, but that's not psyke's fault. Exercising this right is not griefing.
--------------------------------------------------------------

And that's my final word on the issue. The fix is pending, and that's that. Soft has already asked us to refrain from spamming the watchers on this issue, and I'm sorry to have contributed to that. I'm unwatching this issue, and will not respond to any farther comments. The bug is going to be fixed whether you like it or not.

End of story.

• Teleport - this is a legitimate use and shouldn't be broken.
• Avoid sensors - this is NOT a legitimate use as it allows users to circumvent security devices, and it should be fixed.

It is simply not feasible to build a sensor that can work around this, as sensors only work up to 96m, whereas an avatar could be on an object with a sit target greater than 96m. This makes it IMPOSSIBLE for a sensor to pick them up AT ALL, as it can ONLY detect the object the avatar is sitting on, and NEVER the avatar itself.

It's a bitch to explain but the Lindens are understanding it which is great. But I'll try again for the sake of argument:

• When an avatar sits on an object, they become part of a linked-set.
• Sensors can only detect the root-primitive of a linked set.
• Once a root-prim is found, the sensor will look at other primitives in the linked-set to see if they are in range.

So, if you have a box (the root prim) with an avatar on it (child-prim) that's more than 96m away. Then if the root-prim is detected, the sensor will look at the avatar and see that it is outside the sensor range and ignore it. This is okay.
If however the box is outside the sensor's range, then the sensor will NOT look at child-prims and as a result ignore the avatar, meaning the avatar could be right next to the sensor and not be seen.

But its not MY problem. Because i also know how it keeps me protected from the thousands of followers griefers put out.

And the only people who think this is a bug are griefers who arent smart enough to use the workaround.

'people if you fix this your leading way for a bigger issue. if you fix this weapons to kill bots that take a agent off sim will be USELESS. this means people will be unkillable in combat sims.'

This will happen anyways when Havok 4 gets released. Megaprims are restricted to 256m there. So a max diagonal hazard range of 221m if the thing is in a very sim corner. Sit offsets get bigger than that. When H4 comes, you will be invulnerable with a 5-line script. Game Over. The future belongs to player-created combat systems instead of plain vanilla linden combat in Rausch.

Ok. I have decided to give away a few of my secrets for detecting avatars to improving the security orbs' detection, and to squash this debate about it being a security exploit, because it simply is not.

• • • If a security orb was to call the function that returns a list of keys for the people with prims on the current parcel of land, the script would then be able to use llgetobjectdetails to locate the prim owners. Using this in conjunction with the existing sensor scripts will permit you to automaticly locate and deal with people who are on a phased chair.
      ***

My opinion is that this is not a problem that needs fixing by the Lindens. It is a problem with people using security devices that relay on outdated LSL scripts. The Lindens have been working hard to add some dam usefull functions to the LSL that should be incorporated into those security orbs by their creators.

For example I send out weekly updates to my customers to ensure they are always using the very best. If other creators choose not to be as commited as I am, they should not be using the JIRA as a way to avoid scripting their devices properly. The Script Griefing that is going on in the JIRA has to stop. Improving your own product by using the JIRA to break the innovation of other creators is not the way to move SL forward. I agree some things need breaking, but this is not one of them.

Darling.

ps. Anyone who makes use of my innovative tracking script suggestion above had better remove their vote from this issue out of gratitude to me. Or else I will put on my dragon avatar and bite you!

If I see an Avatar standing next to me, I damn well expect my scripted sensor to be able to detect them, regardless of if they're sitting on a prim 300 meters away. It isn't limited to just Security Orbs or Griefer followers, there are several possible uses of a sensor that should trigger a response when an Avatar is in range.

Phased Chairs do not work sideways. They are all scripted to do a displacment of 96+ meters on the Z axis. If they attempt a displacment on the X or Y axis on the mainland the agent is often knocked off the chair due to parcel ban lines. Also it makes the chair useless in combat regions (which is what they were created for) because you can not move within 96m of the region border without the prim your sitting on going offworld and being returned.

[quote]
If I see an Avatar standing next to me, I damn well expect my scripted sensor to be able to detect them, regardless of if they're sitting on a prim 300 meters away. It isn't limited to just Security Orbs or Griefer followers, there are several possible uses of a sensor that should trigger a response when an Avatar is in range.
[/quote]

Using a phased chair is not a convenient way to explore SecondLife. It is something you use when other people are using scripted objects you do not want to interact with. examples
1) You in a combat region and you do not want to interact with the bullets somone is shooting at you.
2) Your in a sandbox and dont want to interact with the hundreds of stupid follower objects that always seem follow you around.
3) Your a griefer trying to avoid a security orb. (I provided a fix for this already)

The bottom line is the Lindens themselves have the ability to hide themselves from sensors. So there must be a lagitimate use for such abilities.

There are some other really cool and usefull side effects of this method that I do not want to publicly discuss here. However if a linden would send me an email I can reply to I will be happy to share.

Darling.

Now as for your three bullet points.

1. If you don't want to interact with bullets... don't go into a combat region
2. There are sandboxes that don't have scripts enabled, perhaps petition for more non-script enabled sandboxes
3. The nastier kinds of griefing don't require you to be in the area long enough to get kicked by a security orb.

And regardless of if a linden can make themself invisible to a sensor, it doesn't mean there is a reason a resident should have that ability.

2. If this fix is "coming if you like it or not", then why not close it anyway?

2. The fix will be marked as "Fixed Internally" by a Linden when it comes, until that time the issue should remain open as it has NOT been resolved.

I know there are a number of interesting discussions that have spawned from this; distinctly separate issues should be filed as new issues and linked as related to this one.

[quote]Most phased chairs are vehicles which can easily fly above ban lines, so sideways sit targets would work, [/quote]

No they will not work. The Ban Lines are enforced for the avatar, not the prim. If your Avatar moves below the Ban Line height they will be knocked off the phased chair just like any other vehicle. Try setting up a 20 meter sideways sit target on a prim next to land with ban lines. When you sit on it you are instantly ejected from the land. You can not use the sit target to bypass the Ban Lines.

[quote]using a combination of x, y, and z you can actually move an avatar up to ~520 meters away (300 * sqrt(3)) [/quote]

(I am assuming you are going to rotate the prim to be above the avatar sitting on it, otherwise your prim will often be in another region and the rider risks being disconnected from SL. See intersim teleport issues for more information on that hazard)
A 512 sit target is not a practicle thing to do because the prim you are sitting on can not move over 768m high while nonphysical. Therefore you are unable to move above ~250m. Many regions in SL have land higher than that!

[quote]Also I do not believe llGetParcelPrimOwners works for deeded objects, the security orbs in question need to be deeded for things like llTeleportAgentHome to function on group-owned land. [/quote]

It does work. I sell a security device called a Prim Bin that makes use of it and is deedable. You can indeed detect and eject people who have rezed a prim over your land or group land.

Unless you have gone in-world and scripted a test, please do not post an opinion. It is difficult enough to get the facts though without getting them mixed up with untested opinions. No personal attack on you is intended. I just dont like opinions passed off as fact in something as serious as the JIRA. We need to get it right for the lindens as they dont have time to sort though misinformation.

Darling.

Just because you can go up to ~520 meters does mean you have to, I simply meant that sideways sit targets on vehicles are possible.

After posting this I did test llGetParcelPrimOwners, it returns nothing in a deeded object. Worked perfect when undeeded. And that is why I used "believe" because I was not passing it off as fact, though that is what the LSL wiki said. But even though I and others could not get it to work you somehow seem to have, so I guess it is somehow possible to use this method in deeded objects.

• Have fun getting raped by random following tentacle monsters and other crap for hours, till someone comes to delete them. *

Fixing this might be useful in your private places, so you have less scripting to do. But for the Sandboxes it's not useful at all though. It's will only be annoying. Because every 0 day avatar beginner script can then follow and annoy you for hours, unless you leave the region or hide in the sky.

With a tiny bit of scripting knowledge it's easy to fix the problem and detect all users on your parcel. No need to change the SL code for that. A sensor prim with a few position changes and you got your avatar list in a few seconds.

Why not just include something like llGetAvatarsOnParcel()?
Instead of wasting your time to break existing content?

Don't get this wrong, I'm neither making any money with sensor evasion tools, nor do I use it regularly.
Fixing this would even save me a lot of work actually, because my combat system does still use sensors and can't detect phased avatars.
But I know that often this is the only way to ignore some of the griefing.

And only because it is a little more work for your security tools scripters doesn't mean this is a Major issue and needs to be fixed asap. It is fixable via scripting.

Fixing this in the SL code will break the content of probably some 100 tools owned by thousands of users.

Staying above the ban lines is a Major Bug with "impact on security and games" as the panic murchants in this threat would have you think. As your unable to go below the Ban Lines without being knocked off your vehicle. The same goes for sideways sit targets. Being able to use this effectivly as a sideways security bypass means you need to be able to go below ban line height. If you do you run a very real risk of being knocked off the vehicle. For this reason alone it is not worth scripting a vehicle with a sideways sit target. All sensor evading chairs are using a vertical sit target for this an many other practicle reasons

[quote]Just because you can go up to ~520 meters does mean you have to, I simply meant that sideways sit targets on vehicles are possible. [/quote]

They are possible on clear land. However most of the mainland is checkerboarded with ban lines which will not permit a sideways sit target to come under the ban height without knowing off the agent.

[quote]After posting this I did test llGetParcelPrimOwners, it returns nothing in a deeded object. Worked perfect when undeeded. And that is why I used "believe" because I was not passing it off as fact, though that is what the LSL wiki said. But even though I and others could not get it to work you somehow seem to have, so I guess it is somehow possible to use this method in deeded objects.
[/quote]

The object needs to be deeded to the land group for it work. As I said before I have a product that uses it.

Azurescens Herouin made a good point with his llGetAvatarsOnParcel() suggestion. It is a far more desirable function for setting up land security or any other type of object (other than a weapon) that needs to track avatars. There is no need for sensors to detect people on other parcels if they are part of your club or land security.

Sure, this is an unintended side effect, but so was warppos. Both have good and bad uses. Warppos was maintained because it added another level of function to SL. So does this. It would be better if could learn to evolve with SL rather than stomp on anything new.

Darling.

But I do not build these things so I defer to your experience and expertise.

The griefer, of course, was long gone.

Of course, the majority of you would say, "why didn't you just teleport away?"

My answer is, "why should I?" I was there to shop. I was where I had a right to be. HE was breaking the rules. I should be able to use a defensive tool to protect myself from his illegal and unwarranted actions, and go about my business and enjoy my day. I shouldn't have to run away from some yutz and spoil MY fun – which is, when it comes down to it, EXACTLY WHAT THE CLOWN WANTS ME TO DO.

These griefer parasites live off our fear and capitulation. Why should we feed them? Leave us the ability to protect ourselves with reasonable defenses! Give us back the ability to take ourselves out of their sights and out of their traps!

This is a good protection from griefers, and as a Road Captain with The Saints of Hell I deal with griefers on a daily basis.
They have never allowed me to cross a banline.
They don't outsmart security systems... eg: HippoSECURE and PDS Orbs are immune from Non-Phys Objects
They are the number one self defense I recommend to my clients.

I own at least three high-quality griefer defense products that this back-door "fix" has broken.

Too bad there's no way to vote for what I think is the correct status of this Jira: "working as designed, dubious enhancement request".

And now it's already deployed.

Also, I recommend anytime anyone is ejected by a Psyke's Defense System, and sent any where other than their Home Destination, they submit an Abuse Report on both Owner and Creator.

As to whoever made the pithy comment about avoiding bullets by staying out of combat areas, you are a FOOL. Why? You obviously don't visit the linden script enabled sandboxes very often. I'm talking about sandbox island, sandbox cordova, and sandbox goguen.

These non physical devices were the only means most residents have for not getting hit by annoying followers and idiots using their weapons in areas where they DO NOT BELONG. And now, that one thin shred of defense is going to be removed over a mis understanding. Sensor detection or not, if someone is nearby, you can still see their nametag, giving you the option of an AR for harassment, and from there its a short step to their key. Get the key, get the avatar.

I fail to see why i should be the one forced to take action when J. Random Jackass comes along in the sandbox and rezzes a bunch of squeaky following cubes that i cannot even escape from! NPV allowed us to sit on an object and the objects either lost track of you, or tried bumping you to no effect. Grief was annulled right there.

There's already a thread on the PN forums re: this. Congratulations guys. You've just made the average resident's life a lot harder, and the greifers much easier.

*edit
Just got back from a bit of testing.

All non physical devices i've been able to test are completely broken. Omicron, Eye of Horus, Quantum Core, Protec, ALL non working.

*edit2
Warkirby, i find it personally disgusting that you make such comments as the ones below in other issues. I guess breaking people's defenses are fine as long as they don't affect you personally? Do me a favor. Spend an hour in a linden sandbox and see how long you go without being orbited or otherwise harassed in some way that these kinds of shields prevent 100%. I'd like to personally thank you and everyone else in here that this problem does not affect for completely screwing things up for the people that it does.

I'm not an ace scripter, but i'd be willing to bet good money on the fact that there is a way to script around sensors not being able to detect people on these. I say its a nice side effect when someone's hellbent on particle/prim spamming you to death, but meh.

=======

"Content that abuses bugs in the system ought not be protected by a "don't break existing content" clause"

Well then. How about "fixing" the warppos hack too? Or how about the neat little bug in llTakeControls that allows you to grab all user input? Or how about reverting every megaprim to normal ?

Those are all bugs, and would break a hell of a lot of things if they were "fixed"
-----------------------------------------------
"make weapons that don't need to abuse bugs"

Oh, why didn't I think of that. I'll just press my magic button and conjure up a new technique.
------------------------------------------------------------

"if you close the loophole everyone has to buy new weapons...."

Why yes, you're quite right.

"Sorry folks. Those fancy weapons you spent all that money on. They're broken now."

I imagine that will go down real well with my customers.

=============

There has to be a better way of solving this other than just elimiating it completely. This "FIX" is more of a "BREAK" and needs to be reconsidered.

"Group Notice From: Darling Brody

http://jira.secondlife.com/browse/SVC-125

Linden Labs broke your PNPV & EPNPV shields. Open this page, login, and complain.
Tell they why it is good, how you use it, how anoyed you are that it is gone, and who is going to refund your money for the broken item. Be Polite, but state that your very unhappy.
Darling"

Darling, I'm turning off my group notices from your group. If I start getting Group IMs in the same vein as well I'll be dropping the group altogether. You make a nice product (not perfect... the UI is a bit complicated and could be a little more user intuitive, but nice). What isn't nice is sending your customers to the pJIRA pages to complain about a feature they most likely don't have much technical knowledge about. Please leave these discussions to those who understand how it things work and not flooded with people complaining "my stuff doesn't work" and demanding refunds. That's not what these pages are for.

Make your case, debate the issue, then let the Lindens weigh the pros and cons and decide what is best. If it means you have to redesign something so be it, but asking your customers to use this forum to complain so you don't have to isn't going to help anything. Things like this go further in making me wary about buying your products in the future than concerns that some of the features I paid for might not work because of fixes in the code.

Bring back my phase capability you maroons, and let's worry about some real issues. Who cares about watching your creepy little avatar sex. Ick!

If these phased chairs are going to open you up to all kinds of griefing, then that indicates a failure in other systems, it does not indicate that this issue is in any-way NOT a bug. It is a bug, and anyone who has based their business on exploitation of clearly buggy behaviour has no right to complain that their items are broken when fixed.

The issues that people are raising with their complaints should be addressed in other ways, for example, an "Invisible Mode" that makes you invisible to scripts. I've posted such a proposal under SVC-1462.

Please do not claim that this issue does not represent a bug, as it does. Fixing it does not break any correctly made content, in fact it FIXES a lot of correctly made content that actually wasn't working properly BECAUSE of this bug.
Your complaints lie with griefing, and scripts that enable griefers.

If this is the reaction that arises every time an actual bug is fixed, then we're never going to get SL stable because someone somewhere probably relies on buggy behaviour. Let's just hope no-one's made a "Sit limbo" chair or exploited one of the other horrible bugs out there.

People should be able to vote against the content breakers who voted for the fix,.

As Thraxis point out; if you don't like the fix, then post a new JIRA issue, don't keep re-opening this in a temper tantrum.

My suggestion is to create any new proposal as "New Feature" since it is requesting a change to correct behaviour, and consider very carefully whether what you are suggesting is the BEST course of action or not, as there are much better alternatives. As I've already pointed out the issue people have with this fix is that allows griefers to target them, this is NOT the cause of that problem, the problem is the griefers, please consider proposing something that provides a better tool against them.

If you have an issue with what scripters have done with this command, the soulution is not to whine and pule to have that command removed or 'debugged'. The soulution is to counter-script a way around it! Having watched the 'balance of power' shift back and forth between offense and defense in SL, I can honestly say that niether camp holds ascendancy for long.

And lets not forget that breaking content is a Bad Thing. Not only does it waste the energies of thoes innovators who are constantly expanding the horizons of what LSL can do, it also gives the feeling that theres no point in innovation if your efforts will ultimatly go for naught. The waste of L$ involved to the parties using thoes scripted objects are immaterial next to the sharp curtailment of the evoloution that makes SL so much fun.

To thoes who have voiced thier opinions againsed llSitTarget, let me offer a small piece of advice: remember what you have done when someone takes issue with one of your favorite commands and abilities, and cries for the nurf bat. Having the shoe on the other foot may well expand your viewpoint to the bigger picture.

This is not the case. llSitTarget() is not the problem here, it is working fine and is NOT bugged as you say, it never had a limit imposed on it.
What WAS broken was that sensors weren't able to cope with sit-targets which placed avatars into their sensor range, while the object itself remains outside. This is what has been fixed. A sensor should ALWAYS return anything asked for that is within its range, that's how it's supposed to work, and anything that prevents this is a bug (unless it was added intentionally as a feature).

All "phased chair" manufacturers as a result were exploiting erroneous sensor behaviour in relation to sit-targets, in order to intentionally evade sensors, which runs counter to how a sensor is supposed to perform. Phased chairs or whatever you want to call them were the ones actually breaking content, this fix has prevent them from doing so.

In summary:
llSitTarget is not broken, because it never said anywhere that sit targets should be within X metres of the object they are added to, range has nothing to do with this bug.
Sensors were broken, because they weren't detecting avatars near to them due to being unaware of sit-targets.

As for compensation, that is the responsibility of the people who sold you a device that exploited an actual bug. Yes, I said bug, not "unexpected behaviour". Unexpected behaviour is doing something that you weren't told NOT to do, a bug is something which breaks a rule that was explicitly imposed, in this case; sensors should sense things.

Working like it is now with the "fix", someone can now arbitrarily attach a sensor follower object to any shielded avatar, and kill that user at any time (hopefully in a combat zone, but there's no guarantee of this). Thus, a griefer can overcome a shielded avatar and kill him/her anywhere in SL. It opens us all up to griefer attacks despite shielding. With this "fix", there is no defense against griefers any more.

Please re-fix this "fix" so that we can once again use shields to repel griefer follower objects and weapons.

I have personally invested a substantial amount of Linden dollars in several combat systems that are now useless because of this "fix". Who is going to pay me back for my investment in these tools I have purchased to defend myself against griefers? I don't think it's going to be the makers of the combat systems, so will Linden Labs now refund my money?

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

Ammo Infinity, I agree with you. The JIRA only voices the opinions of people who want something fixed and does not provide a voice for those who disagree. There should the a FOR and AGAINST voting option. Otherwise people can just rally support from their friends list to get people to vote for somthing to inflate it's figures.

I provited a cure for the inability to detect someone over your own land. Instead of saying "OMG thats cleaver" and using it, I got insain arguments about sideways sit targets which are impossible to script in the mainland due to all the ban lines. They got what they wanted, and now they don't have to fix their scripts which were fixable, at the expence of ours that cant be fixed.

Follow this link and vote YES. SVC-1475

http://jira.secondlife.com/browse/SVC-1475

btw, I already stopped using your product for the most part. It's clunky, full of so many griefing tools and other annoying features they take forever to load and operate. It has a few nice things I like, but loaded with so many griefer tools it's suffering from a major case of feature bloat. There are simpler and better products out there. And they are made by people who don't pull these sort of nasty shenanigans when they don't get something their way... trying to send 1000 attack dogs to whine for refunds when you know very well the only person they can get any compensation from is you. btw, are you going to give us a refund Brody? Somehow I doubt it. Care to prove me wrong?

Now I definitely won't be buying any more of your things. Not just because of the painfully annoying UI you've constructed, but because of the way you try to get things your way with silly "protests" and bully tactics. I tend to patron merchants who I find have a bit more integrity than you possess. What is more, I know a lot of people who feel the same way and word of mouth spreads fast.

Tomomi, with he/she's bad attitude against qc doesnt need to be in our group anyways.

Sensor() is a weapon
llSitTarget() is a defense

Peace please, not war on SL !

Wen.

The contents of your original post have no place in the JIRA. Not only did you reproduce my notice to a private group without my concent, you made demands complete with threats to leave the group if I didnt comply.

I have no time for people who play games or those who cant be trusted to respect others, I removed you from the group for the benefit of everyone, including yourself.

Now the people who read the JIRA will not have to read your complaints about my private group, nore will you be "bothered" by opinions you do not agree with being delivered to you through the group.

Your use of the JIRA for posting two personal attacks on myself is grossly inappropriate.

Darling.

"This has an impact on security and games." ??? Yes? and what exactly can that mean? This statement is so vague and so far reaching that it is bordering on irresponisible at worst and non-professional reporting at best.

So many things in this SL world can have "an impact" on security and games. For some the impact may be a negative and for others the impact may be a positive. To make this statement and leave it blowing in the wind like this is ludicrous. The Phase issue has some really positive impacts that are not implied in the description. How about enabling one to get away from griefing. How about allowing one to have the privacy of determining at least sometimes whether or not you want to be scan, or monitored, or followed or watched or counted or radared or sensed by complete strangers???

Eliminating Phase will give spies and creeps just one more way to make sure they can follow, cling to and grief their targets. Very few griefers use Phase cause it's annoying and they prefer and simple in your face gross attack. But Phase allows innocents a powerful way to sidestep and evade most of these gross uninvited and frequently sexually explicit attacks with the use of passive moves instead of being frozen or caged or pushed off a SIM by some jerk griefer.

Yeah. Eliminating Phase will have an impact alright. One that makes many people that much more available to griefing and harrassment.

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.