Sure the delay is a factor, however there are also rather large delays when sending link messages through large link sets. I don't know how successful you would be at removing the delay, prim animation aficionados such as myself would quickly discover it and make nifty animated thingies which would radically increase network traffic with object update packets when all our friends gathered around the new animated thingie to watch. Perhaps an alternate rule may work instead: apply the 0.2 second rule to each item in the linkset that the script could address rather than the entire script? (or something to that effect).
Of course prim animators use many scripts to get around the 0.2 second delay now, so yeah, maybe just getting rid of it is a good idea :) On Wed, Dec 16, 2009 at 7:45 PM, Kelly Linden <[email protected]> wrote: > > > On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble > <[email protected]>wrote: > >> The master script can then modify these values and modify the child prims >> using the existing llSetLinkPrimitiveParams() function. >> > > At 0.2 seconds of script sleep per call you are currently at 1 second for > every 5 prims. 100 prims is 20 seconds and 200 is 40 seconds of pure sleep, > outside any time the script actually uses. While this isn't actually very > horrible for something that you would in theory only do rarely why push this > on your customers when it is simple to have a script in each prim and get > near-instant change? > > By adding a version of llSetLinkPrimitiveParams that does not have a delay > you will be able to get the same 'near instant' change with a single script, > and that is our goal. > > Additionally, llGetLinkPrimitiveParams doesn't yet exist and will remove > the need for even the initial round of self-deleting scripts in each prim. > > - Kelly >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
