[sldev] Re: [SCULPTIES] New Scripting Functions
Argent Stonecutter
secret.argent at gmail.com
Sat Sep 29 10:34:59 PDT 2007
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.
More information about the SLDev
mailing list