OpenSim Mantis Tracker
Most of these problems only show up when there is a high object count so I tested with 4.8K objects, mostly single prims, with a total of 8K prims in the sim. All but a few were unscripted PASSIVE objects.
The timings are approximate on my ancient PC (4 year old 3Ghz P4) but should give a good relative guide. The the only differences in the test set up for the before and after figures were the changes in the patch. The figures in brackets are the timings with the patch. The timings were done with llGetTime(). The short times are of the order of 3 or 4 sim frames, the rate at which llGetTime() increments.
Through all of these tests the percentage cpu usage was in the high 90s but no drop in sim FPS or time dilation was shown in the statistics window of the client.
A sensor for PASSIVE objects returned no results after 18 seconds (16 results after 4.5 seconds)
A sensor for ACTIVE objects returned all PASSIVE objects and the avatar as well as ACTIVE objects after 35 seconds (9 ACTIVE objects after 0.06 to 0.07 seconds)
A sensor for avatars took 18 seconds (0.04 to 0.07 seconds)
A sensor with a key or name took 18 seconds. (0.04 to 0.07 seconds)
The following problems were also found and fixed
The sensor reported attachments on avatars.
The sensor reported the object that it was in.
An avatar sensor with the sensor object attached reported the avatar that was wearing the object.
The returned list was not ordered by distance.
The returned list was not restricted to 16, in the case of the scan that returned PASSIVE objects the list was 4,800 items long.
The sensor did not enforce the 96 metre limit.
Avatars with God mode activated are sensed.
If during the sensor an object was deleted there was an error because the collection that was being iterated had changed
There are still a couple of problems. The full logic of combining SCRIPTED with the other constants is not yet fully implemented and the occasional sensing of avatars in the next sim by llSensorRepeat(....) is not yet done. Also some further tiem savings may be possible when the scan includes a large number of possibles like the PASSIVE sensor above. Also there is a possibility that not all places that a deleted prim could cause an exception have been covered yet.
llSensor.patch [^] (17,199 bytes) 2008-10-09 15:18 
