Client-side AOs don't offer the flexibility that scripted AOs do. Scripted AOs can be made specific to any given use-case.
Client-side *COULD* be, but that would imply offering an extremely configurable interface to rival the gamut of options available to scripters. For example: *listen for this input on this/these channel(s), then turn off/on or perform another action in response. *every 6 seconds, play this fidgeting animation. *every 30 seconds (the standard) switch stands. *allow random/sequential animation switches. *cycles these animations, but not this one. *know when I'm under water and play my swim anims when I move rather than my walks & runs & flies. *when I'm underwater, apply a vertical impulse of strength X to simulate partial buoyancy. *when I'm less than half my body height from the surface, attract me to the surface and play the treading water animation. *add a flight aid boost when I fly up or down so I go a little faster. *disable sit override when being animated by another object that I'm sitting on. *disallow certain animations to play, or cancel animations started while sitting on one object but not another. .. ad infinitum. Different communities will needs different sets of options that client-side AOs don't currently offer. No matter the effort put into the flexibility of the interface and functionality, there will always be holes, sometimes large, that will make it less fit for entire classes of people. Server-side, this would only be made worse owing to the need to keep this kind of load off the sim, which would mean an even further reduced feature set. Scripted AOs can be made to be *exact* fits for whatever the user wants or needs, and if well-written, can present a minimum of load to the server. More load than a client-side AO, to be sure, but good scripting is good scripting. Hope that answers. --GC On Fri, 2012-04-13 at 12:16 -0400, Oz Linden (Scott Lawrence) wrote: > On 2012-04-12 17:50 , glen wrote: > > On Thu, 2012-04-12 at 14:09 -0700, Ann Otoole wrote: > >> Thankfully the previously bad aos are not so bad now. If a client side > >> AO cannot perform what Oracul and/or Vista AOs do then it is a total > >> waste of time to bother with the client side code. In order to do > >> client side AOs requires AO expertise. Period. Don't even bother if > >> you don't have it. Because it will be a waste and people will still > >> use AOs. > > Agree. I'm one of the ones who's written a scripted AO. I tried the > > client-side AO in Firestorm and went back to my own because of the > > feature set. A server-side AO would like be even worse. > > > > Ok... so those are nice opinions to have, but you're not succeeding in > educating me... what is it that makes these better or worse? > > What do they do or not do that differentiates one from another? > > _______________________________________________ > 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
