[sldev] User needs on script limits

[Lillian Yiyuan]

This list is heavily weighted towards developers, and that means
people who sell scripts. There is no way this change isn't going to
have a negative impact on them at first, because previously a resource
that they used for free is going to be charged for. However the people
who are paying for this, the users, are not represented here, and the
conversation largely has been about inflicting as much pain on the
users as possible to protect other interests, namely LL and
developers. The users need certain features to deal with tis change,
especially for content that was written in the face of the reality
that scripts were free, and the LL permissions system is a borked
nightmare that cannot ever be unborked.

The first thing users need is the ability to make all scripts in an
object "no load." Not just stopped, which still uses resources, but no
load. They need this from inventory, not from rez, since the object
might not rez under most proposed systems. Why, because now that they
are paying for scripts, they have a right to determine how their
resources are allocated, not the creator of the object. Before when
they weren't being charged there was an argument for creator's rights,
now that argument is outweighed by the user's right to dispose of
their property, namely script limit.

Second they need the ability to change the names of items in
inventory, even if the object is no modify. Why? Because for an object
that is modifiable by script, what the user will want to do is rez the
modifiable version, modify it through the scripts, rename it to
identify the new properties (such as say brown chestnut angel hair by
nefarious designs.) Set the scripts on it to no load, and put it back
into inventory. This way it is modded per the scripts of the creator,
but from then on, the load scrits version is what the user will wear.
Some designers do this, but many do not, and the content that is not
is already out there. Therefore, the capability has to be put in by
the system, because before it was a designer being cooperative in the
face of a commons, now it is a property situation, and the property
owner (the user) has to be able to control resource usage for a new
restriction being put on them post hoc.

Now what about the problem of users then saying "my hair doesn't work!"

For this it would be best if a new system folder were created.
"Purchases" An object that goes into purchases, if copyable, not only
rezzes a copy, as now, but if it attaches, the attachment is a copy.
This way, when the user rezes the copyable hair, or shoes, or
whatever, they get a copy rezzed. This is presently done on "make
outfit" Instead it should be done from rezzing. The user can then run
the modify scripts, no load them, and the master copy is still in
purchases. If the user borks the copy they make, the delete it, and go
back to the master copy, which won't ever actually leave inventory. So
the Purchases system folder ill have the property that anything in it,
if possible,  attaches a copy, rather than just rezzes a copy as now.

This leads to the ability to "attach a copy" as an option for
attachments and HUDs. The user find a scripted version of the object,
attaches a copy, plays with it, and saves that. This is useful for
content in other contexts, such as working with mod content, so that
the master copy stays in inventory.

By default, objects received from an object should go into the purchases folder.

Finally, users need the ability to see how much they are using, by
object, from their limits, and what those limits are if they are
dynamic (which they ought to be).

So basically: set scripts to no load in selection, regardless of mod
bit, attach a copy, purchases folder which by default attaches a copy.

Much of the script clutter comes from the master slave model. For new
content this can be fixed by offering List versions of anything that
currently has a delay, and by llGetLinkedPrimitiveParams. These list
versions will take a list, whose length can be limited by function
call say 16 in the case of IMs or whatever, rather than a single
value. This way if an instruction s to llSetLinkedPrimParamsList, the
scripter passes a list of the linkset numbers to be affected by the
call. The script engine parses the list and sets off the command for
the prims on that list. This way there is no reason for master-slave,
or at least much less of a reason for master slave, which is, after
all, to send a command to a list of avatars, objects, or link sets.
Right now only hard coded lists (such as the entire link set) can be
affected this way, what would much of the need ofr master-slave, is to
allow an arbitrarily defined list to be passed in. In a real
programming language, we would overload, but in LSL we ned a different
function call name. This llBlahList as a format.

So LLGetLinkSetPrimitiveParams, and *List versions of anything with a
delay, with that list length limited by call to prevent griefing and
so on. Even if master slave is still used, it will be in multiples of
the list length, not in units of one.