mulling llGetRegionAgents()

[Talia Davidov]

With the maintenance going on this week, I didn't want to do any real work last night.  Therefore, I played with the new llGetRegionAgents() function.  Just some random thoughts and ramblings, ignore or comment on as you wish . . .

First, it seems to work exactly as advertised.  Always a good start.  The example provided on the wiki is good as well as it gave me a clue how to catch if no one was in range, like the no_sensor event.

Most of my products have a function where the user can scan for Agents and then perform some action on them.  I typically limit the sensor range to 20m.   My thoughts on this new function was that I could use it instead of the sensor to get around the 16 Agent limit.  I also have always got inconsistent scans of seated Agents.  I pick them up most of the time but not always.

The function worked quite smoothly as a replacement for the sensor.  I used llGetObjectDetails combined with llVecDist to implement the range limit.  But here is where I got to thinking . . . Before, I simply called a sensor with a specific set distance.  Now I am calling three functions to get the same data.  In addition, before I knew I would have at max a list of 16 to work through.  Now, I could have up to a hundred.   If I switch to GetAgents, am I setting myself up for scripts with more processing time and more memory taken?  

Like I said just me mulling over the new function and rambling on about it.  I do like the feel of the code with the new function.  Seems cleaner, but that could just be me.

Talia

[Rolig Loon]

You can always filter the results of your llGetRegionAgents query, as you seem to be doing already.  Once you have the UUIDs in a list, using llGetObjectDetails to find each av's position is easy.  The result is faster than sending out a flock of radar drones to cover the same area.  You don't need to bother the servers by running all those sensors, and you don't have to worry about whether they double count some avatars and miss others -- either because the sensors didn't overlap properly or because you hit their 16-av limit.  All in all, there's a large potential savings in server load and a great improvement in reliability --- up to 4096m too.  It's a lovely addition to LSL.

I played with the function myself yesterday, and turned out a sim-wide scanner that uses < 0.03ms of server time and doesn't appear to create any measureable lag.  You can see my description of it at https://marketplace.secondlife.com/p/Whos-There/3498932

[Talia Davidov]

OH I am quite sure of its benefits for items like sim wide radars, don't take my mullings wrong.

I am just wondering if I am doing more work for a 20m scanner using it then I would jsut doing a sensor.  I am going to do some comparison runs tonight.

[Talia Davidov]

Decided to answer the question for myself. Oddly enough, in my tests, the sensor took longer even though the GetAgents had more agents to process in my test conditions.

Quite interesting.

As I stated I knew it would be better for sim wide things, it was the 20m scans I was wondering about.  And it seems to be better there as well, at least in script processing time.

/me happily goes to code

edits to add

Oops . .spoke too soon.  Ran my test 10 times, and which route was faster flopped back and forth.   Probably because of sim lag.  Regardless the times were close enough to the same that GatAgent stills seems a wise choice for a close scan as well.

Just my thoughts on it.  . . .

 

[Rolig Loon]

Yes, if you're doing a 20m scanner, then the advantage is wasted, since you'll be throwing away most of the information you gather from a much larger volume of space in order to get the few bits you want.  Once you start balancing llGetRegionAgents against a scanning system with moving scanners, though, the comparison starts to look attractive again.  A single scanner is limited by the 16-person cap, which you typically beat by scanning a smaller area at a time, moving the scanner, and shooting again.  That means adding the overhead for doing those multiple scans, communicating the results, and then sorting them for double hits.  The more of that you do, the better llGetRegionAgents looks.

ETA:  Aha.  Even better than I thought.  I'm glad you did that experiment.

[Innula Zenovka]

I guess one reason for it being faster for the 20 metre stuff might be the sim's having to find less information.  As I understand it (from an Linden comment in a very old secondlifescripters post), llSensor actually fetches all the llDetectedWhatever stuff, even if you don't use it in the sensor event.    

 

[Talia Davidov]

Yes I agree Rolig quite a usefull new function.  And really, even if it took double the time of a scan, I suspect it would be worth it for my use to get around the 16 limit.

Talia

[Innula Zenovka]

Arrgh... Via Nalates.

llGetAgentInfo shipped with a bug, SCR-311.

It works fine, unless it's called from an attachment, in which case it returns an empty list. Kelly Linden promises in the jira that it will be fixed in a future release.

 

[Rolig Loon]

Wouldn't you know it?  A new shiny apple with a worm in it.

I tested it in an attachment yesterday, but only with AGENT_LIST_REGION, which works fine.  I hope that a "future release" with a fix for the others isn't too far in the future.

[Ela Talaj]

I would suspect that llSensor() is a wrapper for llGetRegionAgents(), which was always there just not user-accessible. Sensor does get a full list of agents in the region and then filters out by distance and returns first 16 from the filtered buffer. If the above is true llGetRegionAgents() would be faster even if with the same filter implemented in script. Don't forget that Sensor() results are not returned to user but put on the events queue.

[Helium Loon]

---

Ela Talaj wrote:

Don't forget that Sensor() results are not returned to user but put on the events queue.

---

 

^^^^ THIS.

 

llGetRegionAgents() is a immediate return function.  Sensor() results are a queued event.  While the processing you are duplicating in LSL to imitate a sensor using llGetRegionAgents() is much less efficient than the server-side compiled C++ the sensor event filtering is using, the delay inserted by it being a queued event adds a significant delay on any but the most low-load sims.

I think they should just add a filtering parameter or two to llGetRegionAgents() so we can filter based on range and such.  Such a filter would work much faster, and reduce overhead in scripts.  It would also pretty much make the sensor event a legacy event.....as it would be much easier to just get the agents directly.

 

[Rolig Loon]

---

Helium Loon wrote:

---

[...]  I think they should just add a filtering parameter or two to llGetRegionAgents() so we can filter based on range and such.  Such a filter would work much faster, and reduce overhead in scripts.  It would also pretty much make the sensor event a legacy event.....as it would be much easier to just get the agents directly.

---

I agree. Having to filter llGetRegionAgents seems clumsy and an unnecessary use of server resources.  I'm hoping that the unused parameter list that's built into the function will include that sort of filtering.  I can't see sensors becoming obsolete, though.  After all, there are many things to look for besides agents, and there are other uses of sensors too (here, I'm thinking of the common hack of using llSensor Repeat as a spare timer).

[Helium Loon]

---

Rolig Loon wrote:

---

After all, there are many things to look for besides agents, and there are other uses of sensors too (here, I'm thinking of the common hack of using llSensor Repeat as a spare timer).

---

 

True.  And I'd never considered using llSensorRepeat() as a spare timer before.  That's both sneaky and brilliant.  Though I do wonder about how the extra load that would impose.....

[Rolig Loon]

I worry a little about that too, but I have used that trick only very sparingly, and for times when I need a spare timer with a fairly long trigger time, so I figure that I'm not abusing the servers much.

 

llSensorRepeat("Just_me",NULL_KEY,AGENT,0.1,PI.60.0);[  .... blah blah blah .... ]sensor (integer num){}no_sensor(){    llSay(0,"One minute has passed.");    // Or whatever else I needed the timer for .....}