|
History
| Log In
|
|
|
|
|
|
[
Permlink
| « Hide
]
Tsukasa Karuna - 13/Apr/07 08:12 AM
I think they work by forcing your avatar so far underground that they become out of range of sensors. Aye, it has an impact on security and games, but i think it's just another step in the arms race.
it woudl be interesting to have more specifics on how this is done
This is not an unknown script method. The particular call involved, llSitTarget() is often used to teleport agents between floors in buildings.....
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.... Fixing where an avatar is, compared to where an avatar is detected by sensors when their position is offset by a sit target would NOT "break a lot of legitimate uses of llSetTarget()..."
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. Having purchased this 'device' out of curiosity (it's cheap) and tested it at a party (with FULL PERMISSION of landowners, lol) I can safely say that this is one loophole that needs to be closed.
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. You just use a llSitTarget so that the sit target is more than 96 meters away from the prim you are sitting on, the limit of llSitTarget is 300 meters. Sensors will detect the true position of the avatar as long as the prim is in the detection zone. Making the prim a vehicle gives you the further ability to move around. llGetObjectDetails will report the true position of the avatar anywhere in the sim, but requires the avatar key to be known.
How would you fix this: Fixing where an avatar is, compared to where an avatar is detected by sensors when their position is offset by a sit target would NOT "break a lot of legitimate uses of llSetTarget()..."
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. OMG. What a lot of fuss over nothing.
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 The same people who created the scripts to avoid llSensor have created new sensor scripts that are able to detect these off radar chairs.
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. You can close this all you want and I will just re-open it. The ability for an avatar to be in an area and also undetected by llSensor is a bug.
the sit distance should be within the range of llSensor or the location of the avatar (not where they are sitting) should be what llSensor detects.
If your solution is this type of thing http://forums.secondlife.com/showpost.php?p=137645&postcount=6 Thanks, I got your email, Psyke – if this really is an important issue to many Residents, they should vote and comment. There isn't a substitute for garnering community support via individual opinions of people who care.
I'll ask the right Lindens to check this in their next internal triage, to see what they think of it. Torley Linden
There is NO security issue associated with this. It will break content Darling. Darling brody, you are wrong, I have been victim of this and there was no green dot on mini map. There was no detection what so ever until an IM was received and even then, there was no green dot. I can only assume land ban held, but can't be sure of that either. I never saw anything until I got an IM and then an hour''s worth of conversation and a photo was sent to someone else! This is an issue that needs fixing.
I would say that this is a bug - it is true that in many cases an av is treated as just another prim in a linked object when sitting on something, and this may be beneficial (e.g. moving the av's position via llSetLinkPrimitiveParams) but in this case it seems as if the only use here would be to avoid sensor scans. One can move an av about with animations but that is limited to 10m - this has the whole 300m range! There is absolutely no content apart from sensor-avoidance devices which would be broken, and in fact, this bug breaks sensors.
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. It seems like this could be fixed without breaking existing content. Just a matter of making the avatar detectable when using sit targets, no?
Darling Brody I think you're misunderstanding what the issue is.
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. This is definitely a bug. If the avatar is there, they should be able to be sensed, regardless of the positioning of the object they're sitting on. Psyke is the creator of many security orbs, as I'm sure you're aware. This hack breaks HIS content, and should not exist. Logic dictates that the avatar should be sensed, and I can't agree that it';s anything other than a bug. The only content that will be broken is radar evasion devices which exploit this.
Whisper Dallagio,
An avatar on a sit offeset is most definantly shown on the minimap correctly. I am willing to demonstrate this to you at your convenience. ----------------------- WarKirby Magojiro , 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. Whisper Dallagio,
An avatar on a sit offeset is most definantly shown on the minimap correctly. I am willing to demonstrate this to you at your convenience. ----------------------- WarKirby Magojiro , 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. It doesn't make sense that an object should have to work around an exploit of an issue. If you want to avoid sensors, just don't be there. There's no need to hide from such things when you can teleport thousands of miles away at the touch of a button.
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. Haravikk:
Is the avatar position detected if the object is within range, but the avatar is not ? Nope. The position used is the correct avatar position, but only if the root-prim of the linked-set they are sitting on is also within sensor range.
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. So if the avatar is more than 96m from the object, a sensor cannot possibly get the object and the avatar together in one sweep ? And therefore cannot detect it at all?
As far as my attempts have found yes, only the object is detected. Presumably the sensor will check if the avatar is in range in this case, and dismiss it because it's too far away.
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. Thanks for all your hot votes + comments on this, and thanks WarKirby for the email reminder. I'll ask our developers today to look at this issue again.
Thanks Torley and WarKirby.
I see darling brody that you like exploiting bugs in SL. Perhaps this explains your comments. Haravikk Mistral:
> It's as though a child-object is only detectable if the root-prim of a linked set is detected first. ... > 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. 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. The question then is what the best solution to this is. The main issue being that the root-prim first type searching is a fairly sensible optimisation.
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). The reason for the test is presumably because it significantly reduces the number of nearby objects that need to be tested for range. So simply testing EVERY item in range may increase the burden of sensors considerably. 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. @Darling: A sit target works in more than one direction, so just jumping up 200 meters to detect these can easily be scripted against too by having the sit target use large X and Y. And the prim does not even have to be above your land so detecting prim owners would not work either.
Sensors were assuming that agents sitting on prims had zero offset. That assumption is inherently what was causing this issue. Thanks everyone for your comments and reports, those were all very helpful for tracking down the behavior.
Torley Linden & Seraph Linden
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, Harleen Gretzky darling:
> Please do not break content >  Thanks for voicing your concern, I'll leave it to Torley and others to decide on how best to address your issues. Haravikk: > 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 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. This is content which needs to be broken.
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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Closed
Major
llSitTarget allows evasion of being detected by llSensor
