KT Kingsley

That's pretty much how I do it too. I've posted my version of a multiple timer in this LSL Library forum thread:

There's been a question in a scripting thread about using multiple times in a single script, so I'll offer up my take on the subject here. I've been using this without problem for quite a while now but, as with all scripts, I expect people will find their own problems when they try to use it. list timer_events; SetTimerEvent (string label, float interval) { integer index = llListFindList (timer_events, [label]); if (interval <= 0.0) { if (~index) { timer_events = llDeleteSubList (timer_events, ~-index, -~index); if (timer_events == []) llSetTimerEvent (0.0); } } else { list this_event = [llGetTime () + interval, label, interval]; if (~index) timer_events = llListReplaceList (timer_events, this_event, ~-index, -~index); else timer_events = this_event + timer_events; timer_events = llListSort (timer_events, 3, TRUE); } if (timer_events) { interval = llList2Float (timer_events, 0) - llGetTime (); if (interval <= 0.0) interval = 0.01; llSetTimerEvent (interval); } } StopAllTimerEvents () { llSetTimerEvent (0.0); timer_events = []; } string GetTimerEventLabel () { string label = llList2String (timer_events, 1); float interval = llList2Float (timer_events, 2); timer_events = llListSort (llListReplaceList (timer_events, [llGetTime () + interval, label, interval], 0, 2), 3, TRUE); interval = llList2Float (timer_events, 0) - llGetTime (); if (interval <= 0.0) interval = 0.01; llSetTimerEvent (interval); return label; } To start and stop a timer event use the function SetTimerEvent with either a non-zero or zero interval. You must also supply a string label to identify the specific timer event. In the timer event itself use the function GetTimerEventLabel to get the indentifying label for the specific timer event, and use this to select the appropriate course of action. This function also sets the timer up for the next event. There's also the StopAllTimerEvents function, because sometimes you want to do that.

What Rolig said quicker than me. The only other thing I was going to suggest is that if you're trying to figure out the receiving object's key you could put this line into the state _entry event, just under where Rolig has the llListen line, so it'll tell you what it is when the script starts: llOwnerSay ("My key is " + (string) llGetKey ()); You can then copy and paste it from your chat history into the sending object's script, replacing where you've used llGetKey. Don't forget to enclose the key in quote marks.

I'm not saying that, I'm just saying there's that setting, which is all I know. You could try to get into the habit of pressing Enter immediately before you try to chat.

In Firestorm, go to Preferences/Move & view/Movement and uncheck the option "Pressing letter keys affects movement…" option. This does, however, disable all the WASD movement keys.

One thing that isn't going to work: if (llToLower(message) == "Bot sit"). "Bot sit" has a capital letter, so it will never be the same as a message that's been converted to all lower-case. Use "bot sit" instead. Ditto for "Bot stand". And yeah, that's a thing with scripting: just when you think you've got something sussed, you run into something that lets you know there's even more to it than you thought.

Using this version of the listen event seems to work: listen(integer channel, string name, key id, string message) { if (llGetPermissions() & PERMISSION_TRIGGER_ANIMATION ) { if (llToLower(message) == "bot sit") { llSay(0, "roger, roger."); // llStopAnimation (""); llStartAnimation("sit_ground"); } else if (llToLower(message) == "bot stand") { llSay(0, "roger, roger."); llStopAnimation("sit_ground"); llStartAnimation("stand"); // llResetAnimationOverride(""); } } } I've commented out the llStopAnimation and the llResetAnimationOverride functions that reference an empty string as they do nothing like that, but in the "bot stand" section I've changed the llStopAnimation call to specify the "sit_ground" animation that's started in the "bot sit" section. As expected, my own AO messes up the ground sit when it cycles the stand animation to a different one (it doesn't know I'm supposed to look like I'm sitting on the ground, so it just carries on as if I was standing). So if your bot is using an AO, you may need to find a way to turn it off when your bot sits down. How to do that depends on what type of AO it's using. (As an aside, and in answer to my own question about the differences between sit_ground and sit_ground_constrained, sit_ground works like any other animation, while the constrained version appears to disable the movement keys and bring up the stand button, though starting it using llStartAnimation does not seem to put my avatar into "Sitting on Ground" mode as reported by llGetAnimation.)

It's not in your inventory - it's one of SL's built-in animations, as is sit_ground and the others detailed on the wiki page I linked. You just have to use the name in llStartAnimation. It doesn't need to be in the object's inventory, it sort of "just exists" in Second life and is available to use in any script.

You can make your bot play a ground sit animation in the usual way with llStartAnimation. I was about to say you can use the built-in default animation, but looking at the wiki page for the internal animations, http://wiki.secondlife.com/wiki/Internal_Animations, I see there's two: "sit_ground" and "sit_ground_constrained", and I'm not sure what the difference is. My first guess is that the constrained version locks the avtar in place so it can't get bumped around, as with an actual ground sit. But that's just a guess. If your bot is using an AO with a ground sit animation of its own, you can also try using that. Anyhow, try llStartAnimation ("sit_ground") or llStartAnimation ("sit_ground_constrained"), or even llStartAnimation ("My AO groundsit animation") and see how that goes. Note that neither of the two built in animations have to be in the inventory of the object triggering them, but a custom animation of your own does. And if your bot's AO is using a set of stand animations that cycle, this will likely mess up its ground sit animation.

Definitely. Wetware = human.

An RC (Release Candidate) channel is a set of regions where the latest server versions are tested in-world before being promoted to the main channel. I don't know why they're rolled out on different days. Perhaps to ease the strain on both the hardware and the wetware.

If an object is a prim with a path cut, rezzing it with the cut away part at its base will place it as if the cut away part is still there. But that doesn't explain why it seems to rez as expected on top of another object.

If you do continue with llGetAnimation, please do take a look at the wiki page I linked. There you'll see that the strings the function returns for the sitting states are "Sitting" and "Sitting on Ground" (and it's important to use the same capital letters – "Sitting" is not the same as "sitting"). Something that might be causing confusion is that llGetAnimation does not return the name of an animation that's playing, it returns the state the avatar is in. So if your avatar is sat on something, llGetAnimation will return "Sitting" whatever animation your AO, or the object you're sitting on, has started.

You're using the wrong string values in the if statement for all but the standing animation state. See the wiki page for llGetAnimation here: http://wiki.secondlife.com/wiki/LlGetAnimation.

I think Firestorm was given a pass on parcel Windlight because LL planned to bring in something similar themselves, eventually. It did take a good few years, but it has happened.

I think this was originally aimed at things like the Emerald (throws salt over left shoulder) viewer's multiple attachments to a single attachment point, which which looked fine to people using Emerald (more salt), but rather bizarre to anyone using the LL viewer. I don't see how it can be applied to rendering issues, when even the LL viewer has a host of settings that that can radically alter the look of a scene and the objects in it. And I think the thing with RLV is that using it yourself doesn't affect anyone else's experience: if an RLV object captures and strips you, then both you and your non-RLV audience see the same thing. That a non-RLV user can't be captured and stripped by that object… well, the end result isn't that different from from a scripted object that's set to group only use.

Two thoughts come to mind: wear a prim that covers you up during the change, or use an animation that puts you underground. Either or these could be scripted to trigger automatically when you TP to a new region, and to stay in effect for a set time, or you could tell it to start and stop manually.

It means the things you're buying are all inside a prim box. You'll have to rez it somewhere and then open (from its right-click menu) it to move the items to a folder in your inventory. It may be that the box is set to automatically unpack itself when you click it, which is also handy if you can't find somewhere to rez it: you can just wear it and click it. And some boxes are made to automatically unpack themselves when you do wear them. You should be able to find somewhere to rez the box if you use search to find a "rez zone". Many of the Linden water regions have rez zones where people rez their boats and these are suitable for unpacking boxes. Slightly more involved, if you can't get to a rez zone, is to wear the box, right-click it, and select edit. Go to the Contents tab of the edit window. You can then select and drag the items in the box to a pre-prepared folder in your inventory. Just don't ask why merchants put people to all this hassle when it's just as simple for them to have the goods delivered to their own sub-folder in the Received Items folder in your inventory.

Were they perhaps boxes you had to unpack? Or, maybe, items taking a long time to rez? In case they were, you might consider restoring then from your trash and investigating further before clearing your trash.

I do sometimes try to Alt+Click on still images and videos in RL.

Typo here: llOwnerSay ("Resident = " + resident); Should be: llOwnerSay ("Resident = " + Data); The variable resident is the identifying key for the query. Data is the result of that query.

There's Unavailable (or is it Busy?) mode available to you from somewhere in the top menu bar, depending on which viewer you're using. Set that and it shows in your name tag for everyone to see. Any IMs will get a polite (or not so polite, if you're using a viewer that lets you customise the message and you chose to be more forthright) automatic response.

The first thing I spotted was that in the notecard you have the text "ALL_SIDES". Only the compiler sees that as a constant with the value -1. So you can either replace "ALL_SIDES" in the notecard with "-1", or you can read it as a string and then, in the script, test that string for "ALL_SIDES", in which case assign -1 (or the constant ALL_SIDES) to the face number, or if the string isn't that, cast the string to an integer and assign that to the face number. The next thing I spotted is that you extract a lowercase version of the command you read from the notecard, but then you test that against strings that include an uppercase character, as in "gFace", so the condition will never be true. So either don't use llToLower when you extract the command from the notecard, or, having converted it to lowercase, compare it against a lowercase version of the command.

If you mean Bright Canopy, I understand they've shut down.

I think the function you want is llGetAnimation (http://wiki.secondlife.com/wiki/LlGetAnimation) which actually returns the animation state of an avatar rather than a specific animation.