Wulfie Reanimator

This function moves a list of linked prims within a linkset so that the first link will be centered at target. I've included an example where a set of 4 prims are rotated 0.5 meters from the center of the root over time. SubLinksetMove(list links, vector target) { list positions; integer length = llGetListLength(links); integer i; // Get local positions of all links. while(i < length) { integer prim = llList2Integer(links, i); list localPos = llGetLinkPrimitiveParams(prim, [PRIM_POS_LOCAL]); positions += localPos; ++i; } // Get each prim's position relative to the first prim. // Must be done in reverse because the first prim's pos is used. i = length-1; while(i >= 0) { vector primLocal = llList2Vector(positions, i); vector primRelative = primLocal - llList2Vector(positions, 0); positions = llListReplaceList(positions, [primRelative], i, i); --i; } // Start compiling the SLPPF arguments. i = 0; list data; while(i < length) { data += [PRIM_LINK_TARGET, llList2Integer(links, i), PRIM_POS_LOCAL, target + llList2Vector(positions, i)]; ++i; } llSetLinkPrimitiveParamsFast(1, data); // Do the thing! } vector dir = <0.5, 0, 0>; default { state_entry() { llSetTimerEvent(0.05); } timer() { SubLinksetMove([2, 3, 4, 5], dir * llEuler2Rot(<0, 0, llGetTime()>)); } } Here's a short 5 second clip of it in-world. P.S. There's some optional to-dos here, like setting rotation as well, and optimizing the code some. I chose not to nitpick with optimizations so the script could be as simple to follow as possible. For the non-scripters, this does not mean that the function is laggy.

Okay, I can accept that and I kind of did with "1L." I live in euro-land so we have the amount followed by currency as well. I absolutely agree with this.

The rest of your post is fine, but I find this logic flawed. 1. You can't buy single lindens, and even if you could, the overhead fees would raise that number by a lot. You can't turn that 5 cents into lindens no matter how hard you try. 2. While you can get free lindens easily, I don't want to camp for 10+ minutes or go on a treasure hunt inworld just so I can gift a demo to my alt. It's going to be faster and more convenient for me to just log onto my alt. P.S. The way you abbreviate linden dollars also really bothers me. It's either L$1 or 1L, not $L1 or L1. (I would add a happy emoji but phones are difficult.)

The simplest reason I can come up with is "to stop copybotters." Misguided as that may be.

What does the object itself look like? Is it a linkset? It's not uncommon for the root to have little to no inventory, while the scripts are in a child prim, making the object look empty on quick inspection.

Two things: 1. Attachments don't make good enough use of LODs because the distance calculations are fudged by LL. 2. Auto-generated LODs don't look good and aren't nearly as functional. Removing the option for user-generated LODs is punishing those who do use them properly.

It's not necessary for the sim to tell what to do after an animation stops. Animations are played client-side and the viewer has the data of all animations playing on all avatars. The sim should only need to send information about status changes and let the client do the "heavy lifting" locally.

I've not tested anything so I could be totally wrong, BUT, based on the animation explorer, the internal SL animation for any given state is always playing. This is why we have a priority system. Animations are applied in layers. Higher priority (the looping anim) will override the internal animation and once it is stopped, I would make the logical assumption that the animation should get removed from the active animation list and stop overriding the internal animation as a result, which should then simply continue playing even without state changes.

In my example (that I did in an evening), you only need one script for everything to be lined up. (Call it the "base plate" like you would have in LEGO.) Putting a script in every prim would be massive overkill and the scripts should delete themselves after the aligning process even if you went that route.

It's only visually simpler. Replace the cubes with LEGOs and you've got the perfect product right there. Also.. There's a big (84) collection of fullperm Minecraft textures that've been circulating for years. I know because I uploaded them. It shouldn't be surprising why those aren't being sold on MP/SL though. It's copyright-infringing.

It's totally doable. I made a little proof of concept out of curiosity and it's simpler than you might expect, the important thing is to pick a sizing-standard to follow and that way you can determine how to appropriately align/snap your objects in relation to each other. (In fact you don't need to care about the other prims at all. Really all you need to do is round the positioning.) Edit, some pictures to illustrate (These cubes are varying lengths with 0.2 per "segment" (where a single LEGO stud would be), sloppily placed without using in-world snapping: The script aligns them every time a new brick is linked or the linkset is touched:

Another protip about local textures -- if you edit the file that you're using as local texture, the changes will be reflected inworld as soon as you save. Local textures also have real UUIDs, so you can use your local texture in an applier for things that are otherwise no-mod like many of the mesh bodies.

Textures on faces don't have names.

Your title is a little vague, it should say "replace a texture with another." But that said, it can't be done because scripts can't get the UUID of a texture unless it is full perm. See: http://wiki.secondlife.com/wiki/LlGetTexture "NULL_KEY is returned when the owner does not have full permissions to the object and the texture is not in the prim's inventory."

I really doubt llGetParcelFlags would ever be expanded in this way. It is a bitfield function for flags, as in it compares the individual bits (on/off flags) of a whole integer. Parcel Auto Return is not a flag and it can cover any number of bits, so it's incompatible with the function. Simplest solution is to just create a new function. The most logical solution is to extend llGetParcelDetails instead. (That might sound nit-picky but my goal is to be informative.)

Oh, thread so dead. Writhing in pain. Arise arise, to post again. This thread is from 2011 and doesn't have anything to do with prim counts. P.S. We've had llGetAgentList since 2012.

.

This? EyeFreeze_01.bvh HIERARCHY ROOT hip { OFFSET 0.000000 3.130431 0.000000 CHANNELS 3 Xrotation Zrotation Yrotation JOINT mEyeLeft { OFFSET 0.000000 3.130431 0.000000 CHANNELS 3 Xrotation Zrotation Yrotation } JOINT mEyeRight { OFFSET 0.000000 3.130431 0.000000 CHANNELS 3 Xrotation Zrotation Yrotation } } MOTION Frames: 2 Frame Time: 0.050000 0.000000 43.689983 0.000000 0.000000 0.000000 0.000000 -0.000000 0.000000 0.000000 -0.000000 0.000000 0.000000 0.000000 43.689983 0.000000 0.000000 0.000000 0.000000 -0.000000 -0.100000 0.000000 -0.000000 0.100000 0.000000

I think there's a couple unrelated things being talked about. One is "llDie fails." The other is "the prim becomes a ghost." When #2 happens, the object did llDie successfully and no longer exists in the sim. It's just a client-side error caused by packet loss. I'm not sure how this might be fixed by updating the object before llDie. I would advice the same as Fionalein, setting the object's temp status before llDie would definitely make it more likely to get cleaned up even at sim/parcel borders where they might otherwise get stuck.

@LittleMe Jewell: No offense but please do not continue with this, it's not relevant to the thread.

Not really. You should contact whoever owns the land and make a complaint about the person. Alternatively, you can just derender their skybox.

Take a deep breath. Open your inventory.

What the heck is wrong with you guys being so petty about previous threads? Grow up and just focus on the task at hand. I don't care who started it, it's so fricking frustrating having to shift through this stuff. Just let it go already and go sit in your own corners. Here's a script I wrote in about 10 minutes, I've tested it and it should work. (See edit.) Drop the script in and then the script you want to share to the whole object. The script will delete itself and the script you put into the object, but not the ones it sent to every other prim. string scriptToSend; integer alreadySent; default { changed(integer change) { if(change & CHANGED_INVENTORY && alreadySent == FALSE) { integer contentScriptCount = llGetInventoryNumber(INVENTORY_SCRIPT); while(contentScriptCount--) { if(llGetInventoryName(INVENTORY_SCRIPT, contentScriptCount) != llGetScriptName()) scriptToSend = llGetInventoryName(INVENTORY_SCRIPT, contentScriptCount); } if(scriptToSend == "") return; // Stop and do nothing if a script isn't found. llOwnerSay("Starting.."); integer objectPrimCount = llGetNumberOfPrims(); while(objectPrimCount) { llGiveInventory(llGetLinkKey(objectPrimCount--), scriptToSend); } alreadySent = TRUE; llOwnerSay("Finished!"); llRemoveInventory(scriptToSend); llRemoveInventory(llGetScriptName()); } } } Edit; Right, the "arrives-disabled" thing. You can recompile all scripts in the object by selecting the tree (or multiple trees!), and going to Build > Scripts > Recompile Scripts (Mono). It'll open a little window showing the progress of the process, you don't have to do anything but wait. Pro-tip: You can click on the top of the little sub-menu that has the Recompile Scripts button on it to pin it on your screen, that way you don't have to open it every time you click on it.

This may get some mixed reactions but I like me some Ken Ashcorp. Don't let the art discourage you from enjoying the performance. https://youtu.be/zH_RlepY3GQ https://youtu.be/wX78KhD04N8 https://youtu.be/QIFn0wqZx7Y

Why does it seem like there's usually sex involved? I also had an incident recently where I had fallen asleep with SL open and some guy had gotten into my little shoebox at 4000m just to beg me for pixel bumping. He stayed in chat range for about 50 mins before getting tired of waiting for a response.