On 4/13/2012 10:16 AM, 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? For the most part, the only advantages of client-side ao are those that bypass lsl limitations such as working in areas where Run Scripts is disabled and being able to create very large animation sets with almost zero load time to switch (after their initial creation of course.) For example, I have an AO set with 115 stands which cycle, 15 walks, 48 sits, 22 ground sits. This configuration is far greater than what can be configured in a scripted AO because of the lsl's memory limitation. This is probably not a typical use case, but it is an advantage.
An advantage to scripted AO's as has already been stated is that bundling the config, AO, and animations into one object that can be worn and added to specific Outfits is simpiler and conserves Inventory count. AFAIK, any client-side AO relies on animations being unpacked and in the user's inventory, sometimes creating additional object links. AFAIK, the only client-side AO implientation that doesn't do that relied on an external xml config saved to hard disk and was abused by users plugging UUID's of animations in which they did not own. It was subsequently replaced with another implementation. To my knowledge all client-side ao's also suffer from region crossing bugs which, for whatever reason, cause them to misinterpret the avatar's state or don't release the animation they were currently in while crossing sims (being stuck in a falling flight state being the most common that I've encountered.) Scripted ao's, of course, don't suffer this. Scripted AO's can listen for commands from other objects in the region more easily and interact better when they've been scripted to do so. There are patches floating around that add compatibility with lockmeister and whatnot, but there is no standard viewer api for such cases. kind regards, -Cinder _______________________________________________ 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
