[sldev] Script/Parcel/Memory Limits

Dahlia Trimble dahliatrimble at gmail.com
Wed Dec 16 20:18:18 PST 2009


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 <kelly at lindenlab.com> wrote:

>
>
> On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble <dahliatrimble at gmail.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091216/12fc7c1a/attachment.htm 


More information about the SLDev mailing list