Wulfie Reanimator

Edit: Never mind me, I'm many levels of tired. I wish there was a delete button.

Coding can be tediously specific, so step one would be to avoid vague terms. What's "just above?" 1 meter? 0.1 meters? What size is the object you want to rez? What about "taken away?" Clicked/touched? Walked on? Right-click Take? That might sound nitpicky, but if you're talking with a scripter and trying to explain to them what you want, they'll have a lot less headaches figuring out the details if you're specific from the get-go.

Right-click your avatar's name-tag Select Appearance > Edit Shape Select the male symbol in the appearance window.

For future reference, if you are using Firestorm: 1. Select an object. (preferably a new prim) 2. Build > Object > Edit Particles This will bring up a particle editor window, and the effect is shown on the selected object as soon as you change the values. Only you can see these particles until you click Inject (which creates a new script in the object to start the real particle effect), or copy the code to another script. This way you don't need to have any real knowledge to get the particles you want, all that's required is some playing around.

Not sure if your post was sarcastic, but have you heard about Sansar?

If you're playing video through prim-media, then the audio and video work just fine. When I say "not synchronous," I mean between different avatars. Not everybody might be on the same part of the video at the same time.

All I have to say is that compiling alone doesn't disqualify something from being a scripting language. Do some research, languages that are interpreted from bytecode are classified as "scripting languages."

Sorry but I have to chime in because of the misinformed claim. Sims don't restart every time you compile and add a script to an object. No new EXEs or DLLs are being created so no linking is needed. The script is compiled into bytecode which is then interpreted by the server as it's running uninterrupted. That is the definition of scripting languages.

I'm a bit confused about what you're trying to do exactly. (What is the real use-case, besides just "playing audio or video?") In any case, there isn't a real way to do either of those things synchronously to different avatars in SL. Playing 10-second sound clips can be made almost seamless, but it's tricky, not really synchronous, can't do video, and uploading the clips can get costly. Using prim-media is the better choice, but all it does is load a URL for each avatar separately. It does not show the same page to all avatars, meaning that just like with sound clips, each avatar's bandwidth affects what they get, and any avatar can pause the video for themselves while the other avatars continue watching/listening. (Although, loading an actual livestream like Xilja suggested is probably your best bet for keeping things in sync even if someone wants to pause.) If you go into more detail on what you're actually trying to make, we might be able to give better suggestions on what you could do.

But the non-transparent texture is probably not 32x32. Unless the button uses the same texture as something else on the HUD, in which case it won't need to be loaded again.

I would recommend using llSetLinkAlpha instead of changing the texture. If you changed the actual texture, the user would see the grey "loading texture" almost every time the button was supposed to become visible again and that's just annoying.

This script is intended to help show exactly where the ray travels and what it hits, if anything. All you need to do is manually adjust the visualizer's position and rotation using the build tools, and touch the object to "fire" a ray. The length of the ray can be adjusted by saying any length in local chat, and the visualizer will adjust to it. To get set up, rez 3 (of any) prims, link them together, and then put this script in. It will create an object like this: And here it is in action, hitting the inside of a hollow sphere: Here's the code: float length = 5; default { state_entry() { // This simply sets up the object properly. // Link 1 and 3 are spheres, link 2 is the long cylinder. llSetLinkPrimitiveParamsFast(1,[ 9, 3, 0, <0,1,0>, 0.0, <0,0,0>, <0,1,0>, 18, -1, <0.251,0,1>, 0.5, 7, <0.2,0.2,0.2>, 34, 2, 33, <0,0,0>, 9, 1, 0, <0,1,0>, 0.0, <0,0,0>, <1,1,0>, <0,0,0>, 18, -1, <1,0,0.251>, 1, 7, <0.01,0.01,10>, 35, <0.4950,1,0>, 30, 1, 34, 3, 33, <0,0,0>, 9, 3, 0, <0,1,0>, 0.15, <0,0,0>, <0,1,0>, 18, -1, <0.251,0,1>, 0.5, 7, <0.2,0.2,0.2>, 30, 1 ]); // Only listen to the owner's avatar. llListen(0, "", llGetOwner(), ""); } listen(integer c, string n, key id, string m) { // Only react to valid floats. if( ((float)(m+"1") == 0.0) ) return; length = (float)m; llSetLinkPrimitiveParamsFast(2, [PRIM_SIZE, <0,0,length*2>]); llOwnerSay("New length set."); } touch_start(integer n) { // Rotate the end-position of the ray with the object. list data = llCastRay( llGetPos(), llGetPos() + ((<0,0,length>) * llGetRot()), [RC_DATA_FLAGS, RC_GET_ROOT_KEY | RC_GET_LINK_NUM]); if(llList2Integer(data, -1)) // Was there a hit? { llOwnerSay("Raycast hit \"" + llKey2Name(llList2Key(data, 0)) + "\" link #" + llList2String(data, 1)); // "Dividing" the position with the object's own rotation removes the rotation. llSetLinkPrimitiveParamsFast(3, [PRIM_POS_LOCAL, (llList2Vector(data, 2) - llGetPos()) / llGetRot()]); } else { llOwnerSay("Nothing was hit."); llSetLinkPrimitiveParamsFast(3, [PRIM_POS_LOCAL, <0,0,length>]); } } }

Bullet projectiles tend to be long, usually at least as long as the numbers I gave earlier, for the exact same reason. People don't want their bullets going through their targets either, so, a 5-7 meters long bullet (which is typical) can go partly through a wall, be in contact with an avatar, and then hit it before disappearing. Other factors such as the speed and lower physics FPS can make the problem worse, as fewer updates will allow bullets to skip further into large objects between the updates. I guess one thing you could do is use llSensorRepeat and llPushObject if the sim allows that. The idea being that you push the bullets to the side, causing them to miss the avatar.

There are two problems with that. You can't prevent the damage done by objects using llSetDamage. A bullet using llSetDamage doesn't die when it collides with other objects unless they are scripted by the creator to do so. They only die if they collide with an avatar (and kill them). You can't just force other objects to die.

It sounds like you don't have any access to the projectiles themselves, because they're probably created by other people with no respect to your barrier. In that case, no script will help you. You simply need a thick enough prim to make sure the projectile isn't moving so fast that the physics will "skip" through the wall between physics updates. In SL, the positions of physical objects are updated 45 times per second. If the projectile is flying at 150 meters per second, the wall needs to be roughly 3.33333 meters thick to reliably block it. (Or 4.44444 meters if the projectile is moving at 200m/s.) You can calculate the requirement yourself simply by dividing the meters per second with 45.

@Rolig Loon In response to one of your posts, lists are not required nor are they nearly as good as strings for something like this. (My first thought was lists too.) The reason why using a list for holding input/song combinations doesn't work is primarily the fact that you cannot compare the contents of lists to see if they match in LSL, unless you fully loop through both lists. While that's not a big problem for small lists, it's more code to write that does unnecessary things. You can and should use strings here instead because you can easily compare their exact contents. list combination = [1, 2, 3]; list song = [4, 5, 6]; if(combination == song) { // This happens, but it shouldn't. llOwnerSay("They match!"); }

The way I would do (and did) this is using strings! (Even though the Ocarina is a flute.) I can post my script if you're having trouble, but this should get you started: Take controls, obviously. Use a global variable string to hold a button combination. Each time a key is pressed (held&edge), add to the combination. Use a timer to clear the string if the user takes too long to play the next note. Use a global variable for each complete song, and check if the combination matches any of those.

Unless you're putting a script in every bottle, there should be no lag caused by a script like that. Go for it!

There are many different functions for sending messages, like llSay/Whisper/Shout, llRegionSay, and llRegionSayTo. http://wiki.secondlife.com/wiki/Category:LSL_Communications You just need a listen event in the object you want to communicate with. http://wiki.secondlife.com/wiki/Listen

Off-topic question, but you don't need any timers at all for AOs anymore, right? The new functions got rid of that hassle.

You would use.. llList2Vector and llList2Rotation with params in the first object to get the values. llSay or llRegionSay/llRegionSayTo to send the values to other objects. llParseString2List or llGetSubString in the second object's listen event to translate the received message into usable values. llSetPrimitiveParams or llSetPos/llSetRegionPos and llSetRot to apply the values in the second object. There are small differences in the functions I suggested that may or may not make a difference in your use-case. Use the wiki to determine which ones fit the best.

You could just add a check at the start of moving_end(): If( dice1 != 0 ) return; This ignores the rest of the event if you already have a result. But I would recommend trying to use something other than moving_start(), because it might trigger sooner than when you want it to. One option is a short timer and/or a llGetVel() check.

What really matters though, is the definition of "nearby" and the exact use-case. (Volume detect prims might be a bit impractical.) A third option is to use llGetAgentlist and check if the target avatar is in that list, and possibly the distance of that avatar from the object. This is a better option than sensors and more versatile than collisions.

For the sake of simplicity, I've taken the simplest to understand script from that old thread and made it a lot easier to read/add to a script. This is a user-defined function. You can copy-paste this to the top of your script, and then use it to give the current die value to whatever you want. integer DiceResult() { rotation current = llGetRot(); vector axis = llRot2Up(current); // Object's local Z axis if(llFabs(axis.z) > 0.5) { if(axis.z > 0) // Top face is up { return 1; } else // Bottom { return 6; } } axis = llRot2Left(current); // Object's local Y axis if(llFabs(axis.z) > 0.5) { if(axis.z > 0) // Left face is up { return 3; } else // Right { return 4; } } axis = llRot2Fwd(current); // Object's local X axis if(llFabs(axis.z) > 0.5) { if(axis.z > 0) // Forward face is up { return 2; } else // Back { return 5; } } return 0; // If you get 0, there was an error. } And to use it, you could simply do: default { touch_start(integer total_number) { llOwnerSay( (string)DiceResult() ); } }

Innula's answer is perfectly fine, but I'd like to share my alternative method. touch_start(integer n) { if(llDetectedKey(0) != llGetOwner()) return; // code as normal } It's short, sweet, and self-contained on one line. The reason why I prefer this method (using return which ends the current function), is simply because this way I do not need to insert brackets and indent my code. And to explain that line a little more in-depth, here's an illustration of the "full length" code and how it becomes that short: if(llDetectedKey(0) != llGetOwner()) { return; } // Which becomes: if(llDetectedKey(0) != llGetOwner()) return; // Which becomes: if(llDetectedKey(0) != llGetOwner()) return; The curly braces of an IF statement can be left out if you only need to execute one statement when the check is successful. Multiple statements can be on the same line, the only thing that matters is the semicolons at the end of each statement. Whenever I leave out the braces, I put the one statement on the same line to avoid confusion that might come from putting it on the line below. This is purely a stylistic choice.