[opensource-dev] Formal Animation Set Replacer

glen gcanaday at gmail.com
Sun Nov 4 08:15:08 PST 2012


I've written and used my own LSL AOs for years. I also don't agree with
Carlo's "majorly fail" assessment since he didn't really give a reason,
but relying on control inputs rather than a moderately quick timer (à la
Argent) also doesn't work.

Control events aren't reliable enough for this as an AO that does rely
on them, as the first version of mine did, only *usually* picks up on
button presses and releases. It's likely Frances Chung and Ziggy Puff
ran into the same problem, which is why they also used timers. When you
use an arrow key to walk and then release it to stand, the control()
event does not always fire. This causes your avatar to stop moving as
you'd expect but the AO doesn't always get the opportunity to stop the
walking animation and resume a standing one. This is only one example
but it's the most noticeable one. I do not know the actual cause or
location of the control() snafu, be it the script VM, client-server
communications lag, dropped packets, or whatever, or I'd file a jira for
it in a heartbeat. It would make my script so much simpler.

I've found that a timer of about 0.25 seconds gives a good balance
between seamless animation pickups and moderate to low server load,
which only means that this is the slowest timer I could reliably get
away with!

Client-based AOs often don't offer the same flexibility as LSL-based
ones do, which is why after trying the one in Firestorm (a pretty good
client AO by most accounts and used by probably thousands of people) I
ended up going back to mine.

--GC

On Sun, 2012-11-04 at 05:57 -0600, Argent Stonecutter wrote:
> On 2012-11-03, at 22:39, Carlo Wood <carlo at alinoe.com> wrote:
> > LSL AO's have always failed majorly.
> 
> 
> I have used and written LSL AOs for 7 years now, and I haven't seen this "majorly" failing. Certainly nothing compared to the shortcomings of client-side AOs. Being able to load AOs from a wearable is kind of a key feature, in fact not having that is a deal-breaker, and none of them even attempt to implement it.
> 
> Server-side AOs that can be loaded with wearables would be great, but they're out of scope for this list.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges




More information about the opensource-dev mailing list