[sldev] New Scripting Functions

[Lawson English]

Argent Stonecutter wrote:
> On 27-Sep-2007, at 22:20, Lawson English wrote:
>> I don't recall qarl saying that these were a given.
>
> Didn't say it was "a given", I said it was missing. It may be that 
> Qarl will implement something else instead, but I sure hope that 
> reason prevails and the basics get taken care of first.
>
>> And *I* want something that animates n sculpties, not just one.
>
> Synchronizing events in multiple prims for everything else in SL is 
> done through link messages and through the audio sync support, or by 
> setting the parameters to multiple prims in a link set. Extending 
> llSetLinkParams to allow more precise control of the links (which is 
> in the list Iridium provided) along with the sculpt animation 
> parameter should get you what you need. Keying sculpt and texture 
> animations to audio sync might be better, and would solve problems for 
> texture animations as well, but that doesn't seem to be in the pipe.
>
> So... getting something that animates *one* sculpty may give you what 
> you need, and if not the link parameters proposal being considered 
> would do the job.
>

I'm not sure if we're on the same page here or not. (pun intended)

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.

Conceptually, a texture used in texture animation for multiple sculpties 
would be a single rectangle of m x n tiles, where there are m frames of 
animation texture being used by n sculpties. A single sculpt-animate 
call, however the parameters are defined, caches that texture on the 
client and the client starts animating all scultpies in-synch with each 
other by bumping what texture is used to animate each of them down by m 
tiles with each frame-tick, however that has been defined. Having this 
tied to audio would certainly be very nice, but the main issue is to 
ensure that all the sculpties are literally on the same page, as far as 
what texture they use.

Until that is the case, there is no possible way to coordinate sculpty 
animation since one could never guarantee that all the textrues for a 
given frame of animation were available for all sculpties.

What I proposed that Zero shot down completely, was the ability to 
create such a tile-set on-the-fly, to allow for maximum flexability in 
animation, due to issues with the LSL equivalent of dangling references. 
However, there's no reason why a custom package of tiles can't be 
specified in the animation call as long as that assembly is passed as a 
list in the animation function call itself, rather than as a 
texture-creation call whose result passed to the animation call (the 
dangling reference issue Zero vetoed).

The main issue is always going to be to make sure that all the textures 
used in the animation are available client-side when they are needed, so 
you need a single texture to be used by all sculpties passed to the 
client for caching. Details of synchronization are secondary. I would 
love to see something synched to audio, but even without that, we need a 
way to hook multiple sculpties to the same single texture, or we will 
never see reliable multiple sculpty animation.