Quistess Alpha

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

I'm a little bit confused by your implementation format for LSD. In non-LSD you have uncorrelated lists, in LSD you have group IDs and AV ids grouped in pairs in the LSD? why not just treat AV IDs and Group IDs identically? There's very little chance of a collision Also, I would store the block or allowed in the value of the LSD: // LSD keys of the form "Acc:"+UUID. key avId; key grId; string val; if(val=llLinksetDataRead("Acc:"+avId)) { if("allowed"!=val) { return FALSE; } } if(val=llLinksetDataRead("Acc:"+grId)) { if("allowed"==val); { return TRUE; }else { return FALSE; } } return FALSE; // or so; there are 9 cases to check, and I'm too lazy to set up a truth table for the implementation in the OP.

Facebook?

This is a resident to resident discussion forum, for direct support you'll need to contact Linden Lab with a support ticket here: https://lindenlab.freshdesk.com/support/home Since you're paid premium, they might be able to verify that you are who you say you are with your payment information somehow.

if(!pointer--) { //0 }else if(!pointer--) { //1 }//... else { // was probably -1 all along. } might be more practical.

At the moment I'm using it to define a menu structure, to make my menuing system easier to maintain. Sure, other storage methods are more efficient, but are you really going to remember the exact ordering of a CSV list specification when you want to edit the script a year from now?

string json = "{\"a\":\"a\", \"b\":\"b\"}"; json = llJsonSetValue(json,["c"],JSON_DELETE); llOwnerSay(json); // JSON_INVALID. Attempting to delete a non-existent key in a JSON object deletes the whole JSON object. Expected behavior?

Probably unnecessary unless The ranges are semantically helpful (for example, testing HTTP return codes, grouping 400's together makes sense) Some snippet can be 'factored out' of like categories You have hundreds, not handfuls of tests. (in most cases you're probably doing something wrong if you need that many conditionals) also, for range checks, you only need to check one direction: