On Fri, 13 Apr 2012 12:16:03 -0400, 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?
Again, the viewer side AOs are in fact mimicking exactly what scripted
AOs (and most specifically Francis Chung's "Franimation Overrider") do.
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.
As a result of trying to mitigate this issue, AOs all too often tax the
sim servers by using a very high rate timer that checks the currently
playing anim every frame (llSetTimerEvent(0.02); or less) so to detect
the start of the default animation to be overridden and to start the
corresponding overiding animation as fast as possible.
While it is possible to script relatively "low lag" AOs, especially by
using the control() event and detecting key presses that cause the
walk/turn/run/fly anim changes and then using a lower frequency timer
to catch the rest of the animation changes (e.g. when "falling"), they
are still more laggy (seen from the server side) than a viewer-side AO.
These flaws are due to the lack of a change() event for animation
changes (time to implement CHANGED_ANIMATION, perhaps ?...) in LSL: if
such an event existed, then the scripted AOs could become just as fast
as viewer-side AOs if not faster (see below about the "ping" problem)
and would not cause any measurable lag (since the high frequency
timer() would then become useless and would be removed).
Viewer side AOs simply watch the animation changes as sent by the
sim server and, when a default animation (ANIM_AGENT_*) is triggered,
the viewer watches its AO table to see if a custom animation should
replace the default one, and in the affirmative, sends stop default
anim/start overriding anim orders to the server. Note that while there
is no lag involved doing so from the server side, the user may still
experience a delay (assimilated to "lag" from their point of view)
if their ping with the sim server is high (a 250ms ping will then
typically result in a half second delay before the default anim gets
overridden as seen by the user in their viewer, thus not providing a
better experience than a scripted AO).
As mentionned in other messages in this thread, there is also the
problem that the viewer side AOs are currently poorly implemented and
lack region change/TP checks, etc, causing the animation overriding
to fail in some cases, when scripted AOs are not affected (not hard
to fix however... Just a matter or re-coding them properly).
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).
The problem with viewer-side AOs is that since a viewer can't listen
to a private channel, it can't intercept the "booton"/"bootoff"
commands sent by Lockmeister-compatible devices. Of course, you could
use a "bridge" (an object with a script that listens to the
Lockmeister channel and relays the boot* commands to the viewer via
a special llOwnerSay(), à la Restrained Love), but it's IMHO quite
dirty.
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.
I think the above explanation gives a good idea of the current state
of affair, and here is a proposal of mine for a properly coded AO
protocol:
The idea is that we should not be forced to use the default anims
at all... For each avatar in a sim, the server should instead maintain
a table (that would be filled up with the default anims on avatar
arrival), in which each row would contain the symbolic name of the
anim state (e.g. ANIM_AGENT_SIT), the name as reported by scripts for
this anim (in our example: "sit") and the UUID of the anim to play
(the default UUID or any UUID sent by the viewer).
To change the default anim, the viewer would then send the overriding
anim UUID (after duly checking that there is an animation in the
user's inventory that bears that animation UUID) via a capability to
the sim server.
Then, each time your avatar would play the corresponding anim state,
the server would send the associated UUID to all viewers and there
would be 0 delay for the overriding and 0 conflicts with "seats"
(since these would still stop the anim with the usual
llStopAnimation("sit"), the server then using its table to stop the
corresponding anim. The seat then could play their own anim, not even
needing to care about sending booton/bootoff commands).
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.
Henri.
_______________________________________________
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
