KT Kingsley

The call to llAttachToAvatar in the OP's script is superfluous: the object is already attached. You just need to test the group using Wulfie's code and then have the object detach itself if it doesn't match. Also, the call to llDetachFromAvatar will itself trigger the attach event, so it may be best to test whether the event has been triggered by the object being attached, when the key id will be the owner's (wearer's) or NULL_KEY if it's being detached, in which case you should ignore the event. It gets worse: in order to use llDetachFromAvatar, the script first needs to get permission to do so using llRequestPermissions. PERMISSION_ATTACH is granted automatically to a script in an attached object, but in order to foster good scripting habits, I'd advise (as does the Wiki) to check the permission has actually been granted in the run_time_permissions event, and then detach it there. attach (key id) { if (id != NULL_KEY) { //get object group key if (object_group != allowed_group) { llOwnerSay ("Access denied."); llRequestPermissions (id, PERMISSION_ATTACH); } } } run_time_permissions (integer permissions) { if (permissions & PERMISSION_ATTACH) { llDetachFromAvatar (); } }

Should one remove a listen that's been clobbered by a region change? Does an unremoved one still count against the script's allocation of 64?

Just to say that when you create a new listener, remember to remove the old one.

I think the LL viewer only allows one dialog per object these days, so redelivering a new dialog should remove the old one. Firestorm does allow the option for an object to open several dialogs simultaneously, so if that's what's happening you could turn that off.

Confused? It's really not very complicated: saying that I do like greeters that greet me only the first time I visit implies that I don't like greeters that greet me every time I visit.

If you look at my post again, you'll see that it is actually a list of my pet peeves, but cunningly (albeit too cunningly for some people) disguised as a list of things I like by the use of negations.

Let's be positive! These are some of the things I like: Greeters than only greet you with notecards and landmarks the first time you visit Greeters that offer you notecards that say something about the place, and not just "Sample notecard text" Landing points that don't require you to run the gauntlet of affiliate vendors to get to the action Search listings that don't point to areas controlled by security orbs Sunbathing beaches that aren't permanently in shadow Object givers that give you multiple items in a folder, rather than one by one Marketplace stores that give you your stuff in folders, rather than in boxes

Pie menu: Steak and kidney Chicken and mushroom Ham and leek Shepherd's Cottage Fisherman's Cherry Apple And, of course, given the time of year... Mince

But if this is starting to kick off in a big way just now, then there may be wider, or deeper, issues involved somewhere down the line.

It used to be that sometimes after a crash or corruption, items in your inventory would end up outside the Inventory folder and you'd have a merry dance getting them back inside before you could put them back where they belonged. I think sending orphaned inventory items to the Lost and Found folder was a deliberate fix for that issue.

I get you. So, where the eye texture is changed to one where you want to change the prim colour you can get the original prim colour and save it as a global variable. And when the texture is changed back to one where you want to restore the original prim colour you can use that saved colour. Add something like vector original_eye_prim_color; vector modified_eye_prim_color = <0.5, 0.5, 0.5>; //the prim color to use when the eye is closed (mid-grey here, but choose what works best) to those oher declarations at the start of the script. Immediately after those llSetLinkPrimitiveParamsFast calls that change the eye texture to closed get the original prim colour, and then set the modified prim colour: original_eye_prim_color = llList2Vector (llGetLinkPrimitiveParams (numberPrim_eyeL, [PRIM_COLOR, ALL_SIDES]), 0); llSetLinkColor (numberPrim_eyeL, modified_eye_prim_color, ALL_SIDES); llSetLinkColor (numberPrim_eyeR, modified_eye_prim_color, ALL_SIDES); Then when the texture gets changed back to open, reset the prim colour back to the original: llSetLinkColor (numberPrim_eyeL, original_eye_prim_color, ALL_SIDES); llSetLinkColor (numberPrim_eyeR, original_eye_prim_color, ALL_SIDES); I suspect you only really need to save the original prim colour just once, in the state_entry event. Is this helping?

Also, you can right-click and edit any visible HUD, and then use the scroll wheel on your mouse, or the zoom control in the camera controls floater, to zoom out and bring stuff that's off-screen into view.

Those lines of code need to go inside an event. The declarations at the start of the script can only contain constants, and not calculations. Looking at the script you've posted, I'm wondering if when you say color, you're actually talking about the texture. And I'm wondering if what you want to do is to stop the animal from going dead-eyed, or blinking, or sleeping. Or do you want to keep that and counteract an actual prim color change that some other script is causing?

Yes, in a condition test the zero vector (whether intended or the result of a failed conversion from a mangled string) is treated as false, and any other valid vector is treated as true. There's a nice little piece of code here that tests if a string is a valid vector: http://wiki.secondlife.com/wiki/Category:LSL_Vector#Useful_Snippets.

The function llGetLinkPrimitiveParams will get the colour of a linked prim: http://wiki.secondlife.com/wiki/LlGetLinkPrimitiveParams#llGetLinkPrimitiveParams. Because colours in scripts are stored as vectors, and you say you want to use it in other parts of your script, you may be better off storing the colour that way rather than having to remember to convert a string back to a vector each time you use it in a function. Now, llGetLinkPrimitiveParams returns a list, and, in the case of PRIM_COLOR, it's a list of two items: the first is the colour vector, and the second is the alpha (transparency) as a float. You must extract the colour vector from the list and can ignore the alpha float. list prim_color = llGetLinkPrimitiveParams (link_number, [PRIM_COLOR, face_number]); vector color = llList2Vector (prim_color, 0); Or, if you really do need it as a string: string color = (string) llList2Vector (prim_color, 0);

Both the LL viewer and Firestorm give you the Sit Down option in the menu when you right-click on either your system avatar or any mesh or prim attachments, including HUDs. (You might need to click through a few More... options to get there if you're using pie menus.) Also, you can hit Alt+Shift+S to sit. And you can use these to sit even if you're in mid-air, flying, falling or jumping.

It's an RLV thing. See this thread: It seems it's going to be withdrawn anyway.

I find that setting a timer and executing the "long click" code in the timer event is more comfortable as you get immediate "ok, that's long enough" feedback, rather than clicking and wondering "have I held the button down long enough yet?". You do need to set a flag in the timer event so that the subsequent touch_end event knows that there's been a long click and it doesn't need to do anything other than reset the flag.

Perhaps even more useful is the Scripts Run percentage value. When this drops below 50% and gets into single figures is when you really start to see delays between clicks and responses. There may be thousands of scripts running in a sim, but if they're mostly idle, it's no problem. If just a handful of scripts get really busy then things can start to slow down. Oh, and Script Events per second.

Also, almost every software button click anywhere works when the mouse button is released while the mouse cursor is still over the button. If you click on a button, hold the mouse button down for a bit, and then release the mouse button, that's when stuff happens. If you click on a button, move the mouse away from that button, and then release the mouse button, nothing happens. Usually... mostly. In LSL the touch_end event does fire when the mouse button is released away from the object that's been clicked. You can catch this using llDetectedTouchST and testing for TOUCH_INVALID_TEXCOORD: default { touch_end (integer count) { if (llDetectedTouchST (0) == TOUCH_INVALID_TEXCOORD) llOwnerSay ("Invalid touch."); else llOwnerSay ("Valid touch."); } }

The function you want is llSetLinkPrimitiveParamsFast (link_number, parameters), maybe using LINK_ALL_CHILDREN as the link number specifier when hiding all the links, and using a specific link number to make specific linked prims visible using PRIM_POS_LOCAL as the parameter specifier for a position vector detailing where you want the links to go. http://wiki.secondlife.com/wiki/LlSetLinkPrimitiveParamsFast#llSetLinkPrimitiveParamsFast

If you're looking for trivial and free animations, you can find the UUIDs for the internal facial expressions (those with "emote" in the name) here: http://wiki.secondlife.com/wiki/Internal_Animations.

I think it must be no copy: I'm constantly modifying the scripts in my HUD, which also contains my AO and its associated no modify, no transfer animations (but no no copy ones).

The Linden homes are located on their own groups (mini-continents?) of regions separate from mainland. There are about three of these, each pretty much the same as the other. Each has distinct areas of each of the three styles of home, along with a fair bit of open parkland. Here's an SLURL to a bit of park between housing tracts on a Linden Homes region: http://maps.secondlife.com/secondlife/Biphort/67/195/38.

However... for the sake of theatre it might be worth having the blinds change sequentially, either in a logical sequence around the room or randomly. Seriously, if you can add drama to the mundane you are enhancing people's experience of SL.