[sldev] User needs on script limits

Lillian Yiyuan lillie.yiyuan at gmail.com
Sun Dec 20 09:34:36 PST 2009


All of my suggestions above are in the client: lsl changes, purchased
folder, and rez on attachment.

Now it may well be that there should be a separate topic for the whole
question, but he viewer aspect of how the users are going to interact
with a script limited service cannot be ignored, or swept into some
other location.

There is also the reality that there is a very large overlap between
people who are trying to accomplish solutions in world, an thus
script, with people who want changes to the client, because those
solutions in world do not lend themselves to being fixed by scripts.
The intersection of fashionistas and client developers, is far
smaller.



On Sun, Dec 20, 2009 at 9:09 AM, Tateru Nino <tateru.nino at gmail.com> wrote:
> Actually, I think one of my two points earlier was that this list is
> weighted specifically towards those involved in viewer development or
> whom have a keen interest in that, and - as such - doesn't seem like an
> appropriate or representative forum at all for the topic.
>
> Surely, there must be some more inclusive way to have a discussion about
> this - if discussion it actually be. For the most part it just looks
> like a whole bunch of folks (and admittedly, quite nice folks in the
> main. I'm not singling anyone out, and especially not you, Lillian) who
> want to get their two-cents worth heard by Linden Lab developers, and
> who don't seem to have any other avenue for doing so.
>
> Heck, just doing a quick count of messages, the topic would carry its
> own mailing list at this rate, and free this one up for - you know -
> talking about the viewer again. :)
>
> If, indeed, as has been suggested, the process of analyzing the grid,
> use-cases, running tests and finally producing a cohesive strategy for
> dealing with that... if that process is going to take the predicted
> "months", it seems like viewer development discussion is going to get
> drowned out a little in the torrent.
>
> Just my own two cents, you understand :)
>
> On 21/12/2009 3:55 AM, Lillian Yiyuan wrote:
>> 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.
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting privileges
>>
>>
>
> --
> Tateru Nino
> http://dwellonit.taterunino.net/
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>


More information about the SLDev mailing list