Quistess Alpha

There are ~3 different methods (that I can think of at the moment) of implementing that each with advantages and disadvantages: Old "music box" technique. Sound files hosted on SL servers need to be split up into 10 second snippets, and cost 10L$ per snippet (unless you're premium plus) to upload. There are a wide variety of free or inexpensive scripts available that can stitch the 10 second clips back together into something that plays back well enough. Parcel media. See https://wiki.secondlife.com/wiki/LlParcelMediaCommandList It's not too hard to direct an audio file at a specific avatar, but on the user end of that technique, it can be really easy to miss the pop-up notification asking if you would like to hear the audio. Media on a prim.(also called 'shared media') See Basically, you can make a web-browser tab appear on any face of an object in SL, and you actually don't even need a script for it. In addition to the steps listed on that page, you'll want to adjust the settings so that the media is not automatically played when it comes into view. (Firestorm aggressively enforces click-to-play media, but in other viewers media can turn on automatically from a very far distance unless the settings are checked correctly) Options 2 and 3 require you to have a somewhat reliable 3rd party hosting service to store the audio on.

That function doesn't work unless you own the 0,0 parcel (southeast corner IIRC) of the region.

a texture change script works exactly the same whether it's driven by a HUD or by local chat, although if you put the textures into the inventory of the texture-changed thing, and only want it to respond to the owner, you can simplify the script down to its bare basics: // script and textures go in the inventory of the texture-changed object. // integer gChannel = 27; // in this example you will have to say '/27' in front of the name of the txture: // for exmaple: '/27 magic-blue' or // '/27 magic-blue 2' to only set on face 2. // if the channel is 0, you don't have to say anything in front: // 'magic-blue 2' default { state_entry() { llListen(27,"",llGetOwner(),""); } listen(integer channel, string name, key ID, string texture) { texture = llStringTrim(texture,3); list parsed = llParseStringKeepNulls(texture,[],[" "]); // spacers get kept in the list. string last = llList2String(parsed,-1); integer face = (integer)last; if(face || last == "0") { texture = (string)llDeleteSubList(parsed,-1,-1); }else { face = -1; } llSetLinkPrimitiveParamsFast(1, [ PRIM_TEXTURE,face,texture,<0,0,0>,<1,1,0>,0.0 ]); } } or so (untested)

It's mildly non-trivial. try replacing experience permissins with regular permissions in this example I posted forever ago:

Yes but I wouldn't recommend using it for much serious, unless you like directly playing with numbers. You might be able to use it to add in a few touch-ups to something made in Qavimator, but even for something this trivial I had to reference /character/avatar_skeleton.xml (comes with every viewer installation) for bone names and default positions, and upload a bunch of tests to the beta grid.

Not only that, but you have to transfer ownership to the non-owner. llAttachToAvatarTemp() does that automatically; llAttachToAvatar() does not. Assuming you (the OP) want to use your vehicle in more than one spot (which I'd assume given tat vehicles usually move around) ~not using an experience is actually better, because experience attached attachments automatically detach when you move onto a parcel that does not have the experience enabled.

I had a bit of a play, turns out the best fudge is to push the leg back into the body, a little further than you might think reasonable (animation quoted for spam reduction) .anim file: https://drive.google.com/file/d/183GPdQMB2O_caA75yDPBGoe36loFw93x/view?usp=sharing Not amazing, but marginally better than without fudging in some bone translation. As far as I can tell though, Qavimator doesn't have tools for translating bones other than the avatar's position though.

You might be able to get away with translating the bone down a little? How exactly you do that would depend on the animation software, and the results will of course depend on which body you're using.

Broadly speaking, 'Things that come in lots of colors' (usually clothing) come in 2 varieties, either a single texture for each color variation, or a single grayscale texture and the ability to 'tint' the object by changing its color property in the build window or via a HUD. Making individual textures for all the color variations under the sun is tedious and expensive (less so if you're a premium plus member), but the results from directly tinting a white texture don't always look quite right. Enter this simple script example! If you know the rough 'base color' of your textures, it's not all that difficult to pick out the one that's closest to some desired target color, and tint it just a small amount to get it spot on. list gTexColor = ["001fb953-90df-fde5-748d-0050b93c7c3c", <1.0,0.576,0.924>, // not actual valid textures on the main grid. "d6e6756e-567d-de78-c136-7697da808595", <0.098, 0.533, 0.87> // there will be some 'out of bounds' colors unless you have a pure white (<1,1,1>) texture. ]; list suggest_texture_color(vector color, list texcol) { string tex_fin; vector col_fin; float dist = 9999; vector diff; // temp working variables float d_check; integer index = llGetListLength(texcol)+1; while(index-=2 >=0) { vector col = llList2Vector(texcol,index); if(col.x>=color.x) {if(col.y>=color.y) {if(col.z>=color.z) { diff = color-col; if((d_check=diff*diff) < dist) { dist = d_check; col_fin = <color.x/col.x, // it would be better to just 'col_fin=col;' and do this division in the return statement. color.y/col.y, // but I don't want to break the version I tested in-world (briefly), so leaving it as-is. color.z/col.z>; tex_fin = llList2String(texcol,index-1); }}} } } if(dist!=9999) { //llOwnerSay((string)[tex_fin,col_fin]); return [tex_fin,col_fin]; } return []; } default { state_entry() { vector color = <0.0,0.5,0.3>; list texcol = suggest_texture_color(color,gTexColor); llSetTexture(llList2String(texcol,0),0); // using named functions for clarity over llSLPPF. llSetColor(llList2Vector(texcol,1),0); // llSetColor(color,1); // using face 1 as a refference to compare with a direct tint from white. } touch_start(integer total_number) { // test a random color on touch. vector color = <llFrand(1.0),llFrand(1.0),llFrand(1.0)>; list texcol = suggest_texture_color(color,gTexColor); if(texcol) { llSetTexture(llList2String(texcol,0),0); llSetColor(llList2Vector(texcol,1),0); llSetColor(color,1); }else { llRegionSayTo(llDetectedKey(0),0,"No suitable base texture found for color: "+(string)color); } } } The 'suggest_texture_color' function takes a color and a strided list of texture-color pairs, and returns either a list containing one of the textures and the color that texture should be tinted to in order to achieve the input color, or an empty list if none of the base colors are suitable. It should be noted that this is only a sensible thing to do if your textures are not just a solid color layer multiplied over the base texture. In that case, you'd probably get the exact same results just tinting the base texture in SL.

I think the point is to convert UUIDs to names in some database software outside SL, which obviously doesn't have access to llRequestUserKey,

string name = llGetDisplayName(...); {// I rarely do, but best practice to wrap temporary working info in {}'s. list parsed = llParseString2List(name,[" "],[]); if(llList2String(parsed,1)=="Resident") { name = llParseString2List(parsed,0); } } or so? (untested).

The answer is that you can't. you have to send the user the dialog box back every time they click an option and you want it to re-appear. To make sure the menu remains consistant every time you re-issue it, I generally wrap it in a user-defined function, like so: integer gChannel = 12345; // methods for randomly geerating a channel and when that might be appropriate is another topic. . . integer gListenHandle; list main_menu_options = ["button1","button2"]; main_menu(key user) { llSetTimerEvent(30.0); llListenControl(gListenHandle,TRUE); llDialog(user, "Main menu",main_menu_options,gChannel); } default { state_entry() { gListenHandle = llListen(gChannel,"","",""); llListenControl(gListenHandle,FALSE); } timer() { llSetTimerEvent(0); llListenControl(gListenHandle,FALSE); } touch_start() { main_menu(llDetectedKey(0)); } listen(integer channel,key ID,string name,string text) { integer index = llListFindList(main_menu_options,[text]); if(index!=-1) { llSay(0,llKey2Name(ID)+" has selected option "+(string)(index+1)+"."); main_menu(ID); } } } off the top of my head, untested.

The script seems to add new lines just fine when I try it? you just hit enter ond if the text you put in te box has a newline in it that should show up on the prim-text. If you want to replace '\n' with a newline character you'll need ot do that manually with something like message = llDumpList2String(llParseStringKeepNulls(message, ["\\n"], []), "\n");

If you follow the breadcrumbs, there's circumstantial evidence that this offer is related to:

Cool VL viewer has their own forums. . (even if they are a bit of a pain to get to some times if you don't have a short internet path to France) http://sldev.free.fr/forum/index.php

Ugh. fiine. A worked example. This is a hexdump of an animation with 2 specified frames: Or in a more human-readable format: Notice firstly that this animation has only 2 "frames" one where mPelvis is at position <0,0,0>, and another where mPelvis is translated to <0,0,1>. Here's how it looks in-world: Note how the transition from the first frame to the second is interpolated (linearly) but it snaps back to the first position from the second.

That's what interpolation is. I could give you specific .anim file examples, but I don't feel like wasting my time to prove a tangential point. Edit: see post on next page.

Not really. A) BVH animaitons are 'optimized' on upload and conversion to .anim to remove any changes smaller than certain threshold (loo lazy to look up what the threshold is) so, if your animation only moves 5 degrees in a second, that might result in only 5 frames per second for that joint in that second. B) animations are interpolated viewer-side. an animation with only 2 frames will still look smooth; it would take extra frames to enforce a 'jerky low fps' aesthetic.

I don't think so, but there are long hairs specifically designed for men as well. I know No.Match has a few.

My first thought would be to add a notecard along with the boxed object, and have the notecard's first line used as the price (That would require a bit of careful logic in the script to either read and store the price in a 2-strided list when the notecard is added, or re-direct the logic from the asyncronous note-card read back to whatever interaction is needing the price of the item)

There have been plenty of topics about simple "spanker" scripts you can easily find by searching for them. or for example. As for rubbing, the easiest cheat would be to just depend on the total time with llResetTime() in the touch() event paired with llGetTime() in the touch_end() event. More complicated things can be done in the touch() event by storing llDetectedTouchUV to a global variable (either in the touch or touch_start event or both), and checking the momentary difference, perhaps based on the angle (llAtan2) or magnitude (llVecDist()) of the difference. A rather prominent spanker-maker asked me for advise on "rubbing" and "grabbing" a month or two ago, and as they gave me a rather generous tip for it (which I didn't ask for) I wouldn't really feel right posting the (rather trivial) examples publicly. ETA: As for moving the butt itself, you need specifically made animations for that.

You mean these people?

https://marketplace.secondlife.com/p/DS-Rina-Sunglasses/17228560 perhaps? Deep static has a lot of nice varieties, but my SL partner and I have an in-joke about their use of photoshopped mustaches in a lot of their adds.

The actual names don't even have to substantially differ. "Junk Food" has 3 results. (all owned by people associated with the business)