Akninirith

One more time: a simple scripting summary of what I've done to get this thing to work: A) Some major functions - specifically, one that confirmed whether a move is valid for a player to make, and another that checked where pieces were in relation to each other - were consolidated into a single, multiuse function that had slightly more overhead than either, but eliminated an enormous amount of bytecode and appears to have impacted the memory use positively with compounding returns. B) ALL functions that were user-defined were cannibalized and sewn into the script to make the flow run more in-line; on the few occasions where enormous bits of code would have to be re-copied exactly otherwise, GOTO lines were implemented instead with boolean ints as guidance rails pointing to where execution left off. C) A critical eye was cast over the split points for the different scripts. After some deliberation, a single fairly memory-intensive function that helps the board to reset after restarting was segregated into its own script, while the two big chunk scripts that were both trying to maintain the game logic were recombined after memory use shrank enough to allow for the merge. So in summary, what I've learned here is: when dealing with extremely large functions spanning several hundred lines that need to be executed more than once, if it is at all possible, one ought to prioritize finding a way to combine them even if they have slightly different return values or parameters, and snag only the information needed from the larger amount of information they return. Also, be VERY careful with where scripts are split, since a poor choice for dividing a script into multiple parts can easily set the whole project back painfully large segments at a time later on. Again, all help has been appreciated. I think I have a handle on the problems from here on in. Godspeed, SL, and may all your Christmases be merry. - Akninirith Resident

Update on the scripting process: inlining DOES help. The trouble is: in this case, the sheer amount of bytecode that was generated by moving functions into an inline format expanded memory usage enough to cause a stack-heap collision later down the line than previously. Fortunately, another split of the scripts was easier than expected and seems to have solved the issue for the time being - relegating simple, memory-munching tasks seems to take the edge off in a big way. Will further update if finished product seems stable along with simple description of process.

Alright, sorry in the belated reply - there were some... interesting hold-ups on the way. One being a lack of Internet connection over a 5-day period. It seems that inlining the script HAS brought most of the mid-script memory consumption down somewhat, but unfortunately the bytecode's size increase appears to have almost nullified the gains in memory overall. I have yet to really see the script inclined to release more memory over its operation, but I will post here the instant the inlining job seems to have had an unambiguously positive effect. For now, there is some ambiguity on a number of levels, and I think I will be trying for one more split involving the list representing the game board (probably the most significant memory hog), its accessors and modifiers, and a couple of other specifically list-related knickknacks getting made into a third script. Will use llSleep in the script that used to take care of the stuff related to said list along with linked messages to make a "partly" asynchronous model-view-controller design, instead of the weird mashup of model-controller and separate view that I currently have. Not sure how well llSleep in tandem with waiting for llMessageLinked calls will work, haven't tried it yet. Will also elucidate on the above if necessary - brain at about 65% descriptive function capacity at the moment. Kudos to Lep are in order. Thanks and all that jazz.

Lepre, I appreciate the continued feedback; I will test the code after inclining it, though I am not sure of how much it will improve the memory use. Will re-post here after with results.

Lepre, I will reexamine the usage of memory a little more on the "official" version of the board (there are 2, one pretty much as it should be in the finalized stage, the other allowing willy-nilly piece placement/movement) but there are some other things I probably should have added. First, there are currently 2 scripts in this project, as I already had to deal with stack-heap collisions with the board when my single-script endeavor reached the 1200 line watermark. For the record, I estimate the total number of non-commented lines of code to be between 1500 and 1700 at the moment. Splitting further is possible, but I would like to avoid it unless strictly necessary. Second, while I am aware that llGetFreeMemory does return a "high watermark" of memory used, I have also noticed that in the larger version of the board, where I first noticed the error, there is a deficit of about 4k reported by llGFM on starting the board up. By moving pieces one at a time, that number decreases with most, though not all, position changes. At the exact point where (I presume, anyway, ~30 bytes left at this point) a routine would cause llGFM to return 0, the script dies and I get the wonderful window of undebugginghappiness reporting the stack's train wreck with the heap. This leads me to believe that in this instance llGFM is accurate. Also: I am not actually adding to the size of any lists; while I am modifying them like no tomorrow, and in several places use what is basically a modified call to llListReplaceList or reconstruct a lengthy string by using llList2String() 6 times in succession on a line, I don't increase the size of the list, so it shouldn't be resulting in extra memory being needed in the first place... I think.

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.

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). 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.

I am a scripter helping a small designer team to get a product out in the market with some legal concerns. While I am terribly concerned about my work being taken for granted, and I do trust the party I am working with to a fair extent, is there some standard way of writing up contracts or forming legal agreements addressing payments? I just want to make certain that I can claim some compensation for my work in the form of a "slice of the pie" - if such a thing can be legally pursued in SL - or, if that is not something that can be moderated, a single sum on finishing the coding. If there is anyone out there with any experience in this field on SL, my ears are wide open. Thank you!

I apologize for the gross amount of time I took in replying; I greatly appreciate the feedback, and am sorry for misplacing this post for as long as I did. Thank you very much! EDIT: For those interested, installing the most recent software was what I SHOULD have done at the beginning. Oh, the small things...

As a VERY new Resident to the world of the sales pitch, I have a concrete, though certainly not groundbreaking, idea bucket for creating tools to help people with coding, building, planning, etc., and provide various utilities. I've heard about certain groups being very good at pointing coders in the right direction or even taking them under a wing in some cases, but I would be perfectly happy if I could learn whether there is some place I could talk to "guinea pigs" willing to give me a thumbs-up/thumbs-down in quality assurance? Thank you kindly!

Alternately, one could do this kind of thing with states, since they are well suited for this kind of "switcheroo" functionality: Make one state for each set of lights you want on, then change between them each time you say a phrase. I certainly hope you find a decent solution, but if the problem doesn't look like it will have a fix any time soon, I'd be willing to take a stab at it.

Though you ARE talking about a listening script, it might be possible to make a similar script using the UUIDs of the keys. The script could have a list of the four keys' UUIDs and an integer - say, keys_still_needed_count = 4 - and run a sensor every ~10 seconds or so. When any keys are in range during a sensor scan, the script would check them against its list and decrease the count by the number of keys it finds. Then, if the count ever drops to 0, you know you've got all the keys in the range. This option would probably take some more time to implement than listening for phrases, but it would be more secure, since UUIDs can't be "faked" like messages.

I believe that SHA1 has also been recently compromised - not BROKEN, but an algorithm found that can give a string that will be converted to a known hash made with SHA1. Do not remember where I read this, so take it with as much, er, salt as deemed appropriate. I don't know when/if Linden Labs intends to add support for it, but SHA3 is apparently a far more secure animal than its older cousin.

Hello, fellow Residents, I was wondering whether anyone would know of a way to directly embed the needed code for playing videos off of YouTube in a prim. As far as I understand the issue, there doesn't seem to be a way of doing this, since LSL doesn't understand JavaScript. If I'm correct, there is also no expedient way to modify a prim's ability to display media to include Flash capability. Any information on how to set up a click-and-play type YouTube viewer? Thanks!