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

[Zi Ree]

Am Freitag, 13. April 2012, 19:19:45 schrieb glen:

> *listen for this input on this/these channel(s), then turn off/on or
> perform another action in response.

That's something that needs an external script to forward channel talk to 
llOwnerSay talk.

> *every 6 seconds, play this fidgeting animation.
> *every 30 seconds (the standard) switch stands.

So two timers instead on just one? Our Viewer side AO supports at least the 
animation switch on a defined cycle time.

> *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.

Yep, we do that.

> *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.

These need external scripting support.

> *disable sit override when being animated by another object that I'm
> sitting on.

Yep, we have that.

> *disallow certain animations to play, or cancel animations started while
> sitting on one object but not another.

That would need a list of objects and animations ... could get quite large, 
but entirely possible.

> 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.

Depends. I am sure most of these gaps can be filled by small supporting 
scripts as soon as a standard interface for the AO is in place.

> 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.

Ideally, the AO would be "loaded" only once. After that the viewer does all 
the work, as it does now. Only the setup should be saved in inventory as a 
wearable AO inventory item, for example.

> 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.

I agree completely with this.

Zi