[sldev] Script Synchronization (Was [SCULPTIES] New Scripting Functions)

[Andre Roche]

Sounds to me like something that can already be done, just not as
reliably as it could be done.

Have a "Master" object that, on a timer, uses llSay to send a message.
 When that message is recieved, the listen event fires off oneshot
events.  Many things like llTargetOmega could theoretically be synced
this way as well.  It'd be nice if client updates were a little more
reliable.

Do we need a new setting/event based on the same concept as audio master/slave?

On 9/29/07, Argent Stonecutter <secret.argent at gmail.com> wrote:
> On 29-Sep-2007, at 11:51, Lawson English wrote:
> > What I proposed to Qarl and Zero was along the lines of a texture
> > animation where instead of the texture map being used by one
> > sculpty, it was used by n sculpties, n beng greater than or equal
> > to 1.
>
> [...]
>
> OK, first of all, you *don't need to do anything special* to use
> different portions of the same map for multiple sculpties if you just
> make the mechanism a parallel to the texture animation one. You get
> that for free with the texture animation start and length parameters.
>
> Second, texture animations on prims start when the parameters are
> downloaded to the client. Sculpt texture animations would be the same
> way. So if you set them concurrently they would run concurrently, and
> in general tiled prims with lined up texture animations just work...
> and when they don't it's because you've got unlinked prims that
> didn't rez together.
>
> So sculpties in a link set are going to generally start animating at
> the same time and in sync with each other and texture animations.
>
> HOWEVER, it would be nice if there was a mechanism to sync periodic
> client-side operations.
>
> Well, there is. It's the audio sync mechanism. I'm not suggesting
> that this be used to sync to audio, I'm suggesting using the existing
> audio sync mechanism to sync periodic actions in prims. ALL periodic
> actions. Currently it only works for audio.
>
> That is, if there is an audio master present, then prims with the
> "audio sync" parameter set would wait, at the end of the cycle (of
> texture animation, sculpt animation, llTargetOmega, periodic particle
> generator), until the next time the audio sync loop started. So after
> the first loop, they would start in sync.
>
> The audio master does not need to be audible, it could be a silence
> loop. But there's already a mechanism in the client to sync looped
> sounds to a master, there's no reason that couldn't be extended.
>
> It would also be really useful to be able to generate the master sync
> without a sound file, to make it linkset-local or avatar-local, and
> so on.
>
> Finally, syncing might not need LL to do anything. It might be enough
> to have the client check if there are multiple looped events in a
> linkset *with the same periods* and sync them... and WE can implement
> and test this part using texture animation.
>
> 1. The first part of what you want comes for free with texture
> animations, and it's something that Linden Labs needs to do.
> 2. The second part of what you want needs to be a general mechanism
> that handles things other than sculpties.
> 3. Apart from designating the sync master and slave hierarchy, this
> is all client stuff that YOU could implement, and for a single
> linkset you could test it with sculpt textures now.
> 4. If that works, all LL needs to do is to create a sculpty version
> of texture animations.
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>