SLJiraStats Bug: SVC-1150 |
|
| SVC-1150 | llOverMyLand returns false positives when avatar is not over owner's land but close by in another sim | | Reporter: | Carrah Rossini |
| Assignee: | Irie Linden |
| Votes: | 8 |
| Environment: | Windows XP |
| Status: | Resolved |
| Resolution: | Fixed |
| Created: | 2008-01-04 14:57:49-05 |
| Updated: | 2010-05-13 11:52:35-04 |
| Linden ID: | DEV-44400 |
| Components: | Scripts
|
| The llOverMyLand is supposed to return true when key of an avatar/object is over the land owned by the script's owner. However, it also returns true when the script is located close to sim border and the detected avatar is in another sim.
To replicate:
- create a script which uses llSensorRepeat
- inside the sensor function, place if(llOverMyLand(avatarkey))llInstantMessage(avatarkey,"you aren't over my land");
- place the script in an object in a parcel on one sim close to a border
- fly across the border to another sim, you will get the instant messages.
This affects several security systems in second life, which spam messages to lawful residents of properties in sims neigbouring plots which use such devices. |
| Comments |
blasius messmer 2008-04-27 12:23:07-04 I have experienced the same issue. Proximity to the region border does not appear to have any effect on this issue, as I have reproduced it using the maximum scan range of 96 m, with the scanning object located 50 m from the border, as well as 5 m from the border. In both cases, an AV in the next region, but within the max scan range returned a positive value from llOverMyLand(). Performing the same test, while the scanner and AV were in the same region, worked as expected using a variety of ranges and distances from the parcel border.
Here is a script that can be used to test this. Note, the range for this script is 50, but I have tested it with a variety of ranges.
key CreatorKey;
default
{
state_entry()
{
CreatorKey = llGetCreator();
llSensorRepeat("", "", AGENT, 50.0, TWO_PI, 5.0);
}
sensor(integer number_detected)
{
integer i;
for(i = 0; i < number_detected; i++)
{
if (llOverMyLand(llDetectedKey(i)))
llInstantMessage(CreatorKey, llDetectedName(i) + " is over my land");
else
llInstantMessage(CreatorKey, llDetectedName(i) + " is not over my land");
}
}
no_sensor()
{
llInstantMessage(CreatorKey, "No AVs in sensor range.");
}
}
One other note is that all of my testing was done using a deeded object, as the land I own is all deeded to my group. It may be worthwhile for someone to test this on land that is not deeded.
| Harleen Gretzky 2008-05-21 10:52:33-04 This is an old bug, when using llOverMyLand I have always checked the position like so to avoid this bug:
// Check for sim boundary bug:
// position should not be greater than 256 or less than 0 in either the x or y axis
// Make sure it is not the owner and make sure they are over the owner's land
vector AVpos = llDetectedPos(j);
if ( llDetectedKey(j) != llGetOwner() && llOverMyLand(llDetectedKey(j)) && (AVpos.x > 0 && AVpos.x < 257) && (AVpos.y > 0 && AVpos.y < 257) )
You can also use llGetAgentSize since it will return ZERO_VECTOR for any agent not in the sim.
if (llOverMyLand(key agent) && llGetAgentSize(key agent) != ZERO_VECTOR)
| Carrah Rossini 2008-05-21 17:47:17-04 Yes it is an old bug.. its been opened since January 
kidding aside.. llGetAgentInfo(key agent)==0 (return 0 means agent is not in the same simulator) will also work as a "fix". Still, it would be nice if the function worked as the Linden intended.
| Melany Lunasea 2009-01-07 16:15:58-05 I've tested this with multiple ranges as well... The failure isn't within llOverMyLand, it's in llSensorRepeat.
Reproduce the exact same test scanario as above, only instead of llSensorRepeat, use llSensor from within a timer event. *NO* false positives are returned. You'll also notice if you have a hover text, OwnerSay or other messaging clause in there to tell you when and at what range an avatar has been detected that llSensorRepeat will return positives from *thousands* of meters away at times.
The relationship to llOverMyLand is iintriguing, and should still not fail if in fact the contition is ( !llOverMyLand( foo ) ), however, the behavior difference in llSensorRepeat from llSensor is quite literally overriding all test measures within the sensor event. When llSensorRepeat finds a target outside of it's scan range it will be a positive hit regardless.
I will add however, that the combination of llSensorRepeat with llOverMyLand *does* work as intended within the same sim the object/script is housed. It fails across sim boundaries and won't matter how you set the scan range. I have proofed this many times over.
It's also of no consequence if your script is compiled to LSL or for MONO ... both screw up equally as well.
Some of the workarounds for this are quite extravagant. It may be simpler to use a seperate script for the sensor event so that too many steps don't b
need to be taken in a main scripts timer event , and simple llMessageLinked the sensor infirmation.
Bottom line :::: llSensorRepeat needs an overhaul ::: llOverMyLand should probably include simulator infirmation internally so as not to lose cohesion across sim boundaries.
| trodden miles 2009-05-23 16:17:31-04 Problems with llOverMyLand still can't be ruled out. This is because llSensor doesn't scan across sim boundaries, while llSensorRepeat does.
Therefore results from using llSensor don't constitute a valid test for llOverMyLand because agents in other sims will never be detected.
llSensorRepeat will detect agents across sim boundaries.
Reference: http://lslwiki.net/lslwiki/wakka.php?wakka=llSensorRepeat
I do agree with Melany that the llSensor family needs an overhaul.
| Milo Linden 2010-04-23 11:15:01-04 Targeting Server 1.40
|
|