In fact. I think this is an example where Script Limits will break content.
Imagine all the regions out there that use Object Bonus to pile all there
stuff into a few small parcels. These regions will be destroyed even though
it is legitimate use!
On Thu, Dec 17, 2009 at 2:54 AM, Peter Leonard/Dan
Just look at region Object Bonus. This is an example where a dynamic system
is already in use and works.
Object bonus allows EMs and the EO to allocate empty buffer parcels in order
to give other parcels more prims.
With object bonus on there is the posibility to rez more prims then the sim
allow
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
I wrote some scripts for a friend which let her sell a single object
with multiple color options on subsets of prims, instead of creating a
different object for each color permutation. I set it up with a pool of
slave scripts in the root prim, and she tested it on a few customer with
different
On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble 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
I'm curious why people deem it necessary to distribute resizing systems with
a slave script in each prim. Most of the resizing scripts I've seen only
allow you to adjust the size and position of prims, this is at most 6
floating point numbers per prim (x, y, z offsets, x, y, z scale). These
values
Add an optional command for scripts of llLoadWhenAvatarIsWithin(meters) and a
lot of us would use that to control waterfalls, fountains, pets and other
things :) Of course, you
need an CHANGED_ACTIVED and CHANGED_DEACTIVATED events to go with it.
Twisted
From: babb...@lindenlab.com
.
Tigro Spottystripes wrote:
> If normal usage is not gonna be affected negatively, if most users
> aren't gonna be affected negatively, then how can this problem be so big
> to justify such measures at all?
> ___
> Policies and (un)subscribe information av
On Wed, 16 Dec 2009 00:35:27 -0500, Kent Quirk wrote:
> First, sarcasm isn't the best way to get a positive response.
>
> Second, we do listen -- not only this time, but many times in the
> past. We hear a lot, including a fair amount of contradictory advice.
> .../...
Not wanting to start a f
On Wed, 16 Dec 2009 14:56:41 -0200
Tigro Spottystripes wrote:
> If normal usage is not gonna be affected negatively, if most users
> aren't gonna be affected negatively, then how can this problem be so
> big to justify such measures at all?
why, as you can read just above in this thread, a large
If normal usage is not gonna be affected negatively, if most users
aren't gonna be affected negatively, then how can this problem be so big
to justify such measures at all?
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.
On Wed, Dec 16, 2009 at 1:44 PM, Babbage Linden wrote:
> Very amusing and mostly correct summary of the situation (and about 6 months
> of office hour logs), thanks Imaze.
One worrying thing about the office hour transcript is that the memory
limits are going to be enforced *before* you could set
On Wed, Dec 16, 2009 at 10:36:26AM -0500, Jesse Barnett wrote:
> Normal use of scripts are not affected. Hair and shoes with several hundred
> scripts per avatar is what I am specifically referring to and should not be
> considered "normal use". Go back and look at Babbage's meeting minutes to see
Those are not problems with *dynamic* limits.
Dynamic here means that the limits are not enforced until
REALLY necessary (and then accordingly to how the estate
manager thinks is reasonable to devide the resources).
Fixed limits means that each group (each parcel and each
avatar only gets the mem
Something about "Where Angels Fear to Tread" comes to mind but.
As a community, we have become very tolerant of poor performance. I have
often heard the sarcasm "Lag is always with us." I wondered why. The
assertion that things are working right now isn't true. "Things" fall apart
often and
Normal use of scripts are not affected. Hair and shoes with several hundred
scripts per avatar is what I am specifically referring to and should not be
considered "normal use". Go back and look at Babbage's meeting minutes to
see some of the outrageous script abuse going on.
___
On Wed, Dec 16, 2009 at 08:56:15AM -0500, Jesse Barnett wrote:
> Scripted hair, scripted shoes ... fashion shows will be a mess. ;-)
> Tillie
>
> Which is kind of the point and one of the main reasons this is having to be
> implemented.
>
> Jesse Barnett
Huh?
I thought the reason was to
On Wed, Dec 16, 2009 at 8:49 AM, Tillie Ariantho wrote:
>
> Scripted hair, scripted shoes ... fashion shows will be a mess. ;-)
>
> Tillie
>
Which is kind of the point and one of the main reasons this is having to be
implemented.
Jesse Barnett
___
Pol
Aleric Inglewood kirjoitti:
> On Wed, Dec 16, 2009 at 2:21 AM, Kent Quirk wrote:
>
>
>> "We're planning to make script memory usage along with our proposed
>> script limits visible to all Residents for an extended period before
>> enforcing any limits.
>>
>
> This is doomed to fail, and we
On 16.12.2009 14:43, Argent Stonecutter wrote:
> The object won't rez if the parcel you're in already has too many
> scripts in it.
>
> You would still be able to rez the object in a sandbox.
>
> It is unlikely that you would have a problem unless you had hundreds
> of scripts.
Scripted hai
The object won't rez if the parcel you're in already has too many
scripts in it.
You would still be able to rez the object in a sandbox.
It is unlikely that you would have a problem unless you had hundreds
of scripts.
___
Policies and (un)subscribe
On Wed, Dec 16, 2009 at 2:21 AM, Kent Quirk wrote:
> "We're planning to make script memory usage along with our proposed
> script limits visible to all Residents for an extended period before
> enforcing any limits.
This is doomed to fail, and well for the following reason:
The whole implementa
Very amusing and mostly correct summary of the situation (and about 6 months
of office hour logs), thanks Imaze.
2009/12/16 Imaze Rhiano
> ... everything around this really leads to one real question: "If a
> tree falls in the forest and no one is around to hear it does it make a
> sound?"
> Or
On Wed, Dec 16, 2009 at 2:03 AM, Stickman wrote:
> The comfort or early warning I expect is that we're going to get
> better tools to see behind the scenes on scripts before the limits
> actually show up. My fear is that it's going to be right when midterms
> crop up and have a two week window to
Hm, nice reading, most of it was indeed comforting to some extent, thanx
for bringing this to my inbox :)
Btw, is there some sort of communication medium for a group of people
that doesn't require people to communicate in real time nor actively
check to see if anyone has said anything new, nor req
25 matches
Mail list logo
