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 <ca...@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 _______________________________________________ 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
