Resize Scripts: A Brief Survey

[Czari Zenovka]

---

Marianne Little wrote:

Like my mesh boobs, I got a script tuneup that reduced the scripts from 23 to 2 and they still work with all the options intact.

 

---

I'd like to hear more about this script tuneup - is it a script that reduced the scripts or removing unneccessary scripts yourself?

When I first began SL, I purchased a pair of pumps from a then very well known shoe designer.  I was thrilled because they came with a HUD that changed the shoe in every way imaginable:  texture/color, amount of shine (I don't hear much about shine anymore - did something replace that or was that a pre-windlight thing?), various types of heel prints left behind, clicking sound on/off, and probably others I'm forgetting.  The merchant sold two types of these pumps - one with textures and one solid colors.  I purchased them both and thought "I'll never have to buy another pair of shoes in SL!!"  (I'm not a typical female in that I detest shopping RL & SL.)

I wore those shoes proudly for years, totally unaware of how scripts affected my SL, and that of those around me.  About two years ago I took a class at Builders Brewery called "Let's Lessen Lag" taught by a SL scripter.  That really opened my eyes.  I promptly went home and began tearing out the invisi-scripts from my older shoes and then got to my beloved pumps.  There are 30+ scripts PER SHOE in those things!!! ACCCKKKK!!!  Since they are copy, for awhile I patiently pulled out all the scripts after changing the look for a particular outfit.  About the third time I did that (and some of those scripts were hard to find) I gave up and just started buying new shoes.  LOL

*Makes note to see if that designer is still around and/or has updated this shoe line*

 

[Madelaine McMasters]

Resize scripts are the best thing that ever happened to SL...

[Marianne Little]

30 scripts each isn't so bad. I deleted worse... some engineer boots that I really liked had over 100. I should have saved them just for lulz. It was resizer scripts without a delete scripts function, so it was just impossible to do anything with them.

The script tuneup is made just to reduce scripts in Lolas Tangos, I am sure they work only for them and not for other items.

https://marketplace.secondlife.com/p/IM-Script-Tuneup-for-Lola-Tango/4987479

It was worth buying the script,. Annoying how a a product can be so popular and sell so much without the seller bothering to make it more user-friendly. Hey, you know what... reminds me of LL! 

[Czari Zenovka]

Thank you so much for the info and lol re: LL and some SL items.

Edit: clarification

[Madeline Blackbart]

Would be because the makers of Lolas products generally seem to not give a crap about there customers. The other brands at least provide free script updates. So yes very much like LL.

[Madeline Blackbart]

I will admit I am a horrible person with this. I were upwards of 200 scripts or more at a time. To be fair they general seem to be well written scripts and come under the 2mb of run time or so... I think one needs to consider more then just number of scripts but quality. As one script that's poorly written can be as laggy as 10 or more.

[Storm Clarence]

I only keep one (1) resizer script... and that is in case(s) of emergency  

PS We live in a world where one size does not please all. 

 

[steph Arnott]

200 scripts or more and under 2mb,

i do not think so.

default{    state_entry()    {        llSay(0, "Hello, Avatar!");        integer used_memory = llGetUsedMemory();        llOwnerSay((string)used_memory + " bytes of memory currently used.");    }    touch_start(integer total_number)    {        llSay(0, "Touched: "+(string)total_number);    }}//3876 bytes used

 

[Kwakkelde Kwak]

---

steph Arnott wrote:

200 scripts or more and under 2mb,

i do not think so.

---

Why not?

2MB = 2x1024x1024 = 2097152 bytes

Divided by 200 that's a little over 10kb per script.

LSL scripts use 16kb, mono scripts anything between 3kb or so and 64kb.

Seems like a very realistic scenario to me.

[steph Arnott]

Assuming every script was running at 7500 bytes (anything below that would be rather useless) and set to a memory limit of 10Kb (anything below a 10k limit would risk it being ignored and reverted back to 64K), its feasible. But unlikely.

[Kwakkelde Kwak]

---

steph Arnott wrote:

anything below a 10k limit would risk it being ignored and reverted back to 64K

---

Enlighten me....

[steph Arnott]

The llSetMemoryLimit is not what is used but an upper limit. No scripter is going to set it so close to what llGetMemoryUsed returns because if the limit is too low it will be ignored and 64k will be allocated. So if the script is 7.5Kb a safety allowance is added and 2.5Kb will make little difference on resources.

ADDED: This is of topic. Ask in the scripting forum if you interested.

[Kwakkelde Kwak]

Well I'm sorry but you brought it up.

Scripts can have a 100% steady or 100% predictable memory use, I bet most small child scripts have that. So it's perfectly normal to set the memory limit to a lower number than 10k.

As far as I know, it won't be ignored either. If you go over the memory limit, you'll get a stack heap error, just like you get when an LSL script goes over 16k. What point would there be for a memory limit if it didn't work? The whole function is pointless enough already

The 2.5 in your example doesn't cost any resources at all. Like you said yourself, it's a limit, not actual use.

[steph Arnott]

Which is why i said its off topic. This is from LL When n is too small, llSetMemoryLimit(n) is ignored and the memory limit is not changed. ADDED: The convo was about te 200 not 10 or 50.

[Kwakkelde Kwak]

Unless LL changed it, that is only the case when you compile the script. Once running, you will get an error when you go over the limit.

"ADDED: The convo was about te 200 not 10 or 50."

I don't understand that

[Erik Verity]

It has not changed, nor is that the way it works. The memory limit set will be honored only if the script can run within it. A stack/heap collision will only occur if it goes over the 64kb limit. If you set the limit too low, it will simply be ignored.

There is no problem with a low limit either. Many scripts run fine at only 4k, which I believe is the minimum you can get it to show using. It depends on what the script does; some simple scripts will always run using the exact same amount of memory, some will vary depending on what it needs to do.

[Kwakkelde Kwak]

Then why do I get a stack heap when I make a supersimple script with a memory limit of its initial use+64 which adds a small amount of data on a list on touch?

[steph Arnott]

be a min

[Erik Verity]

Without being in-world or right there with you, I can't possibly answer or verify that. I can say that I have tested it myself and know very well that it is true. The limit basically is only for what it shows to be using when checked by land tools, other scripts, checking your av script info, etc. The script will use what it needs.

It is also well documented in the wiki - and again, I have tested it myself. Set a limit too low and the script will run fine as long as it does not go over the 64k limit.

This is only for mono scripts in the first place - are you using LSO instead? I think you almost surely must be.

http://wiki.secondlife.com/wiki/LlSetMemoryLimit

Edit: Or are you clicking it a hundred times?

[Kwakkelde Kwak]

I added 64k by adding "blah"? Then I wonder how much memory a real script uses....

You know that's not the case. A memory limit is a memory limit.

As you can see, even with a lot of blah only 4k of memory is used.

EDIT ok, I see you meant 64, I added 64 because after the script sets the limit, there's another event. The 64 allows that event to fit the memory. Anything on top of that, not even close to 64k, causes a stack heap collision, which means the script ran out of available memory.

@Erik, as you can see by my first script, I tested it as well. I have done so before. Like I said, my conclusion is that the limit is set when the script compiles. If it's too small it will be ignored, if it's enough, it will be a true limit which can't and won't be ignored once the script is running. Both scripts were running in mono, how else would I get a stack heap with the first script?

More edit... no, one click is enough to trigger the error.

 

[Erik Verity]

I do understand the difference you're demonstrating here, and never made any attempt to distinguish between memory use recognized only at compile time and that during run-time. I have seen the limit set a little too low just to have it show using the full 64k and run fine.

Considering there is no hint of this behavior mentioned in the wiki, and it could only show up if you set a limit between that (almost surely small amount) between max potential identified at compile time and max possible at run-time, it would be worth editing the wiki to clarify. Every indication is given that a limit set by the script is only for use by script checkers and ignored otherwise; I don't think anyone would normally be estimating a limit in state_entry beforehand in the first place, which might be about the only way to set a value too low and still be unrecognized.

Edit: I realize limits are set in state_entry - but it wouldn't make sense to get a useful value from llGetUsedMemory() from there - it kind of defeats the purpose of that function call altogether to try to get a value of memory used before the script has even run.

[steph Arnott]

integer limit = 3000;integer used;integer whatNow;default{    state_entry()    {        used = llGetUsedMemory();         llSetMemoryLimit(limit);        llSay(0,"Limet set to"+(string)limit);        llSay(0,"Whats used memory"+(string)used);            }    touch_start(integer total_number)    {        whatNow = llGetUsedMemory();        llSay(0, (string)whatNow);    }}

 

Object: Limet set to3000 // i changed the limit on test

[09:33] Object: Whats used memory4404

[09:33] Object: 4404

[09:33] Object: 4404

[09:34] Object: 4404

ADDED: Nope, no stackheap error and the limit is just ignored, end of story.

integer limit = 3000;integer free_memory;integer used;integer whatNow;default{    state_entry()    {        used = llGetUsedMemory();        free_memory = llGetFreeMemory();        llSay(0,(string)free_memory + " bytes of free memory available for allocation.");         llSetMemoryLimit(limit);        llSay(0,"Limet set to"+(string)limit);        llSay(0,"Whats used memory"+(string)used);        free_memory = llGetFreeMemory();        llSay(0,(string)free_memory + " bytes of free memory available for allocation.");          }    touch_start(integer total_number)    {        whatNow = llGetUsedMemory();        llSay(0, (string)whatNow);        free_memory = llGetFreeMemory();        llSay(0,(string)free_memory + " bytes of free memory available for allocation.");    }}

 

09:59] Object: 60620 bytes of free memory available for allocation.

[09:59] Object: Limet set to3000

[09:59] Object: Whats used memory4916

[09:59] Object: 60592 bytes of free memory available for allocation.

[10:00] Object: 4916

[10:00] Object: 60592 bytes of free memory available for allocation.

[10:00] Object: 4916

[10:00] Object: 60592 bytes of free memory available for allocation.

[10:00] Object: 4916

[10:00] Object: 60592 bytes of free memory available for allocation.

[PeterCanessa Oh]

---

Perrie Juran wrote:

---

PeterCanessa Oh wrote:

BTW, I have to say that while I appreciate the intent behind this thread (and read your comment in another that led to this) the replies here are almost all going to come from the 'well-educated' SL users.  Forumites are, to put it mildly, more used to having their assumptions questioned than the usual know-nothings, care-less, who are likely to put multi-MB scripts in an object in the first place or leave them there later.

---

I was very aware that this unscientific survey was likely to produce slanted results, that the majority of respondents would be people who are better educated on this subject.

But surprises do happen, like when I did my survey on screen sizes.  I was expecting to see a lot more people with smaller screens because of the number of lap top users who post here.

Forums are no doubt one of the worst places to attempt to do a scientific survey.

---

Oooh, that must have been while I was away.  Link (or summary) please, I'd be interested in seeing the results you got.

[Perrie Juran]

---

PeterCanessa Oh wrote:

---

Perrie Juran wrote:

---

PeterCanessa Oh wrote:

BTW, I have to say that while I appreciate the intent behind this thread (and read your comment in another that led to this) the replies here are almost all going to come from the 'well-educated' SL users.  Forumites are, to put it mildly, more used to having their assumptions questioned than the usual know-nothings, care-less, who are likely to put multi-MB scripts in an object in the first place or leave them there later.

---

I was very aware that this unscientific survey was likely to produce slanted results, that the majority of respondents would be people who are better educated on this subject.

But surprises do happen, like when I did my survey on screen sizes.  I was expecting to see a lot more people with smaller screens because of the number of lap top users who post here.

Forums are no doubt one of the worst places to attempt to do a scientific survey.

---

Oooh, that must have been while I was away.  Link (or summary) please, I'd be interested in seeing the results you got.

---

http://community.secondlife.com/t5/General-Discussion-Forum/What-Size-Computer-Monitor-Do-You-Use/m-p/1941317/highlight/true#M99902

[Kwakkelde Kwak]

---

Erik Verity wrote:

 

Considering there is no hint of this behavior mentioned in the wiki, and it could only show up if you set a limit between that (almost surely small amount) between max potential identified at compile time and max possible at run-time, it would be worth editing the wiki to clarify. Every indication is given that a limit set by the script is only for use by script checkers and ignored otherwise; I don't think anyone would normally be estimating a limit in state_entry beforehand in the first place, which might be about the only way to set a value too low and still be unrecognized.

---

The function is a bit of an oddity in our toolbox. It was meant to help scripters with the dreaded memory ceiling that luckily never saw Second Life daylight. The limit is a limit though, no way around it. The only use for it now is to inform lag-tracking meters and it does a poor job at that, since those meters show the limit, not the use.

I agree the wiki could be more clear on this, but I'm not exactly a seasoned scripter, so I don't feel that's my job:)

---

Edit: I realize limits are set in state_entry - but it wouldn't make sense to get a useful value from llGetUsedMemory() from there - it kind of defeats the purpose of that function call altogether to try to get a value of memory used before the script has even run.

---

The state entry isn't the best place for it of course. It would make sense to set the limit "on the fly" after memory changing commands to give the lag meters some useful and reliable information. My scripts were just examples to show how you can run out of memory, something you'd want to avoid in a real script I'd say.