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