[opensource-dev] Tutorial needed on TPV viewer-side AOs

[Cinder Roxley]

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