Tenaar Feiri

steph Arnott wrote: What part off you are perfect do you not understand, in the SL world your script is not. I try to be polite and you just want to keep pushing.llGetMemory is a gestimate that is all. OK, and I conceded to your point about llGetUsedMemory() and used llScriptProfiler() instead. The difference in results were marginal at best. See, I'm not looking for "you are perfect" or "you are right". I'm looking for evidence that you have to back up your claim that moving code out of defined functions doesn't affect the memory usage either way. You've come off as terribly sarcastic and impolite through more than half of this debate, and now you're defaulting "you are right about everything" just because you think that's what I wanted to read, which is quite frankly offensive. If you cannot argue or debate without defaulting to such responses the moment you get sick of it, then you shouldn't engage in them in the first place. And if you are unwilling to stand for your own claims then I have no more time left for you.

I just did the script profiler then, if it'll please you. Here's the results: With function: [08:00:26] clock face: This script used at most 7860 bytes of memory during function. Without function: [08:01:13] clock face: This script used at most 7228 bytes of memory during function. Script with function: integer talkToClockChan;integer Key2AppChan(key ID, integer App) { // Generates a unique channel per key, with additional app modifier. return 0x80000000 | ((integer)("0x"+(string)ID) ^ App);}list time;integer setup;integer minutehandLink;integer hourhandLink;funcRotateDials(){ rotation rot; if(!setup) // If we haven't set it up yet, it's time! { integer i = llGetNumberOfPrims(); integer x; for(;x<=i;x++) { if(llGetLinkName(x) == "minutehand") { minutehandLink = x; } else if(llGetLinkName(x) == "hourhand") { hourhandLink = x; } } rot = (rotation)llList2String(llGetLinkPrimitiveParams(minutehandLink, [PRIM_ROT_LOCAL]), 0); vector rot2 = llRot2Euler(rot); rot2 = <rot2.x,rot2.y,(rot2.z-0.105)>; rot = llEuler2Rot(rot2); llSetLinkPrimitiveParamsFast(minutehandLink, [PRIM_ROT_LOCAL, rot]); }} default{ state_entry() { talkToClockChan = Key2AppChan("3fb9a3b2-dcbf-4dfb-8740-4630ec499ff3", 143); llListen(talkToClockChan, "", NULL_KEY, ""); } touch_start(integer num) { llScriptProfiler(PROFILE_SCRIPT_MEMORY); funcRotateDials(); llScriptProfiler(PROFILE_NONE);llOwnerSay("This script used at most " + (string)llGetSPMaxMemory() + " bytes of memory during function."); } listen(integer c, string n, key id, string m) { time = llParseString2List(m, [":"], []); } } And script without function: integer talkToClockChan;integer Key2AppChan(key ID, integer App) { // Generates a unique channel per key, with additional app modifier. return 0x80000000 | ((integer)("0x"+(string)ID) ^ App);}list time;integer setup;integer minutehandLink;integer hourhandLink;default{ state_entry() { talkToClockChan = Key2AppChan("3fb9a3b2-dcbf-4dfb-8740-4630ec499ff3", 143); llListen(talkToClockChan, "", NULL_KEY, ""); } touch_start(integer num) { llScriptProfiler(PROFILE_SCRIPT_MEMORY); //funcRotateDials(); rotation rot; integer i = llGetNumberOfPrims(); integer x; for(;x<=i;x++) { if(llGetLinkName(x) == "minutehand") { minutehandLink = x; } else if(llGetLinkName(x) == "hourhand") { hourhandLink = x; } } rot = (rotation)llList2String(llGetLinkPrimitiveParams(minutehandLink, [PRIM_ROT_LOCAL]), 0); vector rot2 = llRot2Euler(rot); rot2 = <rot2.x,rot2.y,(rot2.z-0.105)>; rot = llEuler2Rot(rot2); llSetLinkPrimitiveParamsFast(minutehandLink, [PRIM_ROT_LOCAL, rot]); llScriptProfiler(PROFILE_NONE);llOwnerSay("This script used at most " + (string)llGetSPMaxMemory() + " bytes of memory during function."); } listen(integer c, string n, key id, string m) { time = llParseString2List(m, [":"], []); } } That should make you happy. Are you going to tell me that llScriptProfiler() is unreliable too, now? I really don't understand why you're being so unpleasant about this. You're not being constructive at all.

steph Arnott wrote: Any way, do as you feel suits you. Used memory is not very reliable. This isn't about what suits me, it's about whether I am right or wrong in my advice to try and move code out of functions & into the executing code itself to conserve memory. I'm using GetUsedMemory() because I don't want to mess with my script using the memory profiler, but it already looks promising. If I'm wrong, I'm perfectly willing to accept that--as I have done earlier in this topic, but I'm not just going to take your word for it if what I'm observing is what seems correct. Just telling me that I am wrong when giving advice, and then not providing any examples as to why I'm wrong, does in no way contribute to the topic, and it does not help the OP. And that's all I care about, helping the OP. If I'm wrong, I'm wrong & that's fine. Correct me then with a practical example. Educate me, so other people who come find this topic can be educated too.

By running this at the end of the function before it clears, without doing any manual clearing of the temporary variables defined during runtime: llOwnerSay((string)llGetUsedMemory()+"b"); This returns the amount of memory--in bytes, that the script is currently using.

right, I went ahead & tested this to be sure now. I gained nearly 500 bytes of memory just by removing a function & moving its code into the executing code, so I don't know why you say it makes no difference. Here's the code I tested it with: integer talkToClockChan;integer Key2AppChan(key ID, integer App) { // Generates a unique channel per key, with additional app modifier. return 0x80000000 | ((integer)("0x"+(string)ID) ^ App);}list time;integer setup;integer minutehandLink;integer hourhandLink;/*funcRotateDials(){ rotation rot; if(!setup) // If we haven't set it up yet, it's time! { integer i = llGetNumberOfPrims(); integer x; for(;x<=i;x++) { if(llGetLinkName(x) == "minutehand") { minutehandLink = x; } else if(llGetLinkName(x) == "hourhand") { hourhandLink = x; } } rot = (rotation)llList2String(llGetLinkPrimitiveParams(minutehandLink, [PRIM_ROT_LOCAL]), 0); vector rot2 = llRot2Euler(rot); rot2 = <rot2.x,rot2.y,(rot2.z-1)>; rot = llEuler2Rot(rot2); llSetLinkPrimitiveParamsFast(minutehandLink, [PRIM_ROT_LOCAL, rot]); }}default{ state_entry() { talkToClockChan = Key2AppChan("a key", xxx); llListen(talkToClockChan, "", NULL_KEY, ""); } touch_start(integer num) { funcRotateDials(); llOwnerSay((string)llGetUsedMemory()+"b"); } listen(integer c, string n, key id, string m) { time = llParseString2List(m, [":"], []); } } The first two runs of it yielded these results: [07:31:08] clock face: 7800b [07:31:10] clock face: 7740b And then it was stuck on 7740b memory usage with subsequent runs. Moved the code, so now it looked like this: integer talkToClockChan;integer Key2AppChan(key ID, integer App) { // Generates a unique channel per key, with additional app modifier. return 0x80000000 | ((integer)("0x"+(string)ID) ^ App);}list time;integer setup;integer minutehandLink;integer hourhandLink;default{ state_entry() { talkToClockChan = Key2AppChan("a key", xxx); llListen(talkToClockChan, "", NULL_KEY, ""); } touch_start(integer num) { rotation rot; integer i = llGetNumberOfPrims(); integer x; for(;x<=i;x++) { if(llGetLinkName(x) == "minutehand") { minutehandLink = x; } else if(llGetLinkName(x) == "hourhand") { hourhandLink = x; } } rot = (rotation)llList2String(llGetLinkPrimitiveParams(minutehandLink, [PRIM_ROT_LOCAL]), 0); vector rot2 = llRot2Euler(rot); rot2 = <rot2.x,rot2.y,(rot2.z-1)>; rot = llEuler2Rot(rot2); llSetLinkPrimitiveParamsFast(minutehandLink, [PRIM_ROT_LOCAL, rot]); llOwnerSay((string)llGetUsedMemory()+"b"); } listen(integer c, string n, key id, string m) { time = llParseString2List(m, [":"], []); } } The results: [07:31:59] clock face: 7172b [07:32:02] clock face: 7200b It might look small, but roughly 500 bytes is a pretty big improvement imo. This was done in Mono. I'm observing that moving code out of a function & into the events themselves can in fact, noticeably reduce the amount of memory a program uses.

steph Arnott wrote: Functions are alocated what they need, since mono the size located is the same as inline. If the function is called more than once then there is no saving. TYPO Thank you for clarifying that, that's exactly what I meant but apparently was unable to convey. I'm talking about one-off functions.

steph Arnott wrote: Tenaar Feiri wrote: Having a lot of functions can take up memory. As I recall, just defining a function takes up a sizable amount of memory without putting anything in it, so if you can put more code in the executing script, that will help. Lost me on that one. Defined functions take up e very little memory. "Sizable amount of memory" was actually supposed to be in the first sentence. It should read: "Having a lot of functions can take up a sizable amount of memory. As I recall, just defining a function takes up a bit even without putting anything in it, so if you can put more code in the executing script, that will help." I'm running on fumes atm, so I should probably stop posting until I've had some food & some coffee. I'll go make the correction.

Qie Niangao wrote: Tenaar Feiri wrote: You can also use lists to store global variables in than defining each individual one as a global, but I'd be careful with that too. It can help you save space, but depending on what you put in it, it can also increase memory usage! Do we know an example of list storage saving space? It seems quite counter to (my) expectations. Ah, sorry. I just tested it, & I was quite mistaken. Whoops! Scratch that bit then! But either way, the rest of my advice should hold. Concatenate & optimize what one can to save memory.

*edit #2* I should stop posting when I'm unable to concentrate. Fixed another couple of errors in my post. Having a lot of functions can take up a sizable amount of memory. As I recall, just defining a function takes up a bit even without putting anything in it, so if you can put more code in the executing script, that will help. You can also use lists to store global variables in than defining each individual one as a global, but I'd be careful with that too. It can help you save space, but depending on what you put in it, it can also increase memory usage! And using llList2x functions to pull data from the list, and llListReplaceList() to update the values again both use up a bit of CPU power. *edit* Nevermind the strikethrough, I had a brain fart. Most of the time, putting variables in lists do not seem to help memory usage at all. Also try seeing what calls your script is making; perhaps you can concatenate them! If you've got a function that deals with a lot of temporary variables, try putting them all in a single temporary list instead, as that can reduce memory usage. If you're dealing with menus, using a function like list menu(integer int) { if(menu==1){return ["An entry"];} } will use more memory and unnecessary CPU power than just defining that list as a global. My advice would be to concatenate what you can concatenate, trim down any fat & optimize everything that can be optimized. Generally, the less script calls you have to do to do a thing, the better.

This should do what you want: function: integer whichButton (float x, float y){ integer xminx = 1; integer xmaxx = 2; integer yminy = 3; integer ymaxy = 4; integer i = 0; integer b = (llGetListLength(buttons) / 5); for(; i < b; i++) { float xmin = llList2Float(buttons, xminx); float xmax = llList2Float(buttons, xmaxx); float ymin = llList2Float(buttons, yminy); float ymax = llList2Float(buttons, ymaxy); if(x >= xmin && x <= xmax && y >= ymin && y <= ymax) { return (xminx - 1); } xminx += 5; xmaxx += 5; yminy += 5; ymaxy += 5; } return -1;} list: list areas = [ /* area Name x min x max y min y max */ /*0*/ "ar1", 0.232907, 0.770735, 0.049140, 0.211435, //1,2,3,4 /*5*/ "ar2", 0.232983, 0.791216, 0.238534, 0.406825, //6,7,8,9 /*10*/ "ar3", 0.212880, 0.791064, 0.497025, 0.593129, //11,12,13,14 /*15*/ "ar4", 0.232983, 0.791216, 0.614254, 0.779570, //16,17,18,19 /*20*/ "ar5", 0.232983, 0.791216, 0.803625, 0.965874 //21,22,23,24 ]; touch_start(): vector point = llDetectedTouchST(0); integer which = whichButton(point.x, point.y); if(which == -1) { return; } if(which == 0) // ar1 {// Your code here.} All you need to do is find the face coordinates of where you're touching, then insert the values into the appropriate list entry to create a "grid" that, when that area is touched, returns a number. whichButton() will always return numbers in increments of 5. So the grid set up with the coordinates of list entries 0 through 4, they will create an invisible "button" that when clicked, returns 0. Then the subsequent five entries, 5 through 9, will create another "button" that when clicked, returns 5. And so on. Here's the list again so it's easier to see what I mean. list areas = [ /* area Name x min x max y min y max */ /*0*/ "ar1", 0.232907, 0.770735, 0.049140, 0.211435, //1,2,3,4 /*5*/ "ar2", 0.232983, 0.791216, 0.238534, 0.406825, //6,7,8,9 /*10*/ "ar3", 0.212880, 0.791064, 0.497025, 0.593129, //11,12,13,14 /*15*/ "ar4", 0.232983, 0.791216, 0.614254, 0.779570, //16,17,18,19 /*20*/ "ar5", 0.232983, 0.791216, 0.803625, 0.965874 //21,22,23,24 ];

That makes sense. The data's not important enough to justify sending it to my ext. server, but at least I know it's not possible to anticipate the restarts! It's a shame we can't trust the object attributes, really. Or the script memory for that matter; I've had scripts randomly reset themselves whenever someone logs in wearing it, without there being a single reset call in the code to begin with, so I learned not to trust that the hard way. In any case, thanks for answering! Appreciate it!

Hey! The title pretty much asks my question for me, but I'll just go ahead & repeat it here. Can I detect when a sim is *about* to be restarted using LSL? I'm working on a script that deals with some data & saves it to the object description and an invisible llSetText() to make it easier to have it persist through restarts & such. The script saves the data periodically, but I don't want to accidentally lose any of the information it's currently processing if a restart unexpectedly happens in the middle of its workflow. I know scripts generally just 'pause' when the server's down & resume again afterwards but I don't trust LL's servers to reliably retain my script data. Is there a way my script can notice when the server's going to be restarted or brought down, so it can stop its work & save the data so it can safely resume its operation afterwards?

Yeah, I'm sure. For some reason it was still giving me a syntax error, but I copied the same line which was giving the error, then deleted that one & pasted it in again, and that solved it. This language is weird as heck >.> Or it might just be an undocumented bug in the compiler.

Ron Khondji wrote: Like this for instance: Edit: Scratch the below post. Turns out I just had to copy-paste it, delete it from the script & re-add it again. Thank you for that, it looks much cleaner now! There's just one issue with it right now & that shows what I mean with how LSL is difficult & cumbersome to learn x3 There's a syntax error on line 105, but I can't see where it is because that line looks proper. It involves this: if (!safe) llSensorRepeat("","",AGENT_BY_LEGACY_NAME,5.0,PI,2.0);

dd Temin wrote: Hi, I have 2 suggestions... 1. Why not just do a random number "coin flip" any time an avatar is detected within 5 meters.......to decide if you need particles or not. (safe or unsafe) 2. You will be able to write much simpler more efficient scripts..if you learn how to script without using state changes. You will be suprised at how much easier your scripts can be.. Hi! I need the particle spitter to consistently spit particles at everyone who comes within range for the 4 hours it's in "unsafe mode", so having it do a random coin flip ever time it detects an agent within range would defeat its purpose, really. I do agree I should learn how to script without using state changes as well. LSL is just a very difficult and cumbersome language to learn :<