[sldev] A thought on how to lower resources used by sensors

[ordinal.malaprop at fastmail.fm]

I do quite like the idea that scripts can only detect things in range,  
actually, it has a certain "fairness" to it and it is appropriate to  
times when we all lived on the mainland and shared the environment.  
But then, so were telehubs. And things have gone beyond the point  
where knowing who is there is only appropriate within sensor range,  
because there are so many other functions which don't care.

Firstly there is the open-sourced client, which as has been said knows  
who is in which sim, but secondly there are lots of sim-wide LSL  
functions now such as llGetObjectDetails and llRegionSay which don't  
care how far away you are. It used to be the case that to track  
somebody a script had to be within 96m and have fewer than 16 people  
in-between; that isn't the case any more, and a good thing too, as  
llGetObjectDetails is _far_ more efficient.

It also has not kept up with changes in the style of land ownership,  
particularly private  or single-owner sims which may be themed and  
where the owners and visitors wish to have certain sim-wide systems  
operating. I have an openspace myself, where I have systems running  
that require me to know who is there, and it is ridiculous that while  
I can track them endlessly once I know they have entered, to find out  
whether they are there at all initially requires me to have a sensor  
grid.

The main complaints when I have seen proposals on this theme seem to  
come from one or two developers of "shields" who use hacks to keep  
avatars out of sensors, and quite honestly this is not enough to count  
as unacceptable broken content in my opinion, particularly as so many  
"shields" are abusive anyway.

On 18 May 2009, at 21:39, Thomas Grimshaw wrote:

> The probes can only uperate at up to 4,096m and can scan 96m higher  
> than
> that..
>
> But the point is still absolutely valid. It's already perfectly easy  
> and
> possible to scan an entire sim, and everyone I know has a radar which
> does this.
>
> Absolutely +1 for unrestricting sensor range. Whoever initially
> implemented this restriction was an idiot. :/
>
> ~T
>
> malachi at tamzap.com wrote:
>> Kelly,
>>
>> what privacy issues are you speaking of.. because as it stands agents
>> are already using sim crippling scanner probes that report the entire
>> list of keys in a region even to the point of upto 100,000m in
>> altitude. and the lag produced by these probes is horrible.if there  
>> is
>> a privacy issue then its already been violated by the standard
>> llSensor calls. i was only suggesting a way to help bring resource  
>> use
>> down by implementing a call to the server to get the list of agent
>> keys in the region eliminating the need for probes flying all over  
>> the
>> sim to get data that is already there.
>>
>> i understand that people dont want to be seen on sensors because they
>> are afraid they may be attacked by griefers using the technology. but
>> we already have the ability to find them on the sim no matter where
>> they are hidden... the only fault in it as it is is that is crushes
>> sim resources and makes the general experience for the regions users
>> less than acceptable.
>>
>> my post was ment only to see if any linden or other developer was
>> intrested in helping cure the grid of these lag monsters.
>>
>> regards,
>> mal
>>
>>    ----- Original Message -----
>>    *From:* Kelly <mailto:kelly at lindenlab.com>
>>    *To:* Henri Beauchamp <mailto:sldev at free.fr>
>>    *Cc:* sldev at lists.secondlife.com <mailto:sldev at lists.secondlife.com 
>> >
>>    *Sent:* Monday, May 18, 2009 4:03 PM
>>    *Subject:* Re: [sldev] A thought on how to lower resources used by
>>    sensors
>>
>>    Henri Beauchamp wrote:
>>>    On Mon, 18 May 2009 13:16:29 +0200, Ambrosia wrote:
>>>
>>>
>>>>    On Mon, May 18, 2009 at 04:16, Nexii Malthus <nexiim at googlemail.com 
>>>> > wrote:
>>>>
>>>>>    I think rather than keeping the problem on the LSL side, it  
>>>>> would be more
>>>>>    suitable for being a viewer-side feature entirely that  
>>>>> replaced the
>>>>>    necessity of such silly HUDs and Gadgets. Finally removing  
>>>>> the source of the
>>>>>    problem alltogether, and virally so due to the big advantages  
>>>>> of being able
>>>>>    to be tied into the user interface.
>>>>>
>>>>>    - Nexii Malthus
>>>>>
>>>>    Which would not remove, at all, the problem of having to use  
>>>> sensors
>>>>    in an object in order for the object to detect who is nearby.  
>>>> It would
>>>>    be much more feasable to have a function return a list of  
>>>> avatar keys
>>>>    in the sim, and to call this function once whenever the agent  
>>>> count in
>>>>    the region changes.
>>>>
>>>
>>>    I think the best solution would be to allow sim-wide sensors
>>>    (llRegionSensor() ?)... This would remove the need for probes,  
>>> just like
>>>    llRegionSay() suppressed the need for llShout() relays in the  
>>> sims...
>>>
>>>    Henri.
>>>
>>    Sensor events are kind of weird.  They were designed specifically
>>    to give a real-world quality to gathered data.  If you have a
>>    sensor in the real world, the data it can pick up is generally
>>    directly related to where the object is and some range that it can
>>    sense information, and probably a direction.  There are definitely
>>    uses for this kind of information gathering in Second Life, "what
>>    objects are near me" and the various permutations thereof are
>>    definitely useful.
>>
>>    However they do have problems.  They are limited in what data they
>>    collect since they scan and store a snapshot of the data with the
>>    script - we can't really extend how many results or what data is
>>    gathered just because of the memory footprint involved.  The
>>    legacy script formats add additional difficulties that are less
>>    insurmountable but still trouble.  By their nature they are at
>>    least a little more load intensive than just accessing data the
>>    region already has in memory would be.  If you extrapolate from
>>    this just a little bit you can think about why region wide sensors
>>    wouldn't be that great.  We could still only return the 16 results
>>    and the existing types of data.
>>
>>    As has already been suggested in this thread I believe, we are
>>    much more likely to investigate non-sensor calls that directly
>>    access information the region already has in memory and don't try
>>    to mimic real world behaviors or the sensor pattern.
>>    llGetAgentCount() or llGetAgentsInParcel for example, that could
>>    return data directly.  I'm not saying we are working on these or
>>    even have plans for them, and there may be privacy issues that
>>    come into play for some of these types of calls.  I'm just saying
>>    that I think this is more likely to be the direction we head than
>>    extending or mimicking the llSensor pattern.
>>
>>     - Kelly
>>
>>     
>> ------------------------------------------------------------------------
>>    _______________________________________________
>>    Policies and (un)subscribe information available here:
>>    http://wiki.secondlife.com/wiki/SLDev
>>    Please read the policies before posting to keep unmoderated
>>    posting privileges
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting  
>> privileges
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting  
> privileges