KT Kingsley

The first thing that comes to mind is to utilise the moving_start and moving_end events, starting the appropriate animation and stopping the inappropriate one in each: moving_start () { llStartAnimation ("pushing"); llStopAnimation ("standing still"); } moving_end () { llStartAnimation ("standing still"); llStopAnimation ("pushing"); }

Certainly using Firestorm you can right click an object and Save As/Backup, then use the Import Linkset... option in Build/Upload to get it back. I've only tried this with prims so I've no idea what it'd do with mesh.

So does this snapshot notification work when the person taking the picture has silent snapshots turned on? My first guess would be that the viewer gets told to apply the snapshot animation to a particular avatar (it's UUID is published in the wiki), and thus knows what's happening. Presumably, if the picture taker has silent snapshots enabled, other viewers aren't told to play the animation and don't know about them taking a picture. At least, Firestorm doesn't show me the snapshot animation when I take a snapshot silently, but now I wonder if that animation information is still broadcast by the simulator to other viewers. It'd also be interesting to know if playing the snapshot animation by script would trigger the notification. Well, maybe not that interesting, but what the heck. ETA: or maybe it's that my AO animations have a higher priority than the snapshot animation so it gets played but doesn't show, and the quiet snapshot setting only turns off the sound.

If there's one thing worse than being looked at, it's not being looked at.

I like these newfangled preset things, and I do like that Esc takes you back to the preset rather than the rear view. But I also miss being able to Esc to the rear view when I want to start walking. I'd so much like an additional Esc when in a preset (or front or side/group) view to take you to the rear view.

There's a Create a Support Ticket link at the top right of the forum pages (though not in the individual thread pages).

Is there a way to use the RLV command @setenv_asset to restore the local parcel or region EEP setting, the "Shared Environment"?

Tommy Terrible has saved a lot of people a lot of work and imported all the FS Windlight settings and made them available for free on Marketplace: https://marketplace.secondlife.com/p/Firestorm-Default-Sky-Windlights-for-EEP/20088838

Looking again, I remembered it wrong. You export the avatar shape to an xml file using the Developer/Avatar/Character Tests/Appearance to XML menu item. I used my now defunct Avastar to load that xml file into Blender. The Avastar web page: https://avastar.machinimatrix.org/279/help/io/.

Note that you can (at least via the Firestorm viewer, most likely others) export an SL avatar shape to a COLLADA .dae file and import that into a 3D modelling program. I'm pretty sure that with Avastar, it can the attach that shape to it's model of the SL avatar skeleton.

I'm feeling a bit foggy today, but maybe something like this… float volume = 1.0; list units = ["exactly", "1", "2", "...all the rest...", "18", "19"]; //the sounds for 0 - 19 list tens = ["20", "30", "40", "50"]; //the sounds for 20 - 50 integer GetMinuteSomehow () { return (integer) llFrand (60.0); } default { state_entry () { llSetSoundQueueing (TRUE); } touch_start (integer count) { integer minute = GetMinuteSomehow (); if (minute < 20) llPlaySound (llList2String (units, minute), volume); else { llPlaySound (llList2String (tens, minute / 10 - 2), volume); //-2 because the list starts at 20 rather than 0 llPlaySound (llList2String (units, minute % 10), volume); } } }

In the script you posted, you request permissions in the on_rez event from the owner, which will be you. You need to request the permission to attach from the target avatar. Also, you need to need to target the chat message at this avatar rather than to yourself. Once the object has attached itself to the target they become the new owner and this triggers the changed event with the CHANGED_OWNER flag set. Telling the script who the target is generally requires opening a chat channel between it and the object that rezzed it. It's common to use the on_rez parameter to tell the rezzed object which channel to use, setting it in the llRezObject call in the rezzer script, which then starts listening and waits for the rezzed object to come on line and ask for the key of the target. When the rezzer replies the rezzed object can go ahead and ask the target for the relevant permissions. Other methods are available.

There's a process called rigging. You attach the vertices of the mesh model to the bones of the avatar skeleton, assigning varying degrees of influence (weight) to the connections. There's a thing called Avastar that adds the SL avatar to Blender to help with this. And that's the sum total of my knowledge of clothes-making in SL.

Also consider RLV, which can attach objects to you directly from your inventory, completely bypassing the permissions issue.

Right click on the setting in your inventory and select "Apply only to myself". Or, top menu bar/World/Environment/My Environments... and right click it from the window there. You can get the full set of converted Firestorm Windlights on the Marketplace here: https://marketplace.secondlife.com/stores/200828, but to convert ones you've made yourself you'll have to do it the hard way.

Qie, that's a good point, and something I hadn't thought of. I shall modify my own implementation of this accordingly. Speaking of which, it'd be interesting to hear if the OP is concerned that some of their targets might be sitting on something, which opens a whole new can of worms as far as llCastRay is concerned.

Because you might hit it? The one thing you hit (rather than nothing, or you encounter an error) might turn out to be the target, which isn't that unlikely given that's what you were aiming at.

Have you checked the spam filters in your email services?

@Fritigern Gothly @Rachel1206 I can't see why my post caused your reactions. Fritigern writes about testing the hit returned by llCastRay to see if it's an avatar. There's no need for that, surely? If the key returned by llCastRay is that of the target avatar, then there was nothing in between the start of the ray and that avatar. If the key was anything else then that something else was between the start of the ray and the target avatar, or there was an llCastRay error. Now, this wouldn't be the first time I've missed something bleedin' obvious, but for the life of me I still can't see where I've gone wrong here. Please enlighten me. The shortcomings in my post that I do acknowledge are that I didn't state specifically that the variable target_key was the key of the target that had been previously acquired, that I didn't handle any of the possible errors that llCastRay may have generated, instead going for the simple options: a clear line of sight to the target/something got in the way, albeit possibly a system error (which I allude to with the phrase "pretty basic"), and I didn't address the OP's automation question which, I think needs more information before a proper answer can be given.

Use your own and your target's positions as the start and end vectors. Maximum hits is 1 by default (which is all you need). Phantom objects are rejected by default. vector target_pos = llList2Vector (llGetObjectDetails (target_key, [OBJECT_POS]), 0); list raycast = llCastRay (llGetPos (), target_pos, []); key hit = llList2Key (raycast, 0); if (hit == target_key) { // you've hit the target: there's nothing between you and them } This is a pretty basic snippet, but it may be an adequate starting point. Not tested in-world.

I think all regions – including those usually running RC server versions – are on the main channel, running server version 553685.

If you can modify your mesh avatar, then you could put this script in the link that you want to mess with. You'll need to know the face number of the part you're targeting and use that instead of the 1 I've used in this example. float interval = 10.0; integer face_number = 1; integer opacity; default { state_entry () { llSetAlpha (opacity, face_number); llSetTimerEvent (interval); } timer () { opacity = !opacity; llSetAlpha (opacity, face_number); } }

Setting the camera for a prim you sit on is pretty simple (if you can modify it): default { state_entry () { llSetCameraAtOffset (<0.0, 0.0, 1.0>); llSetCameraEyeOffset (<3.0, 0.0, 1.0>); } } You drop the script into the prim and then you can delete it: these camera properties of a prim persist without the script being present. Inevitably you'll want to tweak the actual numbers used. The "At" is where the camera points at in relation to the prim, and the "Eye" is where the camera is located in relation to the prim. For each the values are the distance forwards/backwards, the distance left/right and the distance up/down, all from the centre of the prim. It does get tricky when the prim has been turned on it's side, or the sit position isn't facing the same direction as the prim's forward, and to help cope with that edit the prim and set the reference to "Local" in the editor window. The red green and blue arrows will show you the actual directions you need to consider. Then when you sit on the prim your camera will move to the specified settings (provided it's in the default setting – press Esc a couple of time to get it there).

My take on using click length, like Nova suggests, to initiate two different actions uses a timer: integer long_click; default { touch_start (integer count) { long_click = FALSE; llSetTimerEvent (0.35); } touch_end (integer count) { if (!long_click) { llSetTimerEvent (0.0); llOwnerSay ("Short click"); // do your short click stuff here } } timer () { llSetTimerEvent (0.0); long_click = TRUE; llOwnerSay ("Long click"); // do your long click stuff here } } I find having the long click action initiate automatically after the button has been held down for long enough is more comfortable than having to hold down the mouse button and hoping you've held it down for long enough. 0.35 seconds seems about right for me. Anything less than 0.25 seems too susceptible to lag and clumsy clicking, while longer than 0.5 seems to take forever.

Using RLV you can set someone's active group, though for that to work they first have to have RLV active in their viewer. Not all viewers support RLV, and for many (probably most, and possibly all) of those that do it is disabled by default, and has to be deliberately enabled by the user. If you're planning to attach an object to an avatar when they enter your land that object can issue the RLV command to set the group. RLV can't determine directly whether a user is a member of a particular group, but it can attempt to set the group and the script can then test to see if it's been successful.