-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 4/13/2012 1:10 PM, Henri Beauchamp wrote:
> Again, the viewer side AOs are in fact mimicking exactly what
> scripted AOs (and most specifically Francis Chung's "Franimation
> Overrider") do.
I believe FS's was designed to mimic the ZHAO II hud, it even uses its
config notecards. "Franimation Overrider" is a new one to me.
> The scripted AOs got two main flaws (which are in fact the result
> of the same lack in the scripted event support): they are often too
> slow to change the overriding animation in time to avoid seeing
> the overridden animation playing for a second or so before the
> overriding anim is started.
I've only seen that behavior with clientside AOs. I figured it was due
to the latency of the viewer having to respond to a simulator event
then send an override.
> Another, much worst issue with viewer side AOs, is that, like I
> explained in my previous message in this thread, they lack a way
> to be disabled automatically by scripts. Let me explain this issue
> more in details: while AOs are great, they can be a nuisance when
> interacting with certain scripted objects which want to play their
> own animation on your avatar. This is especially the case for
> "seats" (in the largest extent of the term: i.e. any object you
> "sit" your avatar onto) that usually provide their own sit anim;
> these objects stop the default sit anim (llStopAnimation("sit"))
> then start their own anim. If your AO is configured to override
> the default sit anim, then the overriding anim will also override
> the scripted seat object's anim. In order to solve this problem,
> the Lockmeister protocol
> (https://wiki.secondlife.com/wiki/LSL_Protocol/LockMeister_System#Special_Commands)
>
>
was extended with "bootoff" and "booton" commands ("boot", because
> the first AOs were in fact used in scripted shoes/boots) allowing
> to (respectively) turn off and turn back on the compatible AOs
> automatically. The seat then just has to send a "bootoff" commmand
> when your avatar sits down on it, then a "booton" command when the
> avatar stands up, and your AO gets automatically turned off and
> back on so that the seat's anim is not overridden.
>
> Note that there are other cases than just seats (for example when
> wearing two AOs or, for BDSM folks, when scripted cuffs are used
> and must be able to override an AO in some cases and especially
> when the avatar is fully chained/bound).
Unlike LSL, the viewer would be able to tell when something else is
trying to animate the avatar. I don't know if the FS AO handles this
(I don't actually use the viewer, and I prefer the use flow of an
attachable AO), but it is a possibility where it is not for a scripted
one.
> Also, not all seats/scripted-devices-with-built-in-anims use
> Lockmeister and this results in having to manually disable the AO
> in some cases.
Most don't.
> There is however a caveat to this apparently ideal solution: anim
> states are currently hard-coded with the default anim UUIDs in the
> viewers and a few code paths in the viewers check these to decide
> whether to take some actions (this is true for AGENT_ANIM_WALK,
> for example: see in llvoavatar.cpp): this could cause a few
> glitches and would have to be checked/tested. A solution for these
> few hard-coded code paths/anim states would perhaps be for the
> server to send (play) both the default anim and the overriding anim
> in a row (and also to stop both in reaction to a
> llStopAnimation("walk")): as long as the overriding anim is played
> last and got the same or a higher anim priority, this would still
> work.
What about having the option to just not sending those play messages
for the default anims in the first place?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPiLEhAAoJEIdLfPRu7qE2eCAIANIsQvZKRkBJV5yEnrXfHdcw
CZJ7qiTiaMaCe9Njn1K6ecyKaWhvRpkvQhCiaL+gb4V6qCoUmDATNTEclF5asIR7
LAg2sKkDaSMGlUwUAaKp9YsMUAaAp+D031nmu0mTVqOY9OPE27UmDgdnz08YW70a
ZxwnYMcExKFenFa6OQWZoNdetVsmPxwbGH5817dyVS1SPf5YXKLVXyji3zND1yJq
yrcxaWOSWvbVAiSsaq3+gXYQdtfd6iASRnhJln2XzMzeQyocHs7xNfT5jwE85URm
T2AkIlwRVdi7xKQV0tyiXivs1eWY0V2Ybs1ElY3m9tkdKo/+FvToUZxTQqrcFjE=
=JLaH
-----END PGP SIGNATURE-----
_______________________________________________
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
