Creators, could we please be reasonable with this 'no mod' paranoia?

She has a big ball with free hair in it on the beach, too.

Amacci has some styles without resize scripts. Sirena does 3 sizes per style so I don't think she uses resize scripts either.

I like my old ETD hair since I can edit single prims.

Sirena not only does three sizes per style but her hairs are mod anyway; the three sizes are just there, I think, as a convenience for people.

She asked in one of other forums (Builders Tips, maybe?) not so long ago if she should add resizer scripts, while keeping her hairs mod, and, of course, everyone said no, please don't. This, she said, confirmed her feeling it was a bad idea.

I can not give you a direct link to where I read it, but I have read several places that LL plan to restrict the number of scripts an avatar can use. I am not sure if I read it in New World Notes, or in different threads on different forums.

I don't like no mod and scripted stuff, and I am even more careful buying that now. If, LL really set a limit to number of scripts, there will be a lot of angry customers when they realize they can't wear both that scripted hair and the scripted shoes, they have to choose.... Not to mention the scripted jewelery they want to use with the gown that has resizer skirt....

I am not fond of "click to change texture" either. I know, I am oldfashioned and grumpy, park my wheelchair in the corner! But big hairshops like Maitreya and Truth sell packs of colors. Their shops are always filled with customers. They don't have to use "click to change color" scripts. Same with Bare Rose, they sell different colors of clothes in a folder. It is really a matter of shopping smart for me now.

Yes, Marianne, Babbage has been telling scripters that there will eventually be limits on the total amount of script memory an agent can use (and similar limits on each parcel based on its size, similar to prim count limits). We expect tools for measuring usage early next year, and the limits imposed perhaps six months later.

The reasons for these limits are also the reasons that it's a problem to use a lot of scripts to resize an item:

1. When too much script memory is used, the sim will start to swap to disk--which creates very substantial lag even for non-script functions (like physics), and not only on that sim but also on every sim sharing that server (four regular sims, or up to 16 OpenSpaces or Homesteads).

2. A simulator bug causes scripts to "leak": they aren't always cleaned-up properly when the script leaves the sim, which means that scripts sometimes consume memory (and other sim resources) even when the object that contained them is no longer around. (Ultimately this needs to be fixed, and I think it used to be worse in some earlier server releases, but it hasn't been fully resolved yet.)

3. Even the simplest script uses some increment of memory, so the *number* of scripts make a difference. (I believe the minimum is 4K for Mono and a uniform 16K for LSL; Mono-compiled scripts can grow--up to 64K now, IIRC.)

4. Scripts consume the same amount of memory even if they're set Not Running.

5. (Not about memory) Even the simplest script uses some sim CPU time even if it's not doing anything. Apparently an artifact of how the scheduler is implemented, a script in a state with no active event handlers (e.g., just a default state_entry long after the script started) still gets a tiny slice of processor time.

It would help if there were fewer scripts in resizeable items. So:
To a degree--Damani suggested one approach earlier in the thread, and I hinted at another--but it's not as straightforward as it sounds. Underlying any implementation there's the problem of remembering the current "size" of the constituent prims--where "size" really entails scale and local position and rotation. The typical resizer script "remembers" all that by simply looking at the prim parameters, but because llGetLinkPrimitiveParams() doesn't exist, there's a script in each prim. (Having a script in each prim also makes the resizing faster because it can happen asynchronously in each prim without a 200msec delay between changes; mitigating the effect of that limit requires multiple scripts, even if they're located in the root prim.)

In Damani's suggested approach, the prims parameters would still be this "size memory", but the scripts would be transient. My suggestion would make the root-resident script remember those "size" parameters for all the prims, which would use somewhat more script memory when idle, but not require pushing the scripts out to the prims.

In lieu of llGetLinkPrimitiveParams(), I don't think there's any simple, no trade-off solution.

It's not something we really have to care about but every attachment with an active script also results in a new asset being created each time it's detached (includes each time you log off).

If you log off the sim will check each attachment and see if it's been changed. If it hasn't it's simply destroyed; if it has the sim has to upload the attachment to the asset server and then contact the inventory server to update the asset reference on the inventory item to the newly created asset.

Similarly: if 1,000 people buy an unscripted item and only 1/4 ends up modifiying it then that results in 251 assets (the original asset which is referenced by 750 people and one unique asset for each of the 250 who modified it) but then no more than that.

If 1,000 people buy the same item but with a script in it then you have 1,001 assets after each of them has worn it once. If they all log on once a day wearing it then after a month you'll have 30,001 assets (29,000 of which will be garbage collected at some point).

If all of the scripts can be deleted it just stops new assets from being created and there will never be fewer than 1,001 assets even if everyone deletes the scripts.

Again, that's LL's problem and they have to make sure everything scales and doesn't degrade. It also certainly shouldn't prevent anyone from putting a useful script into anything. It's just an illustration that even aside from any future active script restrictions just the fact that there's a script in it all places more stress on subsystems that are shared across the entire grid (even if only at the time an item is detached or at log-off).

not exactly true, only running scripts in active memory, at least in the case of MONO (LSO I'm not so sure) which partly explains the huge insertion spike seen with MONO. at least that's what I've gathered from the little news that trickles down.

At a Babbage office hour a few months back, I asked whether scripts that were set Not Running would count toward the memory limits, and he said yes, because they still consume the same memory. I found that a little surprising, which is the only reason I remember it.

One would think they'd at least get paged out to disk, unless there's something really funky going on. They do not get a timeslice in the scheduler, so I dunno why they'd need to be in the resident set.

I'm sure that at least some part of some inactive scripts are paged out... fopr that matter, I suspect part of small *active* LSL scripts get paged out as well... so long as there's plenty of space between stack and heap... but I doubt that scripts are block aligned. To a first approximation, you can't assume big savings from paging even for LSL.

And Mono script data and code isn't allocated in blocks: all the data and code for all the scripts are all in a big memory gumbo. Paging a script to disk would mean running through all its memory and copying it out to a file as strings then freeing it up.

And regardless, the program itself doesn't really know what's in memory and what's paged out, so it has to treat them all the same.

They do get paged out.

The difference between MUDs and SL is that all scripts in MUDs are "inactive" in SL terms. There's no real-time component, objects react to events, but in most such systems events are only delivered when there are logged in users present to cause them.

I've got a simple policy.

If it's got prim parts and it's no mod, I don't buy it. Period.

Yes, I miss out on some fine designers. They miss out on my money. And I teleport reliably.

No mod = no buy.

Pure and simple.