KT Kingsley

Oh good grief! Within seconds of posting this, the answer appeared out of nowhere as the result of a post in another forum detailing someone's incomprehension of the term "universal wearable". It's an new item of system clothing with slots for all the new channels. Question (mostly) answered. And the bit about mirroring can be answered easily enough by trial and error.

So, how do I get a system layer into one of the new BoM channels? The first use case that springs to mind is using a tattoo on the left arm channel. I believe that this exists so that the left arm doesn't have to mirror the right arm. I'm no longer limited to a tattoo on my arm that just says "MOM". I can put "I ♥ NY" there and not have it show as "YN ♥ I" on the other arm. Do I have to make a texture that uses the upper body template (UV map) with the tattoo mirrored, or do I use a mirrored upper body template with the tattoo the right way round? Or is there a completely different template? And having made my tattoo layer how do I get it into the baking system? And how do I throw my skin and, say, my gloves into the mix?

I'm not sure if this will help, but what the heck, here it is anyway: On the left is a snapshot taken using a non-BoM viewer, on the right, one taken with the BoM viewer. This is a system avatar: I'm not wearing a mesh body. I'm wearing a skin, two tattoo layers, a hair base, an alpha layer for my boots, and undershirt, underpants and socks clothing layers. I'm also wearing mesh eyes, and an alpha layer that hides my system eyes. Instead of a mesh avatar I'm wearing a mesh panel above me which has has eight faces, to which I've applied (left to right, top to bottom) the BAKED_HEAD, BAKED_UPPER, BAKED_LOWER, BAKED_EYES, BAKED_SKIRT, BAKED_HAIR, IMG_USE_BAKED_LEFTARM and IMG_USE_BAKED_LEFTLEG system textures using the build editor (in the texture picker there's now three radio buttons to select the texture source: Inventory, Local and Bakes: selecting bakes lets you select the baked texture from a drop-down box). In the left-hand, non-BoM, image the baked textures are showing as the placeholder textures that you'll see in a non-BoM viewer. In the right-hand, BoM, image you can see the baked textures for my head, upper and lower body. These would normally go on the corresponding parts of a mesh body. The baked eye texture is transparent because of the alpha layer I'm wearing to hide my system eyes. The skirt texture is grey because I'm not wearing a system skirt. The baked hair texture is transparent because the hair base I'm wearing uses a transparent texture. The left arm and leg textures are grey because I'm not using those either. You can see that the parts of my avatar that have had the system layers applied are now hidden. This is done automatically when the equivalent baked textures are applied to a mesh. If you can imagine replacing the panel above my head with a mesh body with the baked textures applied, you should be able to see how this all works. Nothing has been changed between the two snapshots, except the viewer used to take them.

Just to say that the BoM viewer has been promoted to default viewer (version 6.3.0.530115), and is available here if your SL viewer doesn't update itself automatically: https://releasenotes.secondlife.com/viewer/6.3.0.530115.html.

Well if you have to rez it in a particular parcel, and that parcel is set to group only access, then anybody who is there has to be a member of the group. And users don't have to wear the group tag to get into group only places.

I don't RP in the formal sense, and when I'm presented with a screenfull of RP rules (no godmodding, wear the RP hud, join a clan/species/race, make sure you have a proper backstory, read the multipage history of the scenario, etc., etc.), I tend to put an egg in my boot*. But when approached casually by someone who talks as if the situation we're in is real, I usually don't have a problem responding in kind. Until I get bored. *And beat it. (Spike Milligan.)

You can download and install Firestorm and LL viewers separately, and they won't interfere with each other, so you can choose which one you want to use when you decide to fire up SL . Barring cockups, when you start the standard SL viewer on Monday (26 August) it will update itself to the newly released version that is the BoM viewer. The BoM version of Firestorm will follow in due course. I seem to remember some comment that the last version of Firestorm was built with BoM and EEP eagerly anticipated, and that the upgrades will follow, by FS standards, relatively swiftly.

Ctrl+Shift+1 (Advanced/Performance Tools/Statistics Bar) opens the Statistics floater. The percentages referred to are Scripts Run under Simulator. (I can't remember what's expanded in the default view, but clicking on items will expand or collapse a section, or cycle through the graphic indicators.)

RLV is a system that lets you control some of the things you can usually only do with your viewer from scripts. It lets you control your attachments and clothing layers and it also lets you control other things like what you can see, what you can say and hear, and where you can go. To make it work you need an RLV viewer, and you need to enable RLV in it. You then need the scripts that make it do its stuff. RLV scripts will only work on the owner of the object they're in (they use the LSL command llOwnerSay to send RLV commands to the viewer). RLV is often used to let other people control things like your clothes and to capture you (make you sit on an object without the option of standing up). To let this happen you need an RLV relay. This is a scripted device (sometimes a collar, sometimes a HUD, and sometimes something else entirely) that listens to broadcast chat commands and converts them to llOwnerSay commands that go to you viewer. Although RLV is best known as a BDSM tool, it is enormously useful for automating a lot of the things you do with your viewer. Without an RLV relay it is entirely under your control, though you are vulnerable if you put on an attachment that has someone else's RLV scripts in it. If you find yourself in an RLV situation you're unhappy with, you can always log out, relog using a non-RLV viewer, and then remove any offending RLV attachments.

This may or not be helpful here, but when I'm faced with a situation where a dialog button text needs to differ depending on a flag, I tend to do something like this: llDialog (id, "Click:", ["This", "That", llList2String (["Lights on", "Lights off"], lightsOn)], channel);

Yes, you should remove a listener when it's no longer wanted, even if only because scripts are limited to a maximum of 65 of them. But also because they use simulator resources, so it's only polite to do so. (Incidentally, changing state as well as resetting the script will close any active listeners.) ETA: there's also llListenControl, which lets you turn an existing listener on or off. Does anyone know if or when using this might be preferable to creating and then removing listeners? I'd guess it'd be the better option on a busy channel when otherwise you'd frequently be creating a new listener and then removing it.

Firestorm has the "Movement at region crossing" setting in Preferences/Move & View/Movement. With "Predict" set, at a region crossing your viewer will continue to show you or your vehicle moving at the velocity (speed and direction) it thinks you were following, based on what it last heard from the previous simulator before it disconnected, until it hears from the new simulator, when it will snap you to the position and velocity the new simulator tells it. If the length of the inter-sim hiatus is significant, and you weren't moving perfectly horizontally when you left the previous region then you will be shown ploughing into the ground of flying off into the sky until the viewer gets updated with the information from the new simulator. With "Stop" set, your and your vehicle come to a dead stop at the border, and stay there until the new simulator updates your viewer with your position and velocity. It's a matter of taste, I guess, which is preferable. When the simulator handover is fast the prediction option gives you a smoother, more seamless experience than stopping. When the handover takes ages the stop option prevents the flying off into the wild blue yonder experience. How, or if, these settings relate to the other problems experienced at region borders, I have no idea. I seem to remember playing with something similar in the SL viewer but can't remember the details. Also, I'm not anywhere near technically savvy enough to claim this is a definitive explanation. It may even be hopelessly wrong. ETA: There's Velocity Interpolate Objects and Ping Interpolate Object Positions settings in the Developer/Network menu, which I think may be related to this.

I just visited Brighton without problem. My HUD reported (at 09:06:52 PDT) that I arrived there 18 minutes after a restart (that is, 18 minutes after the region was up and running again). Perhaps the region had a problematical restart that took much longer than usual.

Bringing states into this may complicate the issue, but it is my favourite way of preventing unwanted clicks. And the OP did acknowledge there might be different solutions. Were you to switch to an active state without a touch_start event when the quiz begins, other avatars wouldn't even have the option of clicking. key user; default { touch_start(integer total_num) { user = llDetectedKey(0); state active; } } state active { state_entry () { llListen(0,"", user,""); llSay(0,"question"); } listen(integer channel, string name, key id, string message) { if(message == "this is the correct answer") { llSay(0,"correct!"); state default; } } } However, in this case it may be preferable to stick to a single state and use a flag. This does give you the option to send a "Please try again later" response.

The bit about flexies knocked something in my brain, and animesh sprung to mind. Might this be the smoothest way of doing this? With switching between more and less extreme oscillation animations, or including more and less extreme oscillations in the same animation? Have I even understood the capabilities of animesh? Also, if you want a bit of X and Y, maybe a particle effect string (ribbon)? In this instance I really would like to hear detailed (or just general) demolitions of this idea, because I'm really not sure just what you can do with animesh.

First thoughts are to use something like llVecMag (llWind (llGetPos ())) to scale the movement — the size of the oscillation, and then feed that into a multi-stage keyframed motion (stopped, slow, faster, slow, stopped) ping-pong, remembering to keep the time per oscillation constant, and adjusting the rate or magnitude of the rotation. I guess I'd want to resample the wind at the midpoint of each oscillation to make it easier to keep the thing facing, on average, in the same direction. I think I'd want to avoid using target omega because you'd have to throw a timer in there too. And make it very shiny, and put it somewhere it'll catch the light. I'm not sure how the sound is generated by one of these, or if it is at all (Wikipedia doesn't mention sound), so I'm not sure how I'd go about doing the chime part.

I don't think locations have a UUID. Objects, however, do. I guess what that script is looking for is the UUID of an object at the target location. Which will, presumably, be the UUID of another teleporter object. I don't see an obvious way of getting the UUID of an object in the SL viewer, though Firestorm has a Copy Keys button in the edit floater that'll probably do it. This script, when dropped into an object that you can edit, will report that object's key: default { state_entry() { llOwnerSay (llGetObjectName () + "'s key is: " + (string) llGetKey () + "."); llRemoveInventory (llGetScriptName ()); } }

Yes, it's a sort of shareable photo album thing, not unlike many other image hosting sites. https://photos.google.com

Have you looked at Google Photos?

Have a look here: http://wiki.secondlife.com/wiki/Third_Party_Viewer_Directory#Subset_Viewers. I've not used any of these so can't offer any comments.

Yeah, it's only a very vague and unquantified idea that's started lurking in my head. Maybe the effect spills over from busier regions on the same server. More likely, though, it's something else altogether.

I've only had this problem with dirty and decaying mouses. If you have an old mouse lying around somewhere try it and see if it also has the same problem.

I may be starting to get the entirely subjective idea that it's regions that have more comings and goings of agents that seem to be most affected by this.

You can reset the avatar list more easily: avatar_list = [];. You need to wait for the sensor to do its stuff and for your code to build the list of buttons before you display the dialog. It can go in at the end of the loop that builds the avatar list in the sensor event. You could put the "SCAN" button text at the start of the avatar list so you can initiate a re-scan from the avatar list dialog. So when you reset the avatar list start it off like this: avatar_list = ["SCAN"];. (First thing in the morning, and I've only just made my tea. I hope the effects aren't infecting my post.)

If you can edit it, try setting the texture's alpha mode to alpha masking, and then fiddle with the mask cutoff setting until it looks ok. If you can copy it mess about with a copy of the original until you're happy with the result. If you can't copy it, a) send it back or, b) make a note of the original settings (which'll probably just be alpha mode: alpha blending) and reset those when nothing works. Be aware that it's entirely possible that there's more than one face in your hair object, so you'll have to repeat the process for each. (Also, this cures that annoying halo effect you get around your hair when it's seen against a background of trees and vegetation that also has an alpha blending texture. Bottom line: the graphics engine used by SL – and countless other games and whatevers has problems deciding what's in front when it has to render overlapping semi-transparent textures. Alpha masked textures are not semi-transparent: they're either completely transparent, or not at all transparent.)