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
To: Henri Beauchamp
Cc: [email protected]
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 <[email protected]> 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
