LepreKhaun

As a matter of fact, I always go out with an umbrella. But that's only because I've lived in New Orleans as long as I have and I've learned. And the key word there is learned.

revochen Mayne wrote: Qie Niangao wrote: This is a pretty fun thread. Hey! This is serious as can be! :matte-motes-wink-tongue: Qie Niangao wrote: I'd just add that llSLPPF has a built-in disadvantage in that it takes a list argument, so the script spends time consing up that list to pass it to the function, whereas llSetTest is passed atomic, non-list arguments. Yes that sounds logical but just take a look at the wiki what it sais about llSLPPF: "This function is identical to llSetLinkPrimitiveParams except without the delay." But this doesnt seems to be true as there is a delay anyway and scripters shall be aware of as it might improves their scripts when they avoid trying to update text a few thousend times each second. :matte-motes-nerdy: :matte-motes-wink-tongue: OK, If you had used llSetLinkPrimitiveParams in your original test, it would've taken your code a bit over three and a half hours to complete. Why? Because that function call has a 0.2s delay built into it and you simply cannot call it more than 5 times a second. Don't take my word for this, try your experiment using that function yourself and go take a long lunch. Now, the result obtained of having llSetLinkPrimitiveParamsFast is directly because it does not have that delay or throttle as it's called. That's all the wiki said, right? "This function is identical to llSetLinkPrimitiveParams except without the delay." Did you expect it to take no time at all? Did you expect it to be faster than a function that does nothing else but one thing for the prim it sits within? What, exactly, did you expect?

Thank you for a simply epic thread. It'll be awhile before this one is topped.

I'll to leave it up to you to try to explain how viewer updates work. Good luck!

CashRules wrote: also should I uv map each part? or join them as one mesh? Yes, you should always uv map your mesh. If you don't, SL will do it for you in a way you'll probably not like and your textures will most likely come out wonky. In fact, many mesh creators spend more time getting their uv mapping "just so" than they do making the model itself. As far as joining, I would make the room and the table two entirely different mesh objects. That way the table could be repositioned and, possibly, used in another build later. BTW, I like the look of your model a lot! Why wait to start trying it out inworld? You can use the beta or preview grid (https://wiki.secondlife.com/wiki/Preview_Grid) to test it for free as many times as you wish. You'll find that it's appearance in SL won't quite be what you're seeing in Blender and the earlier you notice these differences, the easier they'll be to change.

Ela Talaj wrote: Something doesn't compute here Have you tried in a different sim? I didn't count iterations in your loop, don't have time for that, but there is no way a loop with llSetLinkPrimitiveParamsFast() would run for about 100 seconds with thousands of iterations. That would've been a showstopper long time ago. mmm, computing 1/(255*255/100) works out to be about 0.0015s per iteration, which seems about right considering a script is only running within its time slice of the 1/45th of a second pie all scripts within a sim must share and the amount of floating point operations being done as well within that loop. Since no one else was around right now (/looks guiltily at mini-map); I ran the tests in my mainland region and obtained: [23:59] Object: water count:55398 land count:8051 hill count:2343 call time:5.243556s Using llSetText: [00:02] Object: water count:55398 land count:8051 hill count:2343 call time:29.171460s Using llSetLinkPrimitiveParamsFast: [00:06] Object: water count:55398 land count:8051 hill count:2343 call time:119.814300 All which is consistent with the OP's observation on a homestead sim and, really, falls under "expected behavior". The "Fast" in llSetLinkPrimitiveParamsFast is merely there to distinguish it from llSetLinkPrimitiveParams, which has a 0.2s throttle built into it. It cannot be expected to perform faster than a library function with a much tighter calling set and which isn't having to do any comparisons on what it's to change and on which prim the change is to be made.

Foetwenty wrote: And im still searching, im not stopping just because i posted... But im getting a huge headach... I have blender open and im just searching through the different blender tuts... "Press thsi key to do this" -Presses the key- (Totally different operation)... > Goes to next video... Do (not look at the videos, but DO) the first six lessons at http://www.gryllus.net/Blender/3D.html . It took me two weeks, full time, but have never regretted it.

1: Which *current* viewer is best to use for modeling? The main consideration here is what works best for you. Just be certain you are using a current viewer, SL has made some changes lately. 2: Which *current* modeler is better for the current SL? I'd say Blender, because many of the people on its development team are activally involved in SL and and what were once plugins made specifically for SL content creation are now a part of the program. Price is right, too. 3: How can i get my shape into any of the modelers, without having to spend 3 hours copying down numbers and completely recreating my shape? There's Avastar for Blender http://blog.machinimatrix.org/avastar/ (where, btw, you'll find many excellent tutorials along the lines of what you're asking within http://blog.machinimatrix.org/category/mesh/). 3b: If i was to do custom work for a friend/customer/random person, how would i get their shape? They would have to follow the instructions in that above link and then give you the xml file. You can't otherwise access it directly. 4: Where is a good list of addons for any of the *current* modelers? Google "blender plugins", try what seems might be worthwhile, there's hundreds of them. 5: Where could i find a list of *current* tutorials that explain how to build/mod in the *current* SL enviroment? http://www.buildersbrewery.com/

np, we're all human (or neko, or furry, or ... :smileytongue:). To the OP and any beginning coders, study http://lslwiki.net/lslwiki/wakka.php?wakka=debugging to get a handle on LSL's (usually) cryptic messages one will encounter when trying to save their efforts. It gives a good starting point on what may be wrong with your code and what may need corrected.

Heather Moonwing wrote: Ok, thank you very much for your help. Getting a syntax error at the if (~idx) part, but I think I'm beginning to understand. Thank you so much for your help. Add the missing semi-colon ( ; ) to the end of the line in Rolig's code that reads: integer idx = llListFindList(ShortNames,[msg])

And, of course, if you're feeling very ambitious, you could create (the much needed) http://lslwiki.net/lslwiki/wakka.php?wakka=llSetLinkPrimitiveParamsFast . :smileywink:

Look at it this way- 4.6s without changing a prim property, 6 times longer to change a prim property with a LSL function that handles one specific prim property and 4 times longer still when you call the "change any/everything" prim property function (which is having to sort out which prim property(s) [ETA and for which prim(s)] you're changing). Just be grateful we no longer have to deal with a 0.2 second delay with that catchall function anymore.

You can speed up everything 16x by taking your measurements every 4 meters, which is how they are set you know.

steph Arnott wrote: A do while counter will do what you want, It will count while it is true, when it reaches the target count it will become false and end. Have added this to give you an idea. //Counts from 1 to 5 default { state_entry() { integer olf; // Without applied value an integer will be defaulted to zero. do llSay(0, (string) ++olf); // Increment before the while condition while (olf < 5); // On the first pass/loop olf = 1 } } It might be noted that there are some code examples in the wiki that will not compile and this was one of them. Example now corrected to read llSay(0, (string) (++olf)); at https://wiki.secondlife.com/wiki/Do_while . [ETA: A thank-you to Steph for drawing our attention to the error. Our wiki is only as good as we make it.]

Studying http://lslwiki.net/lslwiki/wakka.php?wakka=memory will help a lot to understand what is causing your problem and gaining a better insight into it will show you possible solutions. One possibility may be simply shortening the size of your lists. Not the number of elements, mind you, but the length of each element contributes to the size of the list. For instance, if you're using human readable strings like "Black Queen Knight" you could gain a tremendous savings in memory by using "x" and making a comment to the effect that anytime "x" is encountered in the list, it is to be interpreted as "Black Queen Knight". This sort of compaction does affect the readability of your code and may slow the development process, requiring you to stop at times to look up what "x" might actually be representing, but will open up a lot of memory for your program to work within. Another possibility is serializing your lists, making them into strings. The above link makes mention of using CSV (http://lslwiki.net/lslwiki/wakka.php?wakka=CSV) for this compaction but we now have an even better (imo) method available, json strings (https://wiki.secondlife.com/wiki/Json_usage_in_LSL), where your list is serialized into a string using JSON_ARRAY. But, if you managed to do the previous suggestion of getting your list entries down to one character each, you could even go with a simple string and use the llString* functions for your data manipulations (which parallel, somewhat, the manipulations one has for lists). A, somewhat extreme, solution may be to compact your entire script. This is a pre-compile step that really makes your code unreadable so it should only be used once you have working code that is ready to go. But it will make your code memory footprint smaller. My favorite compacter for this is Wizardry and Steamworks' minify program http://was.fm/secondlife:minify and I can personally say it will save memory, though the mileage will vary according to the program being compacted. [ETA: the link to their working demo is easily missed on that page- it's to be found at http://was.fm/fuss:lsl#minify ]. Anyway, good luck with your project! Do stop back at some point and let us know how it went, even if you finally had to split it into helper scripts, which is sometimes the only solution, no matter how much we hate doing it.

OK, I have a much clearer picture of the problem now and it's not memory leaks but more along the lines of how LSL handles things in general. First of all, LSL does not pass by reference but passes copies of values to functions. What this means, if you use list myList = sortThisList(myList): (where sortThisList is your user function that does just what it says); while within that function call there are in fact TWO lists being held in memory, the original "myList" and the copy of "myList" that is being passed to the function. And, of course, to do the sorting you're having to call various llList* functions, which themselves require their own copies held in memory of whatever list being passed into them. In other words, list processing, if not handled with memory limits in mind, can easily result in stack-heap collisions, but not because of "memory leaks". This happens simple because the programmer isn't allowing for the ballooning memory requirements of their data as it gets passed deeper into function calls. This leads to a counterintuitive coding practice: Instead of writing a function for code that may be used in different parts of a script, it may be better to have that code inlined (written entirely in place) everywhere it's needed. This will, of course, increase your script's byte code size but will decrease (sometimes dramatically so!) the runtime stack size at those code points. Second, LSL lists have, in general, a great deal of memory overhead in their implementation. This memory overhead results from 2 major factors: (1) Having to store the datatype information with the value (this is because one can store mixed datatypes within a list, as opposed to having a list declared to hold [say] only integers) as well as (2) LSL lists are dynamically runtime sizable (meaning they can grow and shrink as needed) which requires allocating the memory for such to begin with to be [usually] twice as much as initially required and then doubling that each time it hits its limit. So, basically, LSL lists are memory hogs in themselves, eating up much more of your precious 64K Mono allotment than you may realize; and then passing them to functions, either your own or those of the Linden Scripting Library, eats up that alloted space very quickly if you're not careful.

Elaborating on Rolig's answer, these are the only parameters (defined as attributes of an object that can be changed by LSL) of an object: https://wiki.secondlife.com/wiki/LlGetObjectDetails. The "for sale price" is an attribute of an object rather than a parameter since you cannot set it nor change it within LSL. Since this attribute can neither be set nor changed within LSL, there is no need for a script to get it. In other words, the value of this is worthless within LSL except to echo what is already being shown in hover tips. If your script really needs to know the selling price of the object it is within or of an object in its contents, simply update the script to reflect the current price in a variable named "mySellingPrice" or, as Rolig suggested, change the object description while keeping in mind the Caveat of https://wiki.secondlife.com/wiki/LlGetPrimitiveParams: 'Note that when people have "Hover Tips on All Objects" selected in the viewer's "View" menu, they'll see the object description pop-up for any object under their mouse pointer'. Either of those options require inworld editing on your part when a price change is made because there is no CHANGED_PRICE flag within a changed() event (for the reasons I gave above).

steph Arnott wrote: For an extra few lines i see no benifit in putting the two together, also you may end up with unreliable script. I just dont see the point of it. As for the confusion of and /or it not hard. && if the right side and the left side are both satisfied do it || if the right side or the left side are satified do it I have no idea of how you define an "unreliable script" but I can assure you that correct coding will never result in such. And though your explanation of logic operators ("&&" and "||") is correct, bitwise operators ("&" and "|") are subtly different in that they don't result in 1 (the value of LSL's constant "TRUE") or 0 (the value of LSL's constant "FALSE") but in non-zero (which is interpretted by LSL as being true) and zero (which is interpretted as false) values.

Akninirith wrote: Alright, here's a tricky one (which may take me a few days to even notice an answer towards): I have spent an enormous amount of time scripting a game board to a functional point, only to now realize that there are memory leaks in several places in the scripts. Due to lists having an abusive relationship with script memory and efficiency, and some cursory debugging, I think I've correctly identified the majority of problem locations as being mostly function calls that use one or more lists as parameters, or deal directly with a very large list used in the script logic. Here's the real problem, though: I've checked, and there is no recursion occurring in the script, yet the memory consumption NEVER decreases. The problem stretches of code don't all 100% consistently increase memory used all the time, but when they do, the available memory gets sucked into a black hole and doesn't get freed up. Ever. I don't think the issue is in garbage collection, since I tried adding an extra state with only a sleep function that is visited between memory-eating function calls, but it didn't help. One of the lines of code (I am certain) that does constantly hurt memory numbers is a one-line function I made with a special call to llListReplaceList (the llfunction takes two lists as parameters). Important other stuff: compiled in Mono, am currently using llGetFreeMemory() to diagnose memory issues, there are no infinite loops. If one is supposed to be deleting instance variables as one goes along, this would be a great time to tell me - I am nearing the end of my rope on this one. Any help at all is enormously appreciated. Thank you. Are you actually getting a "Script run-time error": "Stack-Heap Collision" at times or are you simply noticing that llGetFreeMemory() is not returning a higher value when you expect it to? If you're fretting about the latter, don't. That function has never been known to report the actual free memory available to the program in either LSO or Mono. Look at it as only returning a "high tide mark" more than anything else, especially under Mono (where garbage collection seems to only happen when required). If it's the former and your script is actually crashing, you'll have to do one or more of the following: break your script into two or more parts. rethink your usage of lists. use serialized representations of lists outside of subroutines (user functions). If you actually find evidence of a true memory leak (where memory is not being deallocated properly), you should report it as a bug with example code that shows the error.

Erik Verity wrote: ..., look at his second post - Is it even possible for a CHANGED_OWNER and CHANGED_INVENTORY to occur at the same time? You ask about the line that reads " if(change & (CHANGED_OWNER | CHANGED_INVENTORY))". This is using bitwise operators (http://en.wikipedia.org/wiki/Bitwise_operation), which can be somewhat confusing. The line could be rewritten using logic operators and (in that case) would be equivalent to "if ((change == CHANGED_OWNER) || (change == CHANGED_INVENTORY))". However, since the CHANGED_* constants each have a unique binary bit set (see Flag at https://wiki.secondlife.com/wiki/Changed to see values of these), the (much!) faster bitwise operations are preferred.

So, developing some programs using JSON strings (https://wiki.secondlife.com/wiki/Json_usage_in_LSL) and found a need to check at times to see the structure of it. Came up with this debugging tool. It acts like all JSON pretty printers and outputs to llOwnerSay(). This is NOT a JSON validator, meaning it may well "pretty print" your string even if your strings within it are mal-formed (such as having "\s" within it, which breaks strict JSON compliance). But, it will separate your strings out for visual inspection. It uses recursion A LOT so will likely crash if you have a very large JSON structure. However, it'll have worked it up to a point where you can determine where it hit the stack heap collision, and you simply need to break parts of the JSON string out to continue deeper into it. It expects a link message with the JSON string as the third parameter. The second parameter is used as a "channel ID" (defaults to 75 as written). If this conflicts with your existing link messaging system, I'd expect you should see how to modify the code to suit yourself. [Code edited to correct mishandling of integer and float values within the json struct that had been quoted and should read as strings. Also corrected formatting of Key: Value pairs] //////////////////////////////////////////////////// // JsonPrettyChat.lsl // Version 1.2 by LepreKhaun -- 2013-07-10 // Corrected mishandling of quoted numbers. // Corrected formatting of Key values in json objects. // Version 1.0 Released -- 2013-07-09 // A debugging tool for Json construction // // Usage: Place this stand-alone script within object containing program // you wish to debug and address it with // llMessageLinked ( integer LINK_SET, integer MESSAGE_CHANNEL, string jsonString2PrettyChat, key NULL_KEY ); // at the point(s) you wish to review the JSON string. //////////////////////////////////////////////////// // Used as a "channel ID' for link messages integer MESSAGE_CHANNEL = 75; //How deep we are in the json struct integer LEVEL = 0; // User functions chatThis (string message) { string indent = ""; integer iter = LEVEL; while (iter--){ indent += "\t"; } llOwnerSay (indent + message); } handleValue (string prePend, string value, string apPend) { // JSON Value Type string valueType = llJsonValueType(value, []); if (valueType == JSON_FALSE) { chatThis (prePend + "false" + apPend); } else if (valueType == JSON_TRUE) { chatThis (prePend + "true" + apPend); } else if (valueType == JSON_NULL) { chatThis (prePend + "null" + apPend); } else if (valueType == JSON_NUMBER) { chatThis (prePend + value + apPend); } else if (valueType == JSON_ARRAY) { chatThis (prePend + "["); ++LEVEL; handleJsonArray (value); --LEVEL; chatThis ("]" + apPend); } else if (valueType == JSON_OBJECT) { chatThis (prePend + "{"); ++LEVEL; handleJsonObject (value); --LEVEL; chatThis ("}" + apPend); // NOTE: Once back in list form, all strings evaluate to JSON_INVALID // because of having their enclosing double quotes (") stripped, So... } else { // We'll treat it as a String chatThis (prePend + value + apPend); } } handleJsonArray (string jsonArray) { list valueList = llJson2List(jsonArray); integer iter = 0; integer listLength = llGetListLength(valueList); while (iter<listLength) { string value = llList2String(valueList, iter); if (llJsonValueType(jsonArray,[iter])== JSON_STRING) value = "\"" + value + "\""; if (++iter == listLength) handleValue ("", value, ""); else handleValue ("", value, ","); } } handleJsonObject (string jsonObject) { list valueList = llJson2List(jsonObject); integer iter = 0; integer listLength = llGetListLength(valueList); while (iter<listLength) { string myKey = llList2String(valueList, iter); string value = llList2String(valueList, ++iter); if (llJsonValueType(jsonObject,[myKey])== JSON_STRING) value = "\"" + value + "\""; myKey = "\"" + myKey + "\": "; if (++iter == listLength) handleValue (myKey, value, ""); else handleValue (myKey, value, ","); } } // Main Program default { state_entry() { llOwnerSay ("Hello, " + llKey2Name(llGetOwner())); llOwnerSay ("Json Pretty Chat awaits your JSON string"); llOwnerSay ("Use " + (string)MESSAGE_CHANNEL + " for the second paramater of"); llOwnerSay ("llMessageLinked\(\) and supply your JSON string in the third."); } link_message(integer sender_number, integer number, string message, key id) { if (number == MESSAGE_CHANNEL) { llOwnerSay("Pretty Chat of: " + message); handleValue("", message, ""); } } } Harness program, showing usage: default { state_entry() { llOwnerSay("Hello, Avatar!"); } touch_start(integer total_number) { string source; source = llList2Json(JSON_ARRAY, ["x", 1, JSON_TRUE]); source = llList2Json(JSON_OBJECT, ["x",source,"Y",JSON_FALSE]); llMessageLinked (LINK_THIS, 75, source, NULL_KEY); } }Outputs: Object: Hello, LepreKhaun Resident Object: Json Pretty Chat is waiting for your JSON string Object: Use 75 for the second paramater of Object: llMessageLinked() and supply your JSON string in the third. // Harness program checking in. Object: Hello, Avatar! // Result of touch_start() Object: Pretty Chat of: {"x":["x",1,true],"Y":false} Object: { Object: "x": [ Object: "x", Object: 1, Object: true Object: ], Object: "Y": false Object: } As always, comments, suggestions and constructive critism is welcomed.

You can import a sculpt map into Blender-2.59 (or newer) using the Primstar-2 plug in from http://blog.machinimatrix.org/primstar-2/, where you'll also find a lot of tutorials in the documentation.

That looks like an error that I've had happen with both the UV and model editor windows open at the same time. It happened because the cursor pointer was in the wrong window when doing (say) a merge vertices command. Though I had only two vertices selected in the window I was (well, thought I was) working in, because I had drifted my cursor into the other window after making the selection, the merge was applied in the wrong window (where I might still have 20 vertices selected at the time for another reason).

I just wanted to say; A well-asked question sometimes deserves a "KUDO" more than a poorly-answered one (and, god knows, there be a lot of those lately). Your participation in the forums is appreciated.

"Viewing" SL and "taking snaps of" SL are two different things. As I pointed out in http://community.secondlife.com/t5/Art-Music-and-Photography/Bracketed-photos/td-p/2069433, the viewer deals with the updates of the SL "world" as well as it can handle it. The SL world is going to update itself (ideally) 45 times a second, regardless of whether your viewer is keeping up or not. If your specific viewer has a limitation on how it will display each frame (such as only in BW by stripping out all color information), it is welcome to do so. If the added overhead in doing it that way is undesirable, one has the option of completely reducing their system's showing of color to be BW (NOT recommended btw!). If you are simply wanting to know how to process snapshots w/o any outside programs (such as changing a color picture to sepia-toned), then you are asking the wrong question. Outside programs exist to do these transformations, just as they handle RL photographs To actually view and interact w/in SL in a "Sepia Tone as I've defined it" would contribute to client-side lag to the point of reducing the SL experience to comic book frames whenever your computer managed to get through the calculations of updating a past frame. Bottom line, take your shot and frame it as well as you can, then take it into your favorite photo-processing program to make it what you envision. Just like in Real Life.