Sorry Malachi, I think my spam filter is picking up your emails. :(
Anyway. I put that in there because any time we add new data collection
LSL calls privacy issues are something we have to think about. Maybe
you are right and there are none. Maybe we need to make sure these
calls only work if the script/object owner are on the parcel or the
parcel owner or some other criteria. I don't mean to enter that debate
here or to derail the initial conversation. I only mean that it is one
factor that has to be taken into consideration for this kind of call.
Sorry if mentioning it caused confusion.
The point is that going forward we will probably prefer methods that
just return data readily available from the region process rather than
calls that use llSensor or follow that pattern.
- Kelly
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
[email protected] 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:[email protected]>
*To:* Henri Beauchamp <mailto:[email protected]>
*Cc:* [email protected] <mailto:[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
_______________________________________________
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
