[sldev] Re: [SCULPTIES] New Scripting Functions

[Lawson English]

Argent Stonecutter 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.
>

Great, jira it and every sculpty user would  vote for it, I'm sure 
(well, those that ever vote, which isn't many).