Quistess Alpha

Did you try rotating the root to a 'crazy' orientation to see if it breaks? in the specific case where the root is at ZERO_ROTATION, the 'fix' of dividing through by the root's rotation, is just dividing by 1, which does nothing. or, in simpler terms, if the root has zero rotation, then the global reference frame and local reference frame are the same, and no 'translation' is required to make child prims 'do the right thing'.

I ~might splurge for that one, "Annie Ante" or something might be cute. . . ETA: or "No Dice" could be fun!

because PRIM_ROTATION is borked for child prims and it's been a known "won't fix" error forever. and for completeness, the way I would do it: // I should really thread these 2 functions together and use llAxisAngle2Rot instead of direct sin/cos, but I'm lazy. rotation YPR2Rot(vector v) // Yaw Pitch Roll { return <llSin(v.z/2),0,0,llCos(v.z/2)> * <0,llSin(v.y/2),0,llCos(v.y/2)> * <0,0,llSin(v.x/2),llCos(v.x/2)> ; } rotation uVectorRoll2Rot(vector v,float r) { return YPR2Rot(<llAtan2(v.y,v.x),-llAtan2(v.z,llVecMag(<v.x,v.y,0>)),r>); } Turn_link_towards(vector pos, integer link) { vector target= pos-llGetPos(); // assume the offset of the prim from the root is neglidgeable, or account for it here. rotation rot = uVectorRoll2Rot(target,0); llSetLinkPrimitiveParamsFast(link,[PRIM_ROT_LOCAL,rot/llGetRootRotation()]); } // mostly same follower script: default { state_entry() { llSensorRepeat("", "", AGENT, 96.0, PI,1.0); } sensor(integer num_detected) { Turn_link_towards(llDetectedPos(0),2); } } (untested) I would do the linknumber search only once and store in global variables, but I find linkfinding code obnoxious to write, and not really the topic here.

You can, but there are some subtle gotchas. Unless you're absolutely sure your list is non-empty, it's a bit safer to start at -length-1 and immediately increment back in the while check, or use an explicit for loop. // method A: list l; integer index = -llGetListLength(l) -1; while(++index) { /*...*/ } // method B: for(index= -llGetListLength(l); index; ++index) { /*...*/ }

It's actually single-threaded, unless you consider each independent script a different "thread".

Since LSL doesn't have complex classes and such, and because memory limits make programs program size a good deal smaller than other languages, what kind of documentation do you really need? with LSD, adding some extra comments about which keys are used where could be useful, and information about channel protocols could be helpful for allowing "plugins" to interface with other scripts, but I don't really see the benefit of generating that kind of info "automatically".

Oh yeah, much cleaner than parseString2List with the "search" as a separator then dumpList2String with "replace" as the separator! Still doesn't help with double replacement though. (Fixing "Roses are blue, violets are red." takes 3 replace operations)

I missed or forgot about the new list functions. It's nice to have a good overview of all the changes!

indeed, in LSL declaring a variable in the for statement is forbidden, so using the initializer of the for loop is somewhat rare. a LSL idiom I use often is to iterate through a list backwards with a while loop: list myList = [1,2,3,4,5,6,7,8,9,10]; integer index = llGetListLength(myList); string ret; while(~--index) // for(;index!=-1;--index) { integer val = llList2Integer(myList,index); if(val&1) myList = llDeleteSubList(myList,index,index); // remove from list if odd. ret += (string)index + ": "+llList2CSV(myList)+"\n"; } llOwnerSay(ret); for example to (very verbosely) remove odd numbers from a list.

llRegionSayTo(IdOfAvatar,0,"My message"); 0 is the channel that people see in local chat, all the other channels are for script stuff.

just for sake of completion, llGetObjectDetails(id,[OBJECT_ROOT]); can be used to determine if an avatar is sitting on something as well. (but doesn't detect ground sits obviously)

Making things move in general requires a lot of specific knowledge about the build*, and can even be impossible if the build wasn't designed for it. *E.g. are the wings separate meshes? if so, where are there centers, and what intrinsic axes do they use? If not, can they be made invisible so you can add moveable prim wings?

integer i; default { touch_start(integer n) { llPlaySound(llGetInventoryName(INVENTORY_SOUND,i=((i+1)%llGetInventoryNumber(INVENTORY_SOUND))), 1.0); } } or perhaps the same but less obtuse

and remember to remove and reset any owner-only listens, and re-set important config values if applicable.

FWIW, this is why it's very useful to put something like changed(integer c) { if(c&CHANGED_OWNER) { llResetScript(); } } in most scripts in things intended to be given to someone else. It also often saves you from passing along 'personal settings' that may have changed from default values.

It's been a while, but in my hazy memory, social island and other 'getting started' areas like firestorm help island have teleporters that take one to generic adult themed places. telling newcomers that adult things exist isn't exactly controversial.

Where is it indicated that it's specifically targeted at children?

Oh eww. another reason to stop using the Goliath; DuckDuckGo just mostly gives back travel sites. (and yes, DDG will give adult video sites if you ask it something where those are more relevant) If ~videos were specifically searched for, I'd argue selection bias: 'normal' video sites wouldn't allow the content.

While that is a side benefit, I'd argue the main selling point is that it's Strictly better than a global JSON string. Being able to associate restriction-> restrictor and being able to iterate over all restrictions, is more efficient than say, having an individual list for each restrictor, then needing to iterate over every other restrictor to check if that RLV was also applied by something else when removing a restriction. I'll probably post an updated script after making some minor changes, and reasonable testing, but on my todo list: @clear needs to translate to !release somewhere in the interpretation pipeline. I'm a bit torn whether to do it early or wait until right before it fails the 'has an = sign' check, or perhaps change the detection of meta-commands to 'lacks a =' rather than 'starts with a !'. Associate restriction messages with the root prim of their linkset. One object shouldn't be able to take up multiple slots. More of a 'fun' change: add an 'AFK Vulnerable' mode which if active, accepts any request if there is no @_DOM around, and the wearer has the 'away' status on. (Yes I know 'away' can be turned off and the time is viewer-dependent, but for a voluntary gimmick it's more reasonable than constant dialog boxes) Several debug/error messages are reported using llSay. This is useful for testing when I'm not the one wearing the relay, but I should probably add an option to use llOwnerSay instead to avoid spam.

Yeah I'd have to test it again, because my notes weren't' that great, but from what I recall, with respect to an avatar in the default sit position, changing your shape doesn't actually move your center that much if at all, which good news for chairs, if a specific offset works for one person it should be ~roughly correct for most people.

Back on-topic, I was perusing RLV doc a bit ago an came across an interesting old old thread: http://sldev.free.fr/forum/viewtopic.php?f=7&t=447 we also have the (Extremely unhelpfully named, took me forever to find it) new function llGetVisualParams() which might be helpful, It seems I made a test of it when it was newly released for sit-posiitoning, but my main observation was that: "Well placed sitting depends a lot on body fat, which is not an observable parameter." Your mileage may vary, and it might be more useful if it's for someone standing?

A) Can't quite test it at the moment, but key ID = llAvatarOnLinkSitTarget(3); // if link #3 has a defined sit target, and an avatar is sitting on that link, return that avatar's ID. if(ID) { integer link = llList2Integer(llGetObjectDetails(ID,[OBJECT_LINK_NUMBER]),0); // what link number are they in the link set? } seems like about the intended usage. B) an AO has other methods of testing if their wearer is sitting, specifically: key root = llList2Key(llGetObjectDetails(llGetOwner(),[OBJECT_ROOT]),0); if(root!=llGetOwner()) { // owner==wearer is sitting on an object, is the object scripted? if(llList2Integer(llGetObjectDetails(root,[OBJECT_RUNNING_SCRIPT_COUNT]),0)) { // wearer is sitting on a scripted thing, turn off AO. }else { // wearer is sitting on a non-scripted thing. } }else { // owner==wearer is not sitting, turn on AO. }

https://wiki.secondlife.com/wiki/LlGetObjectDetails it's 46 FWIW. Mostly does what you would expect it to given the name. It's would be better as a separate function IMO, but we take what we get. A lot of (increasingly less) recent changes to multi-functions are less well documented than they could be.

Depending on the intention of the build, llAvatarOnLinkSitTarget() (along with PRIM_SCRIPTED_SIT_ONLY on non-seats) can be very useful, because it lets you define specific "spots" for sitting based on where the avatar clicked to sit rather than order. If done in a well thought out manner, you could for example, have a single-script bus, with several passenger seats and a driver's seat, and the driver could stand up and sit down at any point while other people are sitting and still remain the driver without pushing other sitters around as long as they sit on the prim/mesh representing the driver's seat. Passengers can change seats by standing and re-sitting on the specific seat they want rather than using an obtuse menu. etc. OTOH for something like a "couch" that would b a very obnoxious and unintuitive way of doing things. You probably don't want to stand up and sit on a different cushion for every other pose. So, normally makes the most sense for things with several different single-person spots that don't interact with each other too much, although you could also maybe group seats in pairs or something with a lot of script work. We have OBJECT_LINK_NUMBER now; Huzzah!

you can edit yours or something, I don't particularly mind, or care much about accreditation.