Re: [ogpx] Synchronization of gestures (was: Limits to interoperability of scripted objects)

[Nexii Malthus <[e-mail]>]

Okay, this is a fancy idea. But I think it seems to miss the entire point.

Basically what you are doing is attempting to cope with a faulty
system by implementing a hack on top of it. It isn't the way to go.

What you really need, is a more sophisticated animation system, one
that can handle better constraints, such as having a hand point at
prim UUID and even be able touch the surface of a prim in specific
controlled ways or in our case, being able to handle hugging arms
physically around a specific avatars body shape constrained  around to
hold tight.

There really is no reason to throw on top an entire synchronization
process on a system broken by design. And finally, ideally the script
would have the ability to preload the animation long before it got
executed in the first place, or preloaded just as the dialogs asking
for a hug to the person was sent.

- Nexii

On Wed, Nov 11, 2009 at 10:12 AM, Carlo Wood <[e-mail]> wrote:
> My previous post was a brainstorm, and I made a view mistakes in it.
> Let me try again.
>
> Looking just at animations and sounds, we can observe that it
> is impossible to deny playing a sound, and it is only possible
> to deny playing an animation for ones own avatar. Nevertheless,
> more in general one could think of world-manipulations, visible
> to others, and requested by others, that require permissions,
> the whole set of permissions can than be seen as a bit mask,
> but is at the moment of no further interest. Hence, lets
> concentrate for the sake of simplicity on animations.
>
> The simplest case would be a scene with three avatars (agents,
> whatever) A, B and C, where A proposes to animate B (to B)
> and C is just an observer.
>
> In the ideal situation without much lag, the protocol should
> look something like this (were B/xyz and C could be a list of
> agents/animations):
>
> [A preloads animations (etc)]
> A --request animation xyz of B--> simulator
> simulator --A requests animation xyz --> B
> [B starts preloading animations (etc)]
> simulator --A requests animation xyz of B --> C
> [C starts preloading animations (etc)]
> B --OK--> simulator
> simulator --Ready?--> A,B,C
> A --Ready--> simulator
> B --Ready--> simulator
> C --Ready--> simulator
> simulator --GO--> A,B,C
> [all viewers play the animations for all avatars]
>
>
> HOWEVER...
>
> It seems better to seperate this "voting / handshaking" from whatever
> is the action. If we assume an API, as morgaine proposed, that gives
> us complete control over the world, then a logical step would be
> to have a viewer-local scripting language that manipulates this
> world (albeit locally, in this case). A given script provided by
> another agent would fail if it would attempt to do something for
> which it had no permission; so it should be known what permissions
> a script needs before running it.
>
> The above then can be done by replacing "animation(s)" with "running
> a script". In the above case, the script would only need the
> permission "animate your avatar for animation xyz".
>
> The above then turns into:
>
> [A preloads animation (etc)]
> A         --requests to run script on B,
>            needing permission "animate B with xyz"-->  simulator
> simulator --A requests to run script,
>            needing permissions "animate B with xyz"--> B
> [B starts preloading animation (etc)]
> simulator --preload animation xyz-->                    C
> [C starts preloading animation (etc)]
> B         --OK-->                                       simulator
> simulator --script-->                                   B
> simulator --Ready?-->                                   A,B,C
> A         --Ready-->                                    simulator
> B         --Ready-->                                    simulator
> C         --Ready-->                                    simulator
> simulator --GO-->                                       A,B,C
> [all viewers run the script]
>
>
> Now, although EVERYTHING can be implemented from here on with
> "running client-side scripts" (possibly predefined, permanently
> cached scripts), I'd personally add one more step to seperate
> the 'voting' mechanism from 'running a script'.
>
> I think the most general support would be to first define
> that some handle means "play script needing those permissions",
> and then run the voting protocol, including it's timeout
> and permission-denied policies, using that handle; in that
> case the voting would look like:
>
>
> * Define what we vote on, and what are the timeout/permission-denied
>  policies, and obtain voting-handle
>
> * Handle preloading (tell everyone that they might need these assets).
>
> * Ask for permissions
> * Wait for permissions and/or timeouts
>
> * Inform viewers of result about voting-handle
>
> * Wait for preload-ready signals
> * Inform viewers that everyone is ready and we have a 'go'.
>
> * All viewers do as agreed, resulting a mutally synchronized
>  experience.
>
> On Tue, Nov 10, 2009 at 09:41:55PM +0100, Carlo Wood wrote:
>> * Viewer A (or object) initiates Multi-gesture Request
>>   to N (other) viewers, this involves a list of the
>>   animations (UUID) to play for each of the avatars
>>   involved, and sounds to play etc, and the starting
>>   position in the world of each avatar.
>> * Each viewer reacts with: Ok, will try; or Nope, I won't.
>>   If any viewer denies the request (or times out?)
>>   then the server informs all viewers that the multi-
>>   animation was aborted (and why). [ An optional flag
>>   could be to continue anyway, but without the avatar(s)
>>   that don't want to. ]
>> * Once all avatars that want to play the multi-animation
>>   are known, the server sends them a message: "We have a go!"
>> * All viewers that have all the needed information to
>>   continue (downloaded and cached the animations, sounds etc)
>>   send a message to the server: "ready!"
>> * As soon as all viewers are ready (optionally, a parameter
>>   of the original request includes a timeout after which
>>   the delayed avatar is considered to have said "no"),
>>   the server informs all viewers to start playing the
>>   multi-gesture.
>>
>> And YAY! finally a completely synchronized couple (and
>> multi) animation, even synced with sound!
>>
>> Options in case of delays (timeouts) should be:
>> - Play as soon data available locally,
>> - Wait till at least N, or at least those, avatars
>>   are ready.
>> - Abort completely if any can't play in time.
>> - If someone is delayed and the rest already plays
>>   the animation, then the viewer can decide to abort
>>   or play the animations locally anyway, as soon as
>>   they become avaiable, etc etc... All those possibilities
>>   are mere bits in already existing messages, so why not.
>>
>> As a side effect of this it should be possible to
>> play a gesture involving animation and sound by ONE
>> avatar (as are the gestures in SL now) but *synchronized*:
>> everyone sees it at the same time, and the animations ARE
>> synced with the sound once the start to play (unlike now,
>> where the animation is played and 30 seconds later you
>> hear the sound).
>
> --
> Carlo Wood <[e-mail]>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>