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
