Wulfie Reanimator

@LeonissiaLoc There is no real communication needed between the two objects. For example, I have a nondescript object moving around in a circle (1 degree every 0.022 seconds). It only has code for moving itself, it does not listen or send messages. I then have this script in a worn attachment (also updating the camera params every 0.022 seconds, but you do not need to do it this often): key uuid = "c6e3e94d-9586-ff64-2f52-bae2b76a25b9"; default { state_entry() { llRequestPermissions(llGetOwner(), PERMISSION_CONTROL_CAMERA); } run_time_permissions(integer perm) { llSetTimerEvent(0.022); } timer() { // Get the remote object's position and rotation. list data = llGetObjectDetails(uuid, [OBJECT_POS, OBJECT_ROT]); vector pos = llList2Vector(data, 0); rotation rot = llList2Rot(data, 1); llSetCameraParams([ // Begin controlling the camera and prevent it from being moved. // (Alt-cam will still override this.) CAMERA_ACTIVE, TRUE, CAMERA_FOCUS_LOCKED, TRUE, CAMERA_POSITION_LOCKED, TRUE, CAMERA_FOCUS, pos, // The position the camera will LOOK at. CAMERA_POSITION, pos + (<0, -2, 1> * rot) // The position the camera will BE at. ]); } touch_start(integer n) { llClearCameraParams(); llSetTimerEvent(0); } } Note that I used "<0, -2, 1>" as an offset so that the camera would be on the object's right side and slightly above it. For testing purposes, you can select any object or link in Edit Mode and click on the "Copy Keys" button in the General tab of the Edit Tools window. If you were to rez an object with a script and wanted to track that instead, you could get the rezzed object's key through the object_rez event. For any other case, you'd require some kind of custom communication between the objects. Also note: Because of the *_LOCKED values, the camera change will be instant, so this will always look jerky.

Sadly, that page was created in 2010 and the related JIRA article is from 2007.

The only way for an avatar to automatically sit on anything is with an RLV command. http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI To clarify, especially if you've never used RLV, these commands are used with llOwnerSay so the viewer can take action. string target_prim_uuid; llOwnerSay("@sit:" + target_prim_uuid + "=force"); Also to add; You can get the UUID of the rezzed object in the object_rez event, eg: default { state_entry() { // llRezObject } object_rez(key id) { llOwnerSay("@sit:" + (string)id + "=force"); } }

The most active group I'm in is called "Script Academy" but another, more general group would be the "Builders' Brewery" (but it's for all builders, not just scripters).

I think we're gonna have to consult NASA for the level of Woosh in this thread.

"Ternary operator" (as opposed to unary or binary) is actually a real term in other programming languages, like the C family. The syntax is something like: condition ? true : false The LSL version's syntax in general is a little suspect. It's not necessarily less typing and it's definitely more memory-consuming. I can't say anything about its speed though. But it's not something you should worry about. If that line was the slowest part of your whole script, you've got literally nothing to worry about. (speed-wise)

Also, depending what sort of look you're going for (or what you're into), I would recommend SKNK by Tokeli Zabelin. There's plenty of human options, some even bento-rigged. Personally I prefer the smooth/cute Verpas series over anything like the overly detailed Aeros. Your mileage will vary, especially if your body skin does not match the "cute and smooth" style.

The term "hack" has many meanings in different contexts. I was half-expecting someone to wander in and say something like "you can't hack anything with LSL!" I use the term "hack" in this case to refer to code that does something particularly unusual. Something that doesn't look pretty or is hard to understand when you first read it. While it is true that "hacks" are just another way to do something, the term usually has a negative connotation because hacks are often undesirable solutions. Here are some additional examples of code I have written: // Use a "nonzero" check to toggle another value. integer multiplier = 3; integer test = 3 * !!multiplier; // test will be 3, not 9. // Multiplier will be used as 1, not 3. // If multiplier is 0, it stays 0. // Clamp value with if-check float test = 1.5; if((test += 1.5) > 2.5) test = 2.5; // test will be 2.5 instead of 3. // llList2* functions as ternary-operators string greeting = llList2String(["Afternoon!", "Morning!"], (llGetGMTclock() / 3600) < 12); And all together now, just as an example I came up now to illustrate all of these things in practice. default { state_entry() { integer score_threshold = 100; integer current_score = 95; integer current_multiplier = 2; integer score_gained = 5; // Final score being added before prize checking. integer final = llList2Integer([current_score * current_multiplier, 0], (current_score += score_gained) > score_threshold); // condition llOwnerSay(llList2String([ "Scored too high! Better luck next time!", "Your final score is: " + (string)final], !!final)); // 95 + 5 = 100, not over threshold. The user wins the game with 190 points. // If score_gained is 10, the score threshold is exceeded and the user loses with 0 points. } } Or heck, this is some real code I'm using right now (in a timer):

Nothing is stopping you from using the main body slots normally used for LL UVs to bake textures compatible with your custom mesh body instead.

Scripting is about solving problems. Syntax has surprisingly loose rules sometimes. What kind of code have you written that made you surprised that it even worked at all? (Or maybe it was just something you discovered by accident or never thought about before.) I was inspired to post this because of something I was implementing. For context, I was trying to select the closest avatar within a sensor that was not in the same group as the object. The first line is what I originally did, and the lines after it are changes I made to it to see if I could shorten it without breaking anything. All of these lines are valid and have the exact same result. integer i = -1; do { ++i; } while(llSameGroup(llDetectedKey(i))); integer i = -1; do ++i; while(llSameGroup(llDetectedKey(i))); integer i = -1; do; while(llSameGroup(llDetectedKey(++i))); integer i = -1; while(llSameGroup(llDetectedKey(++i))); // Final i is then used for other llDetected* functions.

You should look into the Omega Applier dev kit. It allows you to put the applier script (no modify) in an object, then a notecard that includes all the texture UUIDs you want the applier to apply. The notecard is then loaded by the script and deleted afterwards (so your customers don't see the UUIDs). But maybe you already know about Omega, and you think a script can take a texture and "make it work" on any UV map. That's not the case, and you must create the tattoo based on the UV you want or it will never look right. One sneaky trick I can offer is "local textures." The "Local" tab allows you to add any textures directly from your computer, without actually uploading them. (Only you will be able to see these textures, others will see grey.) You can still get the temporary UUID of these local textures, and use that temporary UUID in an Omega/Belleza applier to apply your local texture onto the body. Now, if you edit the file on your computer, the changes are shown in-world automatically after you save your changes. This should help adjusting the texture a lot.

Scripts within Second Life have absolutely no way to reach into your computer in any capacity. They run exclusively on Linden Lab's servers and you can only observe the changes they cause in the simulator. (Source: I'm an experienced scripter.) The absolute worst thing a script could do is disrupt your movement (like throw you around the sim), or listen to nearby messages in your local chat and transmit those to someone else. Both of these are bannable offenses (harassment/disclosure rules), so it would be pretty unlikely that you ran into someone trying to do this to you. It could easily be that he rezzed it as well to show you what it was (in case you didn't want to rez it). You are very safe in Second Life, so you don't have to assume the worst from other people. Nobody here can permanently break your avatar or touch your computer at all.

What exactly do you mean by "logging into profiles?" How does changing someone's group title require you to log into anything, when it can be done within the viewer? But generally, assuming this is some kind of a web-thing, you may have cookies disabled. (Cookies are used to store data about your current session or login token, so you wouldn't have to log in again until the cookie expires.)

Helpful as ever, Rolig! Thank you for reminding me of that. I recall reading the old version of the thread before the forum migrated. I was actually pretty close.. had the right idea anyway.. but couldn't get the calculation right for the other llRotBetween. My final code looks something like this-ish: vector target; vector direction = llVecNorm(target - llGetPos()); direction.z = 0; rotation final = llRotBetween(<1,0,0>, direction); float distance = llVecDist(<target.x, target.y, 0>, <this.x, this.y, 0>); rotation pitch = llRotBetween(<1,0,0>, llVecNorm(<distance, 0, pos.z - this.z>)); llSetLinkPrimitiveParamsFast(2, [PRIM_ROTATION, final, PRIM_LINK_TARGET, 3, PRIM_ROTATION, pitch * final]);

So I have this little thing. It's a turret that rolls around its base to aim around itself, and pitches the cylindrical cannon to aim for targets at different altitudes. This turret is linked to a larger linkset, so neither of them is the root (but the root's center will be the bottom of the base). I'm having trouble with the math behind this, as usual. Rotating the base is pretty easy: vector target_position; // Could be anything. vector direction = llVecNorm(target_position - llGetPos()); direction.z = 0; // Ignore the Z offset, the base MUST stay upright. rotation final = llRotBetween(<1,0,0>, direction); llSetLinkPrimitiveParamsFast(2, [PRIM_ROTATION, final]); Even going so far as rotating both, the base and the cannon to face the same direction is trivial, but I don't know how to add to the cannon's local Y rotation so that it would only pitch up/down without rolling around itself and looking all wonky.

Have you read the LSL wiki related to reading lines from a notecard? Why don't you study the music player I've posted (and linked to you previously when you were asking very similar questions) in the LSL Library here on the forum?

@ThalesMiletus Please disregard Steph's advice, they're often misinformed, misinterpreting, or coming up with their own observations without backing any of it up. Then eventually you'll get the iconic "I'm right and you're wrong. Good day." But to answer your question, this isn't really doable, because of two BIG limitations in SL/LSL. While llDetectedTouchPos correctly detects which region coordinate an attachment was touched (very easy to test)... llGetPos will give you the avatar's position in region coordinates, not the attachment's position. (So this will cause you to have an inaccurate offset to begin with.) llGetRot will give you an approximation of the avatar's rotation (it is not accurate unless the avatar is sitting or in mouselook). The only possible way to get llDetectedTouchPos work in an attached object, is to have the attachment attached to Avatar Center at ZERO_VECTOR. Then your avatar must also be sitting on an object. (I'm unsure if groundsitting works.)

I think it mainly depends on the length of the hair. For something that short, I think you can leave it "solid" (unrigged, or only rigged to the skull). For longer hair that goes past the neck, you may want to have it rigged to the head and chest/spine or other appropriate bones. For example: If the above hair was unrigged, the bangs on the front would stab into my chest whenever my head leans forward. Instead of that, we get this: (I assume this is what you meant by "animated" and not actual animations for the hair.)

Sadly this is a very long-standing problem on almost every viewer. (Especially for things that go above 200-300k tris like Belleza Freya, cough. Hope you enjoy freezing for 5 seconds or crashing, unless you have a high-end PC.) Isn't it more related to how the highlighting is rendered, though? Because things only seem to get worse with denser wireframes rather than simple face-count.

Fraud is still fraud, or are you saying it's okay to steal things below a certain value, under the guise of someone else even? (No, I don't mean let's all go grab torches, but pointing a thing like this out shouldn't be met with dismissal. Plain acknowledgement is enough.)

There's a rumor that you started this rumor.

http://wiki.secondlife.com/wiki/LlAdjustSoundVolume 🙄

If you are talking about animating the mesh itself that you have created in Blender, LL has recently added a new feature aptly called Animesh. First, you will have to rig your mesh to the SL skeleton. (The animated parts anyway.) Then you will have yo create an animation. (You can create these in Blender as far as I know.) Once you have those uploaded on SL, you need a script that will play the animation from the object's inventory. A script like this can be very simple, especially if you need just one animation to be playing forever. I've never animated in Blender so I can't help you there. I would post the SL skeleton link but I'm on my phone and it's painful.

Like Qie guessed, you have to first stop the sound before you can play it again with a different volume. (I think this is because playing a looping sound that is already playing is ignored.) Though, fun fact; there's a function called llAdjustSoundVolume which can change the volume of a looping sound without restarting it. It's not particularly helpful here, but maybe elsewhere.

From http://wiki.secondlife.com/wiki/Typecast "For casting a variable myVar to a single-item list, the syntax (list)myVar is about 30% more efficient under LSL Mono than the syntax [myVar]. The same (list)myVar syntax is also slightly more efficient under LSL-LSO."