There's a semantic issue here that we need to clear up. When we say how much memory a script is "actually using", that means the amount of memory the script is making semantic usage of. However, the script is *allocated* a larger amount. This larger amount is the amount that matters to the system: it's the *cost* of the script, and what needs to be controlled. If someone is wearing scripts that are allocated 1MB of space, it doesn't lower the impact on the sim that the scripts happen to be making effective use of only a small fraction. That memory is still reserved for the script and can't be used by anything else, and contributes to thrashing when overallocated.
The metrics need to show the *burden* the scripts are placing on the system. It doesn't help to see that they're using that burden inefficiently and give the wearer a break on that basis. In other words, It's the cost that counts, not the benefit. Lear On Tue, Mar 9, 2010 at 1:29 PM, Kitty <sl...@catznip.com> wrote: >> It might be possible to add display of memory currently used >> as well, but what's the use case for it? > > It would allow residents to independently review the imposed script limits. > > Another use case would be because people *are* going to start banning > residents based on what the script limits UI says (just like people are > ejected/banned over ARC). If some random resident hasn't spent hours and > hours trying to see if everything they've bought in the past few years > doesn't have an update for it that uses the upcoming "llReserveMemory" they > will end up banned from random places for wearing the wrong item. > > Simply reporting "actually in use" for *other* residents even though the > individual limit is against a "hypothetical maximum limit" would do a whole > lot to help with that. A Mono script would still count as 64Kb against that > avie's personal limit, but anyone else trying to look for information would > be seeing say 8Kb because that's how much it's actually using and actual > usage is really the only thing parcel and sim owners are (or should) care > about when it comes to other people's attachments. > >> Likewise, it would be useful for verifying sellers' signs' >> claims immediately after purchase, should a scripted object >> be displayed as a static, unscripted object. The ability to >> see the number of prims in a linked set helps similarly for >> advertised prim counts. > > It likely won't take very long for the sellers of scripted gadgets to > include "script usage" information, but it will be many months before > someone selling - for example - earrings with a texture change script is > going to do the same or before they even find out that there is such a thing > as script limits. > > The examples of "troublesome" cases that require script limits in the first > place never seem to be the highly technical kind, but rather the every day > "mundane" things like hair, shoes, jewelry, prim skirts, etc. So the people > who are least likely to include that information, or even know that > something like script limits exists. > > I already have literally hundreds of "script-in-every prim" things I've > bought - where I can't even delete the scripts because of a change to "no > modify" some time back - that might just be good for relocating to the trash > 6 months from now. Moving forward, noone should find out *after* purchase > whether or not what they just bought is something they'll be able to wear, > or whether they'll see the dreaded "Not enough script resources available to > attach object!" and know that they just threw money out the window. > > When someone picks "Buy", the script limit/usage for each individual object > inside of the prim should really just be right there alongside the > permissions the item will have. > Use of green/yellow/red from ARC would make things even simpler still for > the average resident: anything using less than 1/38th of the per-avatar > limit (limit divded by # possible attachments) shows green, several > multiples is yellow and anything more is red. > > Kitty > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
