Synchronized Pose Balls

When writing animations that are meant to be synchronized, how is the ball script done so that they are synchronized? I saw one set of synch ball sets, but they were no copy, no mod, no nothing..

Essensual gives away a set animators can use.

I keep hearing that, but when I get them from SLExchange, they come No Mod, No Copy, No Transfer or whatever. I can't see the scripting because it is locked. So for what it is worth, I can't really do much with those. Maybe there is a differnt source can get them from that gives me full perms.

It seems that MLP synchronizes their animations, if no one can redirect me to anything else I guess I can examine that code I guess..

The sample animations are maybe no-copy or no-transfer, but the balls themselves are full-perms, and the scripts are copy/transfer. What's displayed next to the object's name in inventory is the most restricted perms of the object and all it's contents, which may not be the same on everything. So like even if the balls can be copied, if something in the contents is no-copy then inventory shows the entire object as no-copy.

It's not really difficult to script this though; I was thinking of writing my own scripts so the objects don't show as no-mod because of the scripts. It's pretty much standard poseballs linked together, with link messages so that they know when the other has been sat on.

Syncíng scripts...

Usually, this is done by exchanging messages. The simplest example is that when script 1 starts, it sends a message to script 2 saying 'now'.

A more precise protocol might be that 1 sends a 'get ready', waits for a 'ok, I am', and then sends a 'now'.

Another approach is that script 1 looks at the current time, adds say 5 seconds, and then sends a 'start at time X' message. This gives the other script time to receive the message, experience some lag, and then wait a few seconds before starting.

The general problem of synchronizing multiple independant processes is huge and fascinating. have fun...

Lee that is what I was thinking. So the question is in how the exchange of messages takes place. Can the balls inherently talk to each other because they are linked, can they reference each other by name? Or is it more that you just send out the message on a channel and both balls listen on the channel?

I can and probably will figure this out by trial and error, but it is always nice to know what has already been done.

yes

Thanks, I will look at that wiki page it seems to have some of the answers.

I wrote this today. Maybe it will help...

integer ch = -5191928;
integer repeat = 2;

// send a message to all the others on the channel
sending()
{
    vector color = <llFrand(1), llFrand(1), llFrand(1)>;
    integer r = repeat;
    
// if you want to be sure, send the message more than once.
    while( r > 0 ) {
        llShout(ch, (string) color );
        --r;
    }

    acting( color );
}

// Do whatever the action is.  
acting( vector c )
{
    llSetColor( c, ALL_SIDES );
}


default
{
    state_entry()
    {
        //llSay(0, "Hello, Avatar!");
        ch = (integer) llGetObjectDesc();
        llListen( ch, "", "", "" );
    }
    
    listen(integer c, string n, key k, string m)
    {
        acting( (vector) m );
    }
    
    timer()
    {
        //action();
    }

    touch_start(integer total_number)
    {
        llSay(0, "Sending...");
        sending();
    }
}

To make two balls synchronized, do the animations have to be uploaded in a special way or something? Because it works with some and it doesn't work with others,.. I don't know why.

Nothing special about hte animations themselves.

Synchronizing it a very tricky issue. The packets sent from the server to the client can one or the other be delayed. The animations sent from the server to the client can one or the other be delayed.

The cleverest sync scripts periodically refresh. That is, if your animations are 20 seconds long, re-sync every 20 seconds or so.

Also note that the animations can look perfectly sync'ed to you, but be totally whacked to others, and vice versa.

The two animations do have to be designed to be synced together. They should have the same exact length, the same frame rate, and be uploaded with the same start and end points.

For a linked set, the best way is to simply send a linked message. Have all scripts listen for this message (including the one that sent it), and on receipt, do the sync.

However, for a re-sync to work, you have to change the animation, wait a bit, and then change it back. Many danceballs use the 'stand' animation, which is good because it's built-in and doesn't contribute to lag.

Synchronization when starting an anim for the first time isn't possible for couples poseballs, because each anim has to be downloaded to the client, and the client starts the anim on the respectiv avatar as soon as it gets it -- so you're looking at two avatars (running different anims) and the anims start at different times unless you're in a very low-lag situation.

There's a fix for this with sounds, allowing you to push a sound clip to a client before playing it -- but unfortunately, no similar one for animations. So, we live with things sometimes being out-of-kilter until the first resync.

Lee's method using llSay should only be used if the objects aren't linked, because chat occasionally has serious lag (which no doubt you've noticed). So can scripts and linked messages, but that type of lag applies for either solution, whereas the chat lag applies only to llSay et. al. Another complication using llSay is that an object won't hear anything it says, whereas a script hears the LMs it sends.