llReturnObject(), Magic Number 16 & Other fun
|
|
Travis Lambert
White dog, red collar
Join date: 3 Jun 2004
Posts: 2,819
|
05-02-2006 20:44
Kelly Linden recently responded in a Linden Answers post: From: Kelly Linden llReturnObject:
One piece of many that caused Sunday's outage to be as long as it was, was asset server load and inventory database load from objects from the attack being returned. This caused a backlog which caused other problems. While llReturnObject is a good idea for other reasons, such as automated rental property management, it is really probably NOT a good idea for grey goo handling. Grey goo needs to whenever possible be deleted and not returned. We currently have several projects in this regard that have been bumped to very high priority, for obvious reasons.
Magic Number 16:
This limit is not arbitrary but is memory based. Every time a sensor sweep is performed, ALL the data possible to get from an llDetected* function is stored for every object or avatar that is sensed. That is 3 keys, 3 vectors, 2 integers, 1 rotation and 1 string, although 1 vector and 1 integer may only be valid for touch events. 16 of those is reasonable to store for any pending sensor event. Increasing to 128 would increase the memory requirement of every sensor event by 8 times which would have a negative impact on script and sim performance. It is possible that later we will decide it is worth it, or future changes to the system may make it less of an issue. However, for right now, this is not being worked on. Before I stuck my uneducated head out and made a follow on post, I thought I'd bring it up here for discussion. llReturnObject()I understand that while llReturnObject() would be fantastic for automated rentals & more - it wouldn't be so great as a guard against grey goo attacks because of the database load. Ok, fine. What about llDeleteObject() as a companion? Providing it would only function on the script owner's land - couldn't that help in the fight against grey goo? Magic Number 16I understand that the reason that the detection limit on llSensor is clamped at 16 agents, is due to memory constraints as a result of the amount of data coming back. What if llSensor & llSensorRepeat were broken up into a bunch of additional, seperate functions, that each had a smaller & more restrictive data set? Such as - llKeySensor(), llVectorSensor(), llStringSensor(), etc? Could that be a viable way of upping the 16-agent limit to something like a more useful 128? Please, Discuss 
_____________________
------------------ The ShelterThe Shelter is a non-profit recreation center for new residents, and supporters of new residents. Our goal is to provide a positive & supportive social environment for those looking for one in our overwhelming world.
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
05-03-2006 03:07
Hmm, I like your idea for the limiting of sensors, except I'd make it more general and have something like a modified llSensor/llSensorRepeat function like:
llSensor(string name, key id, integer type, float range, float arc, integer returnType);
Where returnType has constants like:
SENSOR_KEY
SENSOR_NAME
SENSOR_VELOCITY
SENSOR_POSITION
etc. etc.
This way you only get the information that you intend to use (most of the time I only care about key and position).
_____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)
|
|
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
|
05-03-2006 12:57
I IMed Kelly about this. Got a response. They seem to be tending to having a bunch of calls to get more info about an object by key. Also, having a way to enumerate the objects on a parcel rather than trying to use sensors for that. Though that seems mostly oriented towards responses to griefing than the kind of thing I use sensors for, and I hope they don't just implement that. They'd certainly save memory with an llSenseKey/llSenseKeyRepeat pair. So you might do:
// The stupidest shield script EVAR
default
{
state_entry()
{
llSenseKeyRepeat("",NULL_KEY,AGENT,96,PI,1);
}
sensor(integer n)
{
integer i;
vector pos = llGetPos();
for(i = 0; i < n; i++)
{
key k = llDetectedKey(i);
if(llVecDist(llKey2Pos(k) + llKey2Vel(k), pos) < 0.5)
llOwnerSay("Duck! "+llKey2Name(k)+" is gonna hit you!");
}
}
}
|
|
Travis Lambert
White dog, red collar
Join date: 3 Jun 2004
Posts: 2,819
|
05-03-2006 19:41
The ability to enumerate avatars on a parcel, and having that data exposed thru a function call is an interesting (and quite useful) prospect I hadn't considered. Neat idea that could be a useful tool in its own rite. I suppose this data is somewhat being collected already - via dwell.
Agreed though, less of a swiss-army-knife than a sensor is in its current form.
_____________________
------------------ The ShelterThe Shelter is a non-profit recreation center for new residents, and supporters of new residents. Our goal is to provide a positive & supportive social environment for those looking for one in our overwhelming world.
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
05-04-2006 04:24
From: Argent Stonecutter
// The stupidest shield script EVAR
default
{
state_entry()
{
llSenseKeyRepeat("",NULL_KEY,AGENT,96,PI,1);
}
sensor(integer n)
{
integer i;
vector pos = llGetPos();
for(i = 0; i < n; i++)
{
key k = llDetectedKey(i);
if(llVecDist(llKey2Pos(k) + llKey2Vel(k), pos) < 0.5)
llOwnerSay("Duck! "+llKey2Name(k)+" is gonna hit you!");
}
}
}
The slight problem with that is that llKey2*() functions would fail for avatars that cross the sim border after/while the sensor information is being compiled. Granted you can check, but I kinda like the idea of sensors being a snapshot of your area at the time it fires. What about just having an llSensorFilter(integer types) function with the same sort of constants as I mentioned above (so you can retrieve key, name, velocity etc.)? So you'd do: default {
state_entry() {
llSensorFilter(SENSOR_KEY | SENSOR_POS);
llSensor(NULL_KEY, "", AGENT, 96.0, PI);
}
sensor(integer x) {
llOwnerSay("I found "+(string)x+" avatars with the following ino:");
string prefix;
while((--x) >= 0) {
prefix = (string)x+": ";
llOwnerSay(prefix+(string)llDetectedKey(x));
llOwnerSay(prefix+(string)llDetectedPos(x));
llOwnerSay(prefix+llDetectedName(x));
}
}
}This would output something like: I found 1 avatars with the following info: 0: 5748decc-f629-461c-9a36-a35a221fe21f 0: <128.00000, 128.000000, 128.000000> 0: The last line returns a null string (""  because it wasn't requested by the filter. The default filter would of course by INT_MAX (ie: all information).
_____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)
|
|
Argent Stonecutter
Emergency Mustelid
Join date: 20 Sep 2005
Posts: 20,263
|
05-04-2006 07:54
From: Travis Lambert The ability to enumerate avatars on a parcel, and having that data exposed thru a function call is an interesting (and quite useful) prospect I hadn't considered. Not just avatars, any objects. Kelly indicated the new functions would work on any object keys returned via this future llEnumerateObjectsOnParcel() call (from the llDetectedKey(i) call in the associated sensor() handler or enumerate() handler or whatever they used), not just avatars. The names of the functions are my extrapolation, they will almost certainly not be llKey2Foo and llSenseKeys and llEnumerateObjectsOnParcel... Yes, the downside is that you would likely have some keys that were out of range by the time you used them. The upside is that the returned value would be the returned value at the time the call was made, not the time the scan was performed, which would make the precise use of llPushObject for detailed avatar movement much simpler. |