Talk:1st necessity of SL

While I highly support the intent of this script, I don't think it will achieve its goals. Here are my problems with it:

1. The default time and radius of the sensor is not realistic in most cases, thus the lag caused is much higher than stated in practical use.

2. This is simply replacing a thousand running scripts, most of which are tiny... (what, a clock maybe?) with a thousand sensor repeats.

3. I can't speak for everyone, but I move my camera far more often than I move my avatar. This script would Destroy the creator's intentions in this case.

4. Even for those who don't cam so much, draw distance is rarely lower than the maximum sensor distance. In these cases, people will see a dead object come to life as they approach it. I've seen this used for good before, but it's not a good idea in general.

The one place I would consider using this script is to wrap a channel 0 listener script, and even then I'd want to check for performance differences.

I admire the strive for less lag. In my experience, that means staying away from sensors and listeners as much as possible. If I am wrong about this script (actually I hope I am ;) please explain better or give more proof and arguments. Keep up the good work though PLEASE, it's great to see the constant strive to reduce lag, I've met far too many coders who ignore it.

Sleeves Rhode 09:50, 17 October 2009 (UTC)