[opensource-dev] Tutorial needed on TPV viewer-side AOs
cinder at cinderblocks.biz
Fri Apr 13 09:45:50 PDT 2012
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.
More information about the opensource-dev