KT Kingsley

I posted a couple of textures I use for this here: Generally, use quite a few repeats and crank up the specularity with these.

First you need to get PERMISSION_TAKE_CONTROLS using llRequestPermissions. Then when that permission is granted, in the run_time_permissions event you need to use llTakeControls for CONTROL_ML_LBUTTON. Once you've done that the control event will be triggered whenever the left mouse button is pressed or released while you're in mouselook. The level parameter (as it's called in the wiki - you might be more comfortable calling it something like "pressed") has a bit corresponding to the value of CONTROL_ML_LBUTTON set when the mouse button is pressed and cleared when it's released. You test it by using bitwise &: if (level & CONTROL_ML_LBUTTON) // the button is pressed else // the button is not pressed The edge (perhaps more comfortably called "changed") parameter tells you if the state of the button has changed since the last time the control event was triggered. You test it in the same way as the level parameter. So with those two parameters you can figure out if the button has just been pressed, or is still pressed, or has just been released, or is still not pressed.

The fourth parameter you've entered, <0,0,0>, should be a rotation. What you've put there has three components, so it's seen as a vector. In LSL rotations are quaternions and have four components. But you really don't need to worry about those. Just use the built-in constant ZERO_ROTATION. If you do need to use something other than a zero rotation use llEuler2Rot (vector) if you're comfortable with radians, or llEuler2Rot (vector * DEG_TO_RAD) if you'd prefer to specify the x, y and z rotation components in degrees. Also, the third parameter, for which you've used llGetCameraPos(), is a velocity that's applied to the rezzed object (useful for bullets and other projectiles). If the object you're rezzing is physical the results could be quite spectacular and unpredictable, though if it isn't physical the parameter won't have any effect.

There's a couple of fruit sculpt textures in the inventory library under Textures/Sculpt textures.

There's a potential pitfall to be aware of here if you're using display names. Button text is limited to 24 bytes. llStringLength returns the number of characters. Display names often contain multi-byte characters. There's a code snippet in the llDialog wiki page that shows you how to truncate a string that may include multi-byte characters here: http://wiki.secondlife.com/wiki/LlDialog#buttons_limits, and, for good measure, one that shows you how to check the byte length of a string here: http://wiki.secondlife.com/wiki/LlStringToBase64#Examples.

Bitwise and & (as opposed to logical and &&). Set the testing value to whichever bit you want to check (either by assigning a value directly, e.g. 1, 2, 4, 8, 16, 32... etc. or by assigning 1 to it and shifting as required) and bitwise and it with the value you want to test: if (test_value & value_to_be_tested) is TRUE then the corresponding bits in both text_value and value_to_be_tested are set, and if it's FALSE then the bit in value_to_be_tested is not set (the bit in test_value will, of course, be set because you set it yourself). And that pretty much sums up my knowledge of bitfields. Someone who knows more about this will be along soon...

From what the OP said about using "/11 M2" in local chat successfully, I think the idea is to just chat "M2" on channel 11 from a menu. The "." is, I think, a typo for "/".

As a new project, there's two things that might come up: handling a menu with more than twelve buttons, in which case it'll need "pages" you can switch between, and reading data from a notecard. Both of these things are doable, of course, but they're a bit like getting thrown in the deep end if you're not familiar with LSL scripting.

Maybe something like this: default { touch_start (integer total_number) { llDialog (llDetectedKey (0), "Select a target:", ["M2", "M3", "M5", "M13", "M15"], 11); } } This sends a dialog to whoever clicks the object the script is in with the heading "Select a target:" and the buttons M2 - M15. Whichever button is clicked has its text chatted on channel 11 as if it were coming from the person who clicked it. If you've already got a menu with the correct buttons I think you only need to ensure that the result goes out on channel 11, which you can do by checking the channel specified in the llDialog statement. If your menu is being created by a general purpose script, there's probably somewhere you can specify the output channel; perhaps a line in the notecard it's reading. So you want the menu to output just the text "M2", and set channel 11 in the script function parameters (possiby pre-defined in a setting of some sort). Using "/11" to specify a chat channel only works, I think, in the viewer chat bar.

If it matters which face is clicked (perhaps only one, or some but not all of them) to change the texture then yes, you'll need something like if (llDetectedTouchFace (0) == 0) in there. But if it's meant to work whatever face gets clicked you can leave that out entirely. The fact that the touch_start event has been triggered means that one of the faces has been clicked. The 0 in that llDetectedTouchFace call is tied to the parameter total_number in the touch_start event. total_number tells you how many different clicks there are to be processed in the event, and llDetectedTouchFace(0) gets the number of the face clicked in the first of those clicks. Similarly, llDetectedKey (0) gets the key of whoever was responsible for that first click. All the other llDetectedSomething functions work in the same way. The index used in the llDetected* functions works just like that for llGetInventoryName, in that it can run from 0 to total_number - 1. Now, as it happens, a while ago there were questions asked as to whether the touch_start event ever returned more than one click at a time. Quite a few people tried various tests but it only ever returned a single click. Nevertheless it's worth noting this if you ever start to use other events, like the sensor event, where the parameter does actually tell you how many different results there are, and you then need to use the llDetected* functions with an index other than 0.

llGetInventoryNumber will return the number of the type of item specified in the object's inventory, in this case INVENTORY_TEXTURE. The individual items are indexed, and those indexes run from 0 to that number - 1. So if there's only one texture in the inventory llGetInventoryNumber will return 1, and to find that texture's name you need to use its index, 0: llGetInventoryName (INVENTORY_TEXTURE, 0). And if there were five textures you'd need to call llGetInventoryName (INVENTORY_TEXTURE, 0) for the first, through to llGetInventoryName (INVENTORY_TEXTURE, 4) for the fifth. llList2Integer takes an item from a list and tries to return it as an integer. When the script calls it here the list Pictures is empty so the function will always return 0 for want of anything better. I'm not sure how llSetPrimitiveParams (which originally worked only on the prim the script was in) reacts to the PRIM_LINK_TARGET rule (which came along to let you manipulate several different links in a single call to llSetLinkPrimitiveParams[Fast]), having never experimented with that, though the wiki page that covers this set of functions doesn't seem to say anything about not using it there. llDetectedTouchFace returns the number of the face that was clicked: anything from 0 to up to 7. If the face clicked was face 0 the if test will fail, while with any other clicked face it will succeed. There's more, too, to do with filling up the list Pictures and using an index to work though it and where to do that, but scripting can be a real pain to get started with, so I'll stop here. Incidentally, I'm guessing that the idea is to put some textures in an object and then apply them in sequence to that object whenever it's clicked?

Meshes Yes, the triangles, vertices and nodes that make up what you see. Also distinguishes from prims (primitive shapes that can be modified and combined to make more complex objects) and sculpted prims (objects that use the RGB values of a bitmap to represent their shape, and tend to be used for organic shapes that are difficult to model using prims). With the advent of user-created mesh models, sculpted prims are pretty much obsolete. Of course, even prims are mesh models, but the underlying mesh is pre-defined and can only be manipulated in specific ways. Also can refer to a mesh body: a user-created replacement for the basic system avatar body. Skins The graphic representation of a human (or non-human) skin. Three bitmaps, one for the head, one for the upper body and arms, and one for the lower body. The position and shape of the graphic components are specified (UV mapped) so that they a drawn on the correct part of the avatar body. Many mesh bodies attempt to match the mapping of the system avatar body so skin and clothing layers can be interchangeable, but many do not, and some are close, but not quite close enough to be entirely compatible. Also can refer to the colour scheme and layout of the interface of a viewer, with some allowing the user to select the look and feel they prefer. Outfits The collection of objects that make up a complete avatar. The body and its basic components such as its shape, body parts such as hair and fingernails, and clothing and accessories. Also may include objects like HUDs (Head Up Display) which perform scripted functions such as controlling the avatar's animations (an AO - animation overrider - which changes the default walking and standing and so on animations for ones chosen by the user), and devices that control things like clothing colours or aspects of a mesh body. BoM Bakes on Mesh. A system avatar may be using a skin, a tattoo layer, an underwear layer, shirt and pants layers and so on, each of which has its own graphic components. Baking takes all the layers and creates a single texture (with, for example, the underwear graphics obscuring the underlying skin graphics) that's applied to the system avatar body. Bakes on Mesh has made that baked texture available so it can be applied to a mesh body that's being worn by an avatar.

Velocity has both a direction and a magnitude, so perhaps llDetectedVel might be useful here.

If by "Technicolor" you mean the randomly rainbow-hued pixels resulting from corrupted cache textures, open preferences (Ctrl+P), go to the Advanced tab and click "Clear Cache" button and relog. There was an issue with the last viewer update so it was rolled back, but it left a legacy of corruption. Clearing your cache will slow things down a little as the textures need to be uploaded again, but it'll only mean a little bit longer seeing everything grey. Which is generally better then Technicolor.

I seem to remember that a few years ago SL did have a thing where empty regions stopped running until someone dropped in. I don't remember any announcement from LL that they'd stopped doing this, but I assume they have. Perhaps too many Meeroos died. If AWS were leasing server time by the second, reintroducing something like this might be an attractive proposition. And the resulting evolutionary pressure on the many species of breedables inhabiting SL would be a positive thing.

You could include the information in chat that accompanies the clickable links (like where I put "Click: ", either before or after the links, or both), or you could both open a dialog with the information and post the links in chat. (Incidentally, I see I used llGetOwner as the target in the llRegionSayTo functions; this was the result of a quick test to check I'd got the code right. If you do go this route, you'll want to replace that with the variable user which you've assigned the value of llDetectedKey (0), or with llDetectedKey (0) directly.)

According to the wiki entry for llMapDestination (http://wiki.secondlife.com/wiki/LlMapDestination) this function only works in touch events or if the script is attached to the avatar. How about foregoing the Yes/No dialog, which doesn't really add anything to the interaction, and just opening the map when the avatar clicks on the object? Or, perhaps, using the viewer URI namespace thingy that'll chat a clickable link which opens the Place Details window with its map and teleport buttons: llRegionSayTo (user, PUBLIC_CHANNEL, "Click: secondlife://Perlanera/248/146/3694"); or (llGetOwner (), PUBLIC_CHANNEL, "Click: secondlife:///app/teleport/Perlanera/248/146/3694"); or llRegionSayTo (llGetOwner (), PUBLIC_CHANNEL, "Click: secondlife:///app/worldmap/Perlanera/248/146/3694");

The RLV stuff looks OK to me, it's something I do all the time. That the clothing disappears from the Current Outfit folder but not from view suggest a baking service issue. Have you tired editing the outfit when this happens? I'm not sure of the details, but I think it shows you locally what your viewer thinks you should look like. It usually shows me a correct version on a system avatar, but I don't know if it works with BoM textures. And it is only a local fix: others continue to see the incorrect image. Is it only one set of clothing items? What happens if you use originals rather than links? Have you tried this using just a system avatar? TL:DR; I don't know the answer, but I did think of a few questions.

The Firestorm setting "Allow the camera to move without constraints through prims" is tied to the debug setting "FSIgnoreSimulatorCameraConstraints". Given the FS prefix to the debug setting name, this would appear to be a Firestorm-only feature. P.S. When I did try it out a while back, I found it even more annoying than having the camera move out of the way of objects automatically.

I just saw a notice for a Firestorm Skins class at 2pm SL time. I guess that's too short notice, but these classes do get repeated, so it may be worth looking out for. https://wiki.firestormviewer.org/firestorm_classes Although I guess this will be more about using different skins rather than making them. Though maybe you could ask questions.

I just saw a notice for a Firestorm Skins class at 2pm SL time. I guess that's too short notice, but these classes do get repeated, so it may be worth looking out for. https://wiki.firestormviewer.org/firestorm_classes Although I guess this will be more about using different skins rather than making them. Though maybe you could ask questions.

You must typecast message to a vector: llMoveToTarget((vector) message,100); And when you chat the vector you need to be careful to get it exactly right. An invalid vector in the message will be converted to the ZERO_VECTOR <0.0, 0.0, 0.0>, and your object will wander off into the distance. After that's happened a couple of times you might want to use this code snippet to test if the message string does represent a valid vector: integer IsVector(string s) { list split = llParseString2List(s, [" "], ["<", ">", ","]); if(llGetListLength(split) != 7)//we must check the list length, or the next test won't work properly. return FALSE; return !((string)((vector)s) == (string)((vector)((string)llListInsertList(split, ["-"], 5)))); //it works by trying to flip the sign on the Z element of the vector, //if it works or breaks the vector then the values won't match. //if the vector was already broken then the sign flip will have no affect and the values will match //we cast back to string so we can catch negative zero which allows for support of ZERO_VECTOR }//Strife Onizuka

Most mesh bodies pre-BoM had a few skins stacked on top of each other to accommodate things like tattoos textures over skin textures. I think some BoM mesh bodies may retain an additional layer like that. So if you have a pre-BoM body (or a post-BoM one with an extra layer) you could try using that to preview your tattoos.

I use this script to get the UUID of a local texture: default { changed (integer changes) { if (changes & CHANGED_TEXTURE) { key texture = llList2Key (llGetLinkPrimitiveParams (LINK_THIS, [PRIM_TEXTURE, 0]), 0); if (texture) llOwnerSay ("The UUID of the texture on face 0 is \"" + (string) texture + "\"."); else llOwnerSay ("You do not have permission to see this texture's UUID."); } } } Rez a cube and paste this into a new script inside it. Face 0 is the upwards facing face on a cube that hasn't been rotated. When you change any texture on the cube it'll chat the UUID of the texture on face 0 to you. I've no idea what you need to do with the UUID once you've got it. But yeah, being BoM, I guess the bake server won't know anything about the texture itself, so it won't be able to bake it. Perhaps you can just apply it directly to an onion skin layer on your target. I don't know what access issues are like on the beta grid, Aditi, right now, but if you can get in you can at least upload stuff to test at no cost.

See if using llSetLinkTexture instead of llSetTexture does what you want: llSetLinkTexture(LINK_SET, llGetInventoryName(INVENTORY_TEXTURE, g_NDX), ALL_SIDES);