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

[Kadah]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/13/2012 9:16 AM, Oz Linden (Scott Lawrence) wrote:
> 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?

Gonna try to list pro/cons-ish things about both that I'm aware of.

Scripted AO pros:
* Work on any viewer
* Can natively affect avatar's movements (eg. move faster, fly, swim)
* Included as part of an outfit without needed further required actions
* "Buy & wear" work flow
* Latency-poof for the most part
* Unique behaviors through additional scripting

Scripted AO cons:
* Memory foot print of some AO huds are ridiculously high
* Memory and notecard limitations restrict animation lists
* Unable to detect when animations are being overridden by another
source (eg. pose balls)
* Issues related to no-script parcels and script-disabled regions
* Unable to react to user actions not exposed in LSL (I don't have an
examples of this offhand that client AOs have implemented)
* Subject to simulator performance issues (eg. High TD or script time
will highly affect them, but movement  in general is usually an issue
during these events anyway)
* Some complicated AOs eat up a none trivial amount of script
time/CPU, even compact AOs add up to a lot when a region is near capacity
* Updating AO core less than ideal (typically requires repacking all
animations and notecards in to new copy of the HUD. Given the normal
volume of items involved with these, just viewing the objects
inventory is non trivial let alone transferring. This process is not
"noob friendly". Could be offset with AO hud that supports and
"updater", but these also have their caveats and further add to script
load.)


Clientside AO pros:
* Can detect when animations are being overridden by another source
(eg. pose balls)
* No script memory impact (unless being fictionally expanded by a worn
scripted object)
* Ditto for script time impact
* Nearly unlimited animation list lengths
* Not subject to no-script land and script-disabled regions
* Updating AO system considerably easier, only requires updating the
viewer

Clientside AO cons:
* Not supported by every viewer and different viewers' AOs might not
function identically (Though most of them use FS one, but not always
the same version of it)
* Currently cannot be part of an outfit for easy switching (AFAIK.
Could be added with some cleverness.)
* Subject to simulator-viewer latency
* Less than ideal setup flow (minimally requires unpacking to folder
in inventory)
* Requires viewer update to add features or fix bugs (not sure if
that's necessarily a bad thing)

Disclaimer: I'm not too familiar with FS's clientside AO.

[One thing that was brought up a few times by others is object-to-AO
communication support by scripted AOs, and that it could be added to
clientside AOs with a relay. But there is a problem with this, not
many AOs actually have this feature, nor do many in-world objects make
use of it, and the ones that do, use different or unique standards. I
wouldn't count this as a major feature of any AO, but might have the
possibility to be one if there was a one widely adopted standard.]

I had planned for this to be a short list, I guess that didn't happen.
The major pros and cons of both are just essentially the technical
limitations of doing something in either LSL or on the viewer's end.
Ideally I think getting SCR-10 implemented would help scripted AOs be
more robust, and adding some sort of minimal support for serverside
animation override to help mitigate the latency would make clientside
AOs better suited for the average User McResident.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPiIJMAAoJEIdLfPRu7qE2U40H/jcOCNttE0Vj6anUBe8qU3hy
1KMckgM471YMU9WNoCyE8LWoAeA3Exsr1ln0lHzx7Dr4xbGBzLIr6zqYl/qt3RNq
tYYnOjb5osl5KAo6kJn3iIyKNi+FYW9MOBrsnCObYyLYpWVy9KvxtUSHYFsw8IGL
B41f6QlRBmAhU4Zv6G4LohPyiGvC3T5sPUrpt2cWqIsOeLUW/WFReKCQEboz/EEW
uFgi5bFr6BkkZUjlBrOBt59uhg84wh55mOFb3+B6qA/G4zVfBzuVoUYJ/j1DFfnC
l7+h1xdpPu1ve7u+DZo3ZRT8PkANxGTYigRC4kPCi2Rm9W4U2Wbj7plwIFFDylk=
=tbGR
-----END PGP SIGNATURE-----