Quistess Alpha

For splitting a track into multiple 10-second wav files sox -r 44100 -b 16 $1 $2 trim 0 10 : newfile : restart Where $1 is the name of the file to split and $2 is a filename to output to. (specifying 'out.wav' for $2 results in 'out001.wav, out002.wav ...')

You need to have your object in an orientation that the script expects. You can correct for it in the script, by multiplying the rotation of the object by a correction factor, but by far the easiest solution is to just have an invisible prim be the root of the object, and then rotate the owl (or whatever else the script is supposed to move around) with respect to the invisible root such that it "looks right".

5. Does the script use recursion (Ex. recursion(integer n){ /*...*/ return recursion(n-1)} ) ? If so, is there a reasonable limit on the recursion depth?

https://jira.secondlife.com/browse/BUG-232800 "unactionable"

If you don't use one of the 'over' RLV commands, it works like if you 'add' instead of 'wear' something from your inventory: things on the same attachment point can be pushed off. If that's the issue, rename the folder to have a '+' at the front of it in the script and the actual folder, or use @attachover / @attachallover

No, pardon my accidental injection of similar names. and FWIW the documentation I use is on the wiki: LSL Protocol/RestrainedLoveAPI - Second Life Wiki (and for relay reference) LSL Protocol/Restrained Love Relay/Specification - Second Life Wiki

Not especially relevant in this specific case, but multiple sequential RLV commands can be strung together with commas, for example: llOwnerSay("@attach:swapitems/adult=force,detach:swapitems/moderate=force,detach:swapitems/pg=force"); Also, to avoid some possibly unexpected behavior related to attachment points, and recursively attach sub folders, 'attachallover' and 'detachallover' are probably preferable to attach and detach. Given the susceptibility of rigged attachments to slow attach/detach times, it might make sense to consider the attach/detach order depending on what's in the folders and where you're landing (If you're going to a PG area, adding conservative clothes before removing revealing ones might make sense to avoid a few moments of nudity. OTOH, not-pg-safe attachments ought be removed as fast as possible)

It's more efficient in this case than a timer loop.

Use mono, always, for everything. lsl2 is old and bad and LL are considering discontinuing it eventually(^tm). llSetMemoryLimit makes your script look better to certain script detectors, but does nothing to actually decrease resource usage, except crash your script if it does use more than the limit you set of memory. If your system has more than one script, llSetScriptState("Other_script",FALSE); can potentially be nice though.

Thinking about it in the abstract made me wonder if it works in llGetLinkPrimitiveParams, and apparently it does! list l = llGetLinkPrimitiveParams(2,[PRIM_POS_LOCAL,PRIM_LINK_TARGET,3,PRIM_POS_LOCAL]); vector posA = llList2Vector(l,0); // local posiiton of link 2. vector posB = llList2Vector(l,1); // local position of link 3.

If your scripts are in objects rezzed in-world, you may need to pull them into your inventory before editing them. (It's usually only a problem with objects owned by other people though.)

Results for every pancake except coffee is what I'm seeing. ETA: "Coffee" "Pancake" gets her in the top 5 results though.

"Coffee Pancake" -> No results.

~--index doesn't depend on negative indexes, although looping backwards is "interesting" in some cases (not this one I don't think) Otherwise, interesting strategy. If it were me though, I'd probably write a CSV list of inventory items to the key of the regex that they match. Also at te scale where these sorts of acrobatics become a reasonable thing to do (rather than say, a manually curated list of category+item read from the notecard) the most likely case to handle is one or two items being added or removed from inventory at a time. It'd be better to try and optimize for the differential case rather than building the indexing from scratch after any change.

Maybe it changed recently or I'm bad at using the site, but I can't find you specifically on said site. Nor myself, but yes my main alt, who had one of the bots pop in right next to her in a 192 sqm skybox a few months ago.

I think I got from @animats that you can force the garbage collection by (ab)using llSetMemoryLimit() (add and sub 1 from the limit)

It can be set to different textures, so if someone felt like making several textures for moon-states between full and new, a script (with sufficient permissions) could set the moon texture once per day.

It would only have an influence if you actually plugged that into the llSetLinkPrimitiveParamsFast command. In the code above, only your unmodified offset is passed as an argument. Also, you need the local position of the actual prim you're moving, not the local position of the prim the script is running in. ETA: because I was bored: open(float amount) { vector posA = llList2Vector(llGetLinkPrimitiveParams(2,[PRIM_POS_LOCAL]),0); // local posiiton of prim A. vector posB = llList2Vector(llGetLinkPrimitiveParams(3,[PRIM_POS_LOCAL]),0); // local position of prim B. posA.y+=amount; posB.y-=amount; llSetLinkPrimitiveParamsFast(2,[PRIM_POS_LOCAL,posA,PRIM_LINK_TARGET,3,PRIM_POS_LOCAL,posB]); } or so works.

You can't have event handlers in functions, it doesn't work that way. integer gListenMode; string responseA; string responseB; integer gHandleListen; inteegr gChan = -17; default { state_entry() { gHandleListen = llListen(gChan,"","",""); llListenControl(gHandleListen,FALSE); } timer() { llSetTimerEvent(0.0); llSay(0,"Timed out. Please respond faster."); llListenControl(gHandleListen,FALSE); } touch_start(integer n) { llTextbox(llDetectedKey(0),"Please type response A:",gChan); gListenMode=0; llListenControl(gHandleListen,TRUE); llSetTimerEvent(60.0); } listen(integer chan, string name, key ID, string text) { if(0==gListenMode) { responseA = text; llTextbox(ID,"Please type response B:",gChan); gListenMode=1; llSetTimerEvent(60.0); }else if(1==gListenMode) { responseB = text; // Do something intelligent with the responses here: llSay(0,"\nReponse A: "+responseA+"\nResponseB: "+responseB); // clean up listener: llListenControl(gHandleListen,FALSE); llSetTimerEvent(0.0); } } } // UNTESTED! Seems more in line with what you're after?

Root or region depending on a slew of fiddly caveats.

Thanks!

I've never heard of them and I'm not finding them in search, anyone have an address? ETA: Apparently it's called Sinse with an 's': http://maps.secondlife.com/secondlife/sinse/127/84/27

I usually put large blocks of code into quote blocks if I remember to (you don't have to quote someone specific to make a quote thing).

I've only tried the llSetEnvironmentParams direction, but the SKY_SUN parameter is indeed the position of the sun. You should be able to pull out the azimuth and elevation with something like rotation skySun; vector v = llRot2Fwd(skySun); float azimuth = llAtan2(v.y,v.x); float elevation = -llAtan2(v.z,llVecMag(<v.x,v.y,0>)); // UNTESTED!

I haven't tried it, but my back-of-the envelope calculation says you could fit about 3120 keys if they were compressed using base 95 (20 bytes per key + 1 for an unused value) or ~700 more than Molly's method. If you could get rid of the value, that'd only give you another ~100 keys. theoretically true, but in order to leverage existing base64 functions in LSL in the most obvious way, you have to encode in 32 bit -> 6 character blocks (*4 ints in a key = 24 characters). I might see if I can get the byteshifting to work it down to 20+1.5 next I have some free time though. ETA: Actually I think that's basically what you said in your last sentence after I parsed it a few times...