Wulfie Reanimator

High poly does not mean high quality. Others doing it doesn't mean your work is not good enough. Fenix is absolutely on point.

Are you using llMoveToTarget? That function only works in physics-enabled objects and as an attachment the avatsr is the "physics-enabled object." If you want to only move the attachment itself, yoj must use some other function like llSetPos, which unfortunately isn't smooth like llMoveToTarget, so you will need to use smaller increments while moving from A to B. For more specific info, seeing the object would probably get you more specific advice, or showing the script (the part that moves) would show us what the problem is exactly.

Way to go right back off-topic. That's such a specific thing that you'll probably need a 3D modeler. Offering them 3-6k (I'm assuming lindens) for a custom avatar job is going to be an insult. Double that number -- at least -- and let them sell it on Marketplace if you can't afford to go higher.

Even if it was possible to do an "inworld click" with another script, that would only be even more unreliable than another program on your computer. Each script has a separate timer, there is no single "inworld timer." Scripts don't run all at the same time in most cases either. Some scripts are "put on hold" by the sim when all the "slices" from the "script time pie" inevitably run out.

OP wants an actual click / touch on the other object. This cannot be done with LSL, you need some other program on your PC like AutoHotKey to work as an autoclicker independent of SL. But even that can be unreliable because scripts are vulnerable to lag, so the timer may not start exactly on the first click, and the second click might not trigger instantly.

Re-linking the entire set would make more sense than unlinking just the root alone. I've never experienced the root prim getting changed without the builder making a mistake in selecting the wrong thing in the wrong order. Even then, I don't remember ever experiencing the links changing order aside from the Build window, which is just a visual bug and scripts still report the correct order. No real harm doing that routine though. Whatever works!

Why does the root need to be unlinked?

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!