|
History
| Log In
|
|
|
|
|
|
Would love to have llGetAvatarKeysOnEstate() certainly. On the issue of llDetected* bloat, a big issue that also needs addressed is the lack of any other way to get the information they provide, as such it would be nice to have more llKey2* calls. I've posted these in SVC-348
Highly useful. This would eliminate SLBanLink.com's reliance on sensors, thus reducing load on sims as well as being useful from a security point of view.
More generally it would make it far easier to monitor a sim without the use of MANY sensors and relay scripts. I linked this to WEB-240 as these functions, especially llGetAvatarKeysOnEstate, llGetAvatarKeysOnRegion would be possible to implement as a capability and from a capability it isn't far to implement as a dataserver event
Why would it need a dataserver event? The information is right there in the simulator. Dataservers are for gathering information about things outside of it, like assets, and agents.
This function should be able to return immediately. One note;
I'd suggest changing the implementation, as the lists returned by these functions could be pretty huge. An alternative would be to do it like object inventory calls: int llGetNumberOfAgentsInEstate() int llGetNumberOfAgentsOnParcel() key llGetAgentInEstateKey(int agent) key llGetAgentOnParcelKey(int agent) Or: int llGetAgentCount(int mode); key llGetAgentKey(int mode, int agent); with constants for mode: AGENT_IN_ESTATE AGENT_ON_PARCEL Your implementation idea sounds neat, but I really thintk it needs a monolithis list return form, too. Having all the keys neatly compiled into a list would be very helpful, and cut down on list building. which would otherwise be required to create one
That wouldn't be a safe implementation, Haravikk, as you can't be sure no agents entered or left the sim while you worked with the data (i.e. between you asking for data on avatar 3 and avatar 4, avatar 3 might leave, making avatar 4 avatar 3... etc. Headache :)
That said, a monolithic list could be pretty unpleasant - I can envision scripts running out of memory because they picked up a list of 50 keys. Perhaps implement this in an event. For example, llGetAgentKeys(int mode) could trigger a sensor event (or it's own event) with the data. Hmm, those are very good points. I guess it's not as big of a deal now that Mono is on the horizon, since it has an upper limit of 64k which wouldn't make a list of 50 or even 100 avatars that big a deal, since it would take up around 5.8k tops.
I guess a list would be the best bet then, with a delay to offset the creation of the list. If it comes to it one script could be made that fetches the list, and then feeds the entries into another script one at a time. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
New LSL Super-Sensors
llSensorRayCollision: Performs a ray collision test agains world geometry and returns the 16 closest objects that the ray collides with. Ray could easily be specified w/ a vector.
llSensorSweptSphereCollision: Same as above, but uses swept-sphere (or maybe capsule) collision testing. (w/ vector and sphere radius)
When I say "world geometry" I mean "objects/prims". Although, it might be interesting to be able to see if a ray hits the ground. Maybe a llDetectedStruckGround or something similar could facilitate this.
I don't imagine that either of these calls would introduce a great deal of lag, and I also don't imagine they would be that hard to add. However, they would provide for quite a little bit of usefulness in creating automated scripts. Furthermore, I believe that a properly crafted specialized sensor call could generate _less_ lag than the usual llSensor("", NULL_KEY, ACTIVE|PASSIVE, 96.0,PI) calls that are in just about every single script that uses sensor.
Just my $0.02
-Thordain Curtis