KT Kingsley

Thanks, Wulfie. I did have a passing wonder about that, but dismissed it until such time I might need to address it directly. I think in a situation like this I'd be building parallel lists, one for the names truncated to button labels and the other for the keys of the avatars. And maybe a third list of the full names were these needed for display purposes, though there I've taken to using the viewer URI thingy for that.

There's a nice little code snippet in the llDialog caveats that shows how to truncate a string so that it'll work in a button, even when it contains UTF-8 characters that'd take it over the byte limit although it's 24 or fewer characters in length: llBase64ToString(llGetSubString(llStringToBase64(theString), 0, 31)) So, @Sylvia Wasp, all you need to do is replace llGetSubString(llGetDisplayName(thisKey), 0, 11) in your button list building loop with llBase64ToString(llGetSubString(llStringToBase64(llGetDisplayName(thisKey)), 0, 31)).

Here's a way of distinguishing between an attach event triggered by attaching from inventory and one triggered on login: attach (key id) { if (id) //is this an attach? (as indicated by a valid non-null key) { if (llGetColor (1) == ZERO_VECTOR) //is face 1 coloured black? { llSetColor (<1.0, 1.0, 1.0>, 1); //restore face 1 to its normal colour //attached from inventory } else { //attached on login } } else //or a detach? { llSetColor (ZERO_VECTOR, 1); //colour face 1 black //normal detach, not triggered by logging out (but see below) } } Note that the wiki entry for the attach event very sensibly points out that currently logging out does not trigger the attach event will a null id, but that scripters should anticipate the possibility that this might not alway be the case. I have very sensibly ignored that advice here. In this example I'm using a face colour to flag a detach, but there's any number of other prim parameters that could be used instead. When an object is being detached you can usually squeeze in a couple of lines of simple code that'll execute fairly reliably before the script stops running. My experience (and a brief test) suggest that any such code not executed at the time of the detach will pick up again when the object is reattached, and do so before the attach event is triggered with its owner's key, so this should still work even if the flagging code doesn't actually execute at the time of the detach. It used to be the case that calling llGetAgentSize would return ZERO_VECTOR for a few moments immediately after login, but having just tried to use that method I found it not to work, hence this alternative.

Oops, wrong place

I think the stand-alone sky preset "(SS) Atmos 13:00 1" corresponds to the time you have the day cycle set to. Select that for your WL sky and unselect Firestorm's Preferences/Firestorm/Windlight/Automatically change... setting (and any others on that tab that apply).

I have some mesh crosshairs I use when no one is looking at me.

Umm... Priorities. I've only ever used QAvimator to make animations, but when I upload one SL gives me the opportunity to set a priority. In-world, when playing two animations, when they clash it's the one with the highest priority that wins. (I understand that with some animation creating software you can set priorities within the animation itself, and even set a higher priority – 6, according to the SL Limits wiki page – than the maximum 4 allowed by the SL uploader.) You just call llStartAnimation whenever you want. The SL Limits wiki page doesn't, however, mention a maximum number of animations that can be run on a single avatar at any one time. Edit: what Wulfie said.

Object: llSetPrimitiveParams error running rule #1 (PRIM_TEXT): bounds error; -7.45058e-08 is not in (0, 1). That's a very tiny negative number, so I'd say it's a rounding error. This does seem to work, though: integer i=0; integer alpha = 10; while(++i<=10) { alpha-=1; llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_TEXT,"test",<1.0,1.0,1.0>,(float) alpha / 10.0]); llSleep(1.0); }

Mesh. Well, rather than being stuck with just prims and sculpted prims, we can make pretty much any shape we want, albeit it using an external 3D modelling tool like Blender or Maya. Mesh avatars, or rather bodies. As we can make any shape we want, one of the things a lot of people want is a better body than the standard SL one. Enter mesh bodies, of which Maitreya and Slink are major purveyors. Rigged mesh. To make a mesh body or mesh clothes work they have to bend at the elbows, for example. Rigging is the process (part of making the 3D model) that moves parts of the mesh shape in sync with the underlying SL avatar skeleton. Fitted mesh goes a step further in that it conforms to the body shape sliders of the underlying SL avatar. Bento is an enhancement of the SL avatar that provides many more bones than the original, so you get things like wings that can be animated, and, perhaps most frequently seen, hands that have fingers that can be individually animated and heads that can have fine control of their shapes and expressions. Mesh clothes. These are now mostly rigged and fitted, so they bend with the SL avatar and conform to the body shape. But rigging is tricky, and there are few clothes that'll fit perfectly. So in came a new clothing layer: alpha layers. Alpha layers make parts of the avatar body invisible (remember invisiprims?), so your elbows are no longer seen to poke out of your jacket. It gets more complicated. Alpha layers don't work on mesh bodies, so most mesh bodies come with a HUD that'll let you hide those inconvenient body parts. Also, you want to be able to use a skin of your choice on a mesh body, so we have appliers, scripted objects that apply the skin of your choice to the mesh body of your choice. And, of course, appliers can be used to apply "painted on" clothes (like the original system clothes) like underwear. But... Just recently introduced: Bakes on Mesh! BoM lets you put the baked avatar body textures (the combination of skin, tattoos, underwear, shirt, jacket, pants, etc.) that you'd see on your system avatar onto a mesh body. Mesh bodies have been made with several skin layers (the onion skin model) so you could apply a skin texture to one layer, a tattoo layer to the next and clothing textures to yet another (for example). Eventually, BoM will let mesh body makers do away the the extremes of the onion skin model, and do away with the need for appliers. Eventually. Maybe. Hope this helps. P.S. Rather than be gutted at how much has changed, see it as a new learning opportunity. Look forward to those moments when you suddenly twig what something's about and revel in the joy that brings!

I guess you're not scripters.

Not something I'm familiar with, so this is a wild guess, but have you set the Experience to the same group as you've set for the parcel and deeded the object to? Oh, and allowed that experience in the parcel?

This blog post talks about Process Credit limits, and has links to a review of your status and to the page where you can submit a ticket to request changes:

You can add things to outfits by copying and pasting them (or, usually better, pasting a link) into the outfit folder. You can paste into multiple selected folders if you use the Paste keyboard shortcut Ctrl+V. Be careful, as you can make a bit of a mess with this if you've selected the wrong folders. Undoing a paste like this is a matter of selecting every incorrectly pasted instance and deleting it manually. If you want to paste a link, you must first copy and paste a single link and then copy that link and paste that into the folders. If you're pasting into outfit folders in the main Outfits folder, though, links are pasted automatically.

You'll see a lot of Isil doors in a lot of sci-fi settings.

Which method are you using? The strided list or the parallel question and answer lists, with the extra list with the order of the questions? Edit: Ok, so looking back I see you're using a strided list. Hopefully this minimalist script (which doesn't listen for the answers but just puts the questions up as a dialog using a throw-away channel) illustrates how it could be done: list quiz = [ // question answer picks (buttons) the pipe | is the delimiter "\n\nWas heißt auf Englisch \n\n\n'weil'", "because", "now|also|but|because", "\n\nWas heißt auf Englisch \n\n\n'obwohl'", "although", "although|now|but|because", "\n\nWas heißt auf Englisch \n\n\n'auch'", "also", "although|also|but|because", "\n\nWas heißt auf Englisch \n\n\n'aber'", "but", "although|now|but|because", "\n\nWas heißt auf Englisch \n\n\n'jetzt'", "now", "although|also|now|because", "\n\nWas heißt auf Englisch \n\n\n'heute'", "today", "yesterday|tomorrow|now|today", "\n\nWas heißt auf Englisch \n\n\n'morgen'", "tomorrow", "yesterday|tomorrow|now|today", "\n\nWas heißt auf Englisch \n\n\n'gestern'", "yesterday", "yesterday|tomorrow|now|today", "\n\nWas heißt auf Englisch \n\n\n'immer'", "always", "always|also|although|again", "\n\nWas heißt auf Englisch \n\n\n'wieder'", "again", "always|also|although|again" ]; integer stride = 3; integer quiz_length; integer question_number; string correct_answer; // so it's available in the listen event when the user has made their choice default { state_entry () { quiz = llListRandomize (quiz, stride); quiz_length = llGetListLength (quiz); } touch_start (integer count) { if (question_number * stride >= quiz_length) { llDialog (llDetectedKey (0), "\n\nThat's all, folks!", [], -999); llResetScript (); } else { string question = llList2String (quiz, question_number * stride); correct_answer = llList2String (quiz, question_number * stride + 1); list choices = llParseString2List (llList2String (quiz, question_number * stride + 2), ["|"], []); llDialog (llDetectedKey (0), question, choices, -999); ++question_number; } } }

If the questions list is strided, with the answers in there too, you could use llListRandomize to shuffle it at the start of a quiz, and then work through it sequentially. If you have parallel question and answer lists, maybe you could create a third list for the order in which to ask the questions, starting of as [1, 2, 3, 4, …], use llListRandomize on that, and then work through it sequentially to get the numbers of the questions to ask.

Yup, it did one back-and-forth and then stopped.

It seems to need the LOOP bit set otherwise it only does the ping pong once.

I dread encountering that complete with sound effects.

As you say, the group names could be anything. Your script would need to run through the prims in the link set and for each name, check whether it's already in the list if it is use llListReplaceList to update the counter item use llListInsertList to add the link number into the group if it's not add the name to the end of the list add the counter, 1, to that and add the link number to that

You can use frame animations to depict mechanical movements such as the inner workings of a clock. Or blinking lights on a control panel.

You could take a look at the LSL JSON functions which are a useful way of storing complex (by LSL standards) data structures. Or you could make what I'll call a "variably strided" list (there's probably a formal computing name for this, but I don't know it), where each group consists of a group name, the number of items in that group, and the items themselves: ["A", 3, 2, 3, 4, "B", 2, 5, 6, "C", 4, 7, 8, 9, 10] So to find the items in group B, you'd use llListFindList to find the index of ["B"], then index + 1 will tell you how many items there are, and the items will have indices of index + 2 through to index + 2 + count - 1.

llGetSunDirection is, I think, reporting the EEP sun direction while your viewer is rendering the Windlight settings, and I don't think these are necessarily the same. It may be worth taking a look using the EEP project viewer.

I'm sorry my post affected you like that. It was meant to be a lighthearted acceptance of the reality of my place in the whole scheme of things and of my place in the whole scheme of Second Life. Just because someone doesn't make a publicly acknowledged mark on whatever universe you care to use as a measure, really doesn't mean they were nothing at all. I'm conceited enough to believe that my death will sadden quite a few people in real life, but I really wouldn't want it to sadden anyone too much. As far as SL goes, I very much doubt anyone will notice (except perhaps LL's billing section when they start to wonder why my subscription payments are being refused), and that's pretty much how I want it to be.

"Who?"