These forums are CLOSED. Please visit the new forums HERE
llReturnObject() request |
|
Feynt Mistral
Registered User
Join date: 24 Sep 2005
Posts: 551
|
04-30-2006 15:25
It has been suggested in the past in the forums a few times, and a quick search reveals a vote on it as well. In light of the recent escalation in grid wide attacks, I think this kind of thing would fall into the class of a "Very Good Idea." On a related note, increasing the amount of objects a sensor can scan from a mere 16 objects or avatars to a hefty 128 would be beneficial in building an anti-replication scanner/returner system, and would also aid in the construction of automated rental spaces (vendor areas are rarely limited to 16 objects, and rented houses are CERTAINLY not limited to only 16 objects).
_____________________
I dream of a better tomorrow in SL!
You should too. Visit, vote, voice opinions. Support CSG! Tell LL how much it would mean to subtract one prim from another! Prim Animation! Stop by and say something about it, show your support! |
Torley Linden
Enlightenment!
![]() Join date: 15 Sep 2004
Posts: 16,530
|
05-02-2006 17:22
I'm asking further for any comments and insight... hopefully more will vote too, Feynt.
About the sensors--I've felt this way before, when going to crowded parties and wanting to check who's around me (without name tags all bumping around). The number can be a funny one for people not familiar with powers of two. _____________________
|
Kelly Linden
Linden Developer
Join date: 29 Mar 2004
Posts: 896
|
05-02-2006 19:07
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. _____________________
- Kelly Linden
|