|
|
|
I can change the scan radius to 10 meters to fix it, but then I have to go through putting out an update, and even that won't help people who expect their sensors to work properly. I doubt I'm the only person who relies on sensors returning accurate output.
Would be nice if they did a bit of unit testing before they released these updates to a production environment. Elevated this to show stopper.
Changing to Normal as this doesn't affect SL in a whole and there's a bugfix possible, too. Periodically checking the llGetNumberOfPrims if it changed back to a lower value can test if an agent is still sitting.
Nonetheless the behaviour of llSensor changed and should be at least documented what changes happened to the function. Also 1 meter seems to be the break off point, anything above 1 meter, even 1.1 meters seems to work.
I am setting this back to Critical. Yes there is a fix, no that fix doesn't do any good for existing content. I don't think it's a Showstopper, but they need to fix this soon because it breaks existing content in a way that the end users cannot do anything about.
This is definitely not a Normal priority. I think critical is right for a content breaking bug.
I don't use sensors below 1m, generally, but I can certainly see the advantage in doing so. Ah. A thought. This may be related to
Have you tested it on a standing avatar? I don't think that the other methods suggested above should be considered a workaround for the underlying bug, because they only work in this specific instance. They don't get around the underlying breakage.
So are you sure that all sensors of 1.0 meters and under are breaking, or just trying to sensor an avatar that's on the other side of a sim border? It's hard to tell from the description. Sensoring people on the other side of a sim border has always been wierd so I usually throw away anything that comes from invalid coordinates. In this case, it is:
llSensor("", owner, AGENT, 1, TWO_PI); Thanks Huns and others for your reports – I'm asking our devs in Studio Blacklight (focused on critical issues) to investigate this ASAP.
This appears to be fixed by yesterday's update. Thanks Torley!
Seems like it's broken again. I don't know what happened.
@Huns: Crap, I'll find out.
Huns can you provide a test script that shows the broken behaviour or drop an object on my av that shows the broken behaviour, our test scripts based on the information above are working ok.
Thanks. I put together a test object from one of my airplanes (removed everything except the bare minimums.) It seems to be detecting my avatar at its true position (root + local position of seat + sit target offset.)
I think the old behavior was to return the avatar as being at the object's root position. So, I could fire a sensor with a radius of 0.2 and it would work, even though the avatar was further than that from the object root. It breaks old content so it's a bit of a hassle, but on the other hand, if the old behavior was incorrect I can see the desire to fix it. I will release patched versions of my aircraft. Was this an intentional change? Probably a result of
Edit 2: Re-duping as
"Was this an intentional change?"
Huns, the change was intentional. This was being used to create offset seats so people could appear to be located in a different parcel, bypassing home security orbs and similar. Resolving an issue as a duplicate is not saying the issue itself is resolved, it is merely saying it is a duplicate issue.
@Soft Linden
It was not being used to make someone appear to be on a different parcel. Due to ban lines it is not possible to create a reliable script to do that. Any offset seat will using the Z offset and be over the same parcel, and as such can be seen through scritped parcel land tools. I posted a script to do just that to the other related issue. Vehicles can fly above ban lines, so why is it not possible?
@darling - It's unfortunate that some content broke, but developers finding and relying on bugs are taking a huge risk when they write scripts against the bug instead of reporting the bug so that we can fix it. Much more content was fixed than broken by
We do try to maintain backward compatibility for LSL bugs where use doesn't interfere with people using the function as documented. My restoring llSetLinkPrimitiveParams being used to reposition seated avatars was one good example of this. But there is absolutely no promise or guarantee when relying on undocumented behavior that has negative effect. Consider http://jira.secondlife.com/browse/SVC-1475?focusedCommentId=46956#action_46956 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
2/1/08 rolling restart breaks llSensor()
key user = llPermissionsKey();
if(llGetAgentSize(user));else
{//Do this when booted
}
Or you could use llGetObjectDetails
Course this doesn't help with the products already sold.