KT Kingsley

Have you tried /*Windlight Sky: "[name of the preset]"RegionOverride*/ https://wiki.firestormviewer.org/fs_windlight#how_to_force_parcel_wl_to_always_override_region_wl

As mentioned, you can't trigger a gesture from a script, but it's easy enough to reproduce a gesture in a script. Perhaps something like this: default { state_entry () { //The script must request permission to play animations //which is automatically granted for worn objects llRequestPermissions (llGetOwner (), PERMISSION_TRIGGER_ANIMATION); //set the object's name to the wearer's display name if you want it to say stuff as if //it was coming from your avatar llSetObjectName (llGetDisplayName (llGetOwner ())); //this doesn't change the object's name in your inventory, to which it reverts when detached } attach (key id) { if (id) llResetScript (); } collision_start (integer count) { //check if you've collided with an avatar: //llGetAgentSize returns ZERO_VECTOR if the collision object isn't an agent (avatar), //and this is evaluated as FALSE, so the following code doesn't get executed. if (llGetAgentSize (llDetectedKey (0))) { //the animation must be in the object's inventory llStartAnimation ("angry old lady"); //or whatever it's called //The sound clip must be in the object's inventory, or you can use its UUID (key) llPlaySound ("curse and swear", 1.0); //or whatever it's called //trigger rather than play so it's heard outside if it's in a HUD //llTriggerSound ("curse and swear", 1.0); llSay (PUBLIC_CHANNEL, "Watch where you're going, you stupid kid!"); //or whatever you want //or llWhisper or llShout or //llRegionSayTo (llDetectedKey (0), PUBLIC_CHANNEL, "Watch where you're going, you stupid kid!"); //for a more private admonition //and maybe for fun: llSay (PUBLIC_CHANNEL, "/me waves her stick at " + llGetDisplayName (llDetectedKey (0)) + ", nearly poking their eye out."); } } } WARNING: this hasn't been tested in-world, so there's probably problems lurking.

You'd then need to include some method of issuing an llOwnerSay("@detach=y"); command, otherwise you'd be stuck with it until you either disabled RLV and relogged, or you relogged with a non-RLV viewer. Alternatively, you could give the object a name that includes the word "nostrip", "Rating tester (nostrip)" for example. (Or, I think, though I've never tried it, you could keep it in a folder – an #RLV subfolder? – whose name includes the word "nostrip".) This stops RLV commands from detaching it, but lets you detach it using the normal SL methods.

I have an old-style Linden Home, which I find very useful for its LI allowance. But I also have a mainland 512m² parcel which I'd be loath to give up under any circumstance. I understand that LL's intention is to do away with the old homes eventually. I do hope that they can be persuaded to either leave a few of them or to create some new 512m² homes for people who've used part of their 1024m² allowance elsewhere.

How many buttons show in the menu now? If it's 12, including the animations and the control buttons, then maybe the script hasn't been written to accommodate multiple pages and is just ignoring anything that takes it over the limit.

What happens if the offending animation is the only one in the object? What happens if you add yet another animation after the offending one? What happens if you rename the offending animation? Oh, and Avsitter is a script system for playing animations in objects that are sat on. It lets you customise stuff like the menus. It doesn't sound like it's involved in this.

If you can script (or know a tame scripter) and you use an RLV viewer then you could be able to automate the process to some extent. I do use RLV to adjust my hover height for some of the shoes I own, and it does work pretty well. I guess you'd need to make something like a HUD with a script driven by a settings notecard that specified stuff like parcel/region/height. I wonder if llCastRay could be used to determine the exact height of the surface you're walking on, and this value used to adjust your hover height? I suspect it'd be a fairly complex process having to take several other factors into account as well.

Don't forget that Bakes on Mesh is just around the corner (currently fighting it out with EEP for the next major feature release).

LSL itself is a pretty simple language with enough similarities to many others to be easy to learn by anyone who's ever done any scripting. It does lack some features, such as arrays, but it does have work-arounds for these that do work. The big learning curve with LSL is the large number of unique functions for performing in-world tasks, and the way SL works and how you have to approach its specific needs, factors that'd still be present in any other scripting language. This would still present a significant challenge to anyone coming to SL, even if it used a scripting language with which they were familiar. Having said that it was mooted sometime around the introduction of Mono that C# might be instituted as an alternative. I'm not sure why it never did get implemented: maybe something to do with some layoffs at the time.

Yes, you set the timer when you start the animation (10 seconds in this case): llStartAnimation (animation); llSetTimerEvent (10.0); and in the timer event you stop the timer and the animation: timer () { llSetTimerEvent (0.0); llStopAnimation (animation); } One other thing (probably redundant now you've found a suitable script) is that in order to use llDetachFromAvatar () you need to have asked for permissions to do so: llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION | PERMISSION_ATTACH);

Something like this: llListen (0, "", "", ""); if (llSubStringIndex (message, "ass") > -1) { llStartAnimation (animation); } This checks if the string "ass" appears anywhere in the incoming message. It will respond positively if the message contains words like "bass" or "Cassiopeia" as well as just "ass". It is possible, though considerably more involved, to check if "ass" appears as a stand-alone word rather than as part of a longer word.

Way too much in those folders and files for me to publish publicly. Sorry. I'm out.

A couple of years ago, facing a financial crisis, and subject to a confusion about dates (1st November versus 11th January, USA versus the Rest of the World), I did abandon my mainland parcel and Linden home and downgrade. I couldn't downgrade without first abandoning my land. When the crisis turned out to be a damp squib, I submitted a support ticket and LL allowed me to rescind the downgrade and buy back the abandoned mainland parcel at L$1 m‾². I had to find a different Linden home, though.

Which log files are relevant, and where can they be found? (Windows 8.1 in my case.) Thanks.

Dammit, I've always had trouble with probabilities like these. It's not the red/red card. Therefore it's either the blue/blue card or the blue/red card, suggesting the probability of blue is 0.5. Does that work? What's the catch?

I quoted the list from, and the link to, the SL wiki to show that LL does, in fact, disallow residents of some states from participating in skill gaming, which seems to be causing some confusion.

Here you go: http://wiki.secondlife.com/wiki/Linden_Lab_Official:Second_Life_Skill_Gaming_FAQ#Prohibited_states_and_countries.

I've found that textures that have some transparency are susceptible to this. I have sometimes saved a texture as a png with the transparency checkbox set in my graphics editor when the texture actually had no transparency in it at all, with the result that it didn't work as intended under different SL lighting conditions. If your texture isn't supposed to have any transparency, check that the transparency % setting in the build floater is zero, and that the alpha mode is set to none. Also, is it possible that a script might be turning the fullbright setting on and off?

On my dashboard, under Account, I can see Change email settings, Contact information and Billing information. And that's about it. (And my contact information is blank.) If it's identification for process credit that's changed, I've no idea. Maybe a support ticket?

It can be done pretty much the same way: a series of outfit folders in the #RLV folder, filled with links to the actual items. You can get RLV to report the folders to populate a menu. To change an outfit you can lock everything in the target folder that's already worn, remove everything else you're wearing, and then add the rest of the target folder. I've found it's worth waiting for RLV to report that everything in the target folder is now worn before redisplaying a menu. For myself, I put sub-folders for things like a jacket that can be removed independently into the outfit folder. It's this sub-folder capability that persuaded me to go the RLV route, something that's sorely missing from the system outfits, though it was available briefly after the initial introduction of outfits.

I seem to have learned something new (new to me, at least). If Inara Pey's blog (here) correctly reports Grumpity Linden's statements at the Tilia town hall meeting, I and most other SL users won't even have to accept the Tillia Terms of service to continue using SL. Grumpity says "Only those who have a USD wallet [balance] need to accept the Tilia Terms of Service".

Yeah, UUIDs. Ah well, back to waiting for grid-wide experiences.

Oh! Does that mean I can keep a notecard in my inventory and have scripts read it from there?

llKey2Name asks the simulator for the information. The simulator only keeps information that's relevant to it right now, and maybe for a just bit longer until it gets purged for not being immediately relevant. The llRequest* functions ask the database for the information. This is always available, but takes longer to access, hence the use of callback functions. Depending on the context, using the forms from Viewer URI Name Space may be a useful option, for example: "User secondlife:///app/agent/" + (string) llDetectedKey (0) + "/inspect was detected."

In my case the bad effects on scripts have been that those I've edited (whilst worn, and not subsequently detached and reattached) shortly (in terms of the number of TPs rather than time) before the TP failure have reverted to their pre-failure code. As has data written to the object description field. It's one of a number of scripts I use constantly (as part of my always and everywhere HUD) without issues, and on relog after a TP failure the data recovered from that object description refers to a situation a while before the failure rather than that at the time of failure.