Wulfie Reanimator

Why? There's rarely ever a need to restart the whole script every time it's attached or detached. Considering the simplicity of what's being done, everything could be done in a single attach event (or formally with the help of run_time_permissions). default { attach(key avatar_uuid) { if (avatar_uuid != NULL_KEY) { llRequestPermissions(avatar_uuid, PERMISSION_TRIGGER_ANIMATION); llPlaySound(" --SOUND UUID1-- ", 1); llSleep(15); llPlaySound(" --SOUND UUID2-- ", 1); llSleep(30); llPlaySound(" --SOUND UUID3-- ", 1); llSleep(20); llStartAnimation(" --Inventory Animation-- "); llPlaySound(" --SOUND UUID4-- ", 1); } } } Each time the script is attached (avatar_uuid is not set to NULL_KEY), the sequence will begin. llRequestPermissions is made for the current owner and PERMISSION_TRIGGER_ANIMATIONS will be automatically granted because the object is attached.

No, only objects that exist in the world can have running scripts. Scripts in your inventory, or in objects within objects, can't run.

Yes, it can simply be left out. Your second bit of code has two big problems. You can't put an event inside of another event. Move touch_start out of state_entry. if (on = FALSE) is an assignment, not a comparison. You are always assigning a false value to "on" and the test will never pass. All variables are initially set to zero, or an empty string/list. It's not necessary to give them that value, but it helps with clarity. "on = FALSE" is an assignment. It gives a value to "on". "!on" is an expression. It does something that results into some value. "!" is the logical "not" operator. It switches any nonzero ("true") value to zero ("false"), and vice versa. The value is not assigned to anything, so the value of "on" does not change.

Personally speaking, I don't mind if someone is unhappy with my product because it doesn't work after the user has edited it. Either the edits they're doing is something I can't reasonably expect, or what they're trying to do is simply more complicated than what I intended (and I'm not obligated to fill their needs), or the product is actually flawed or poorly designed (and it's up to me to improve the product as a whole). Could you clarify what you mean by "they wanted a mod version ... and I didn't want to do a custom job?" It sounded like that other person was going to be the one doing the work, or did you mean changing the permissions? Sure, it can be tedious to re-perm an object (I often just can't be bothered to fill random requests while I'm in-world) but tedium aside, what reason was there for the object to be no-modify to begin with?

Multiply time by some value. float time = llGetTime(); // 100% speed float time = llGetTime() * 2; // 200% speed float time = llGetTime() * 0.25; // 25% speed

Works on mobile too. Tap and hold. @Marianne Little Long quotes are automatically shortened and can be "closed" to save even more space. (You'll see that if you quote my post, because of the long image.) You can add a quote (without actually quoting anyone) with this button:

I mean, you can do it like that, but to what benefit? In my opinion that's just overcomplicating the problem.

I still don't understand. The only reason why you'd use two scripts is to have the infinite loop part in the second script -- and nothing else: default { state_entry() { while (1) { float time = llGetTime(); rotation r = llEuler2Rot(<time,0,0>) * llEuler2Rot(<0,time,0>) * llEuler2Rot(<0,0,time>); llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROTATION, r]); } } } And then you have the main script that does everything else, including llSetScriptState to control the above script. There would be no "stopping the loop to receive commands."

No, OpenGL (and any other well-established graphics API) is able to support any arbitrary size image. It's completely trivial in principle, but there are probably some kind of technical reasons (such as optimizations) for LL to limit texture sizes to a set range.

What do you mean by "stutter" exactly? Can you demonstrate? Also, llSetScriptState should not be confused with llResetOtherScript. llSetScriptState will simply "suspend" the script the same way as the sim would when it's put into a schedule to wait for its turn to run. When the script continues, it will continue exactly from where it left off (mid-loop) as you'd normally expect. I'd appreciate it, it looks very cool! I'll send some lindens your way as a thank you when I get it. If I remove the llSleep and run your script, it rotates as smoothly as the script I used in my video, so the problem is probably just the sim you're in. Not much you can do about that. (Well, besides attempting to get KFM working, but that'd require unlinking parts of your object.)

You can also use llSetScriptState instead, to not spend time polling for external data.

It's hard to make any definitive conclusions without seeing the involved code, but most likely, exchange_curr is not actually set correctly. Functions can't know whether they've been given a variable or its data, there's no distinction in LSL. This works, for example: string json = "{\"rates\":{\"USD\":1,\"AED\":3.67,\"ARS\":78.93,\"AUD\":1.38,\"GBP\":0.761,\"GTQ\":7.78,\"HKD\":7.75,\"HRK\":6.37}}"; string exchange_curr = "GBP"; llOwnerSay(llJsonGetValue(json, ["rates", exchange_curr]));

If your original work is 4:3, it'll be reduced to 4:2 on upload, but you can still create a 4:3 surface to display it on. This will essentially "stretch it back" into its intended dimensions. The only thing you lose is quality -- but that will happen even if your original work is exactly 1024x1024 (for example). It's just the nature of SL's texture format.

No, a script cannot process new events until the current one ends. An event can't end before the loop ends. And infinite loops... The smoothness is affected by script lag in the region. You could show your script just in case. Also, is that thing you showed available inworld somewhere?

I used an infinite loop that only contains the three lines of code I've shown in the previous post. Triggering a separate event for each update has significant overhead compared to a single loop that simply pauses and continues. Of course, infinite loops aren't usually practical.

Builder's Brewery still has free scheduled classes.

Well, I wasn't exactly responding to you, I was more focused on the math they were explaining, to explain to them how SL offsets affect their (kind of correct) math. You don't need that math since you've just figured them out by hand (which is fine, I need a lot of fumbling as well). The texture rotation is only necessary depending on which way the face is rotated. I assume you're using cube prims, so if you haven't rotated the cubes at all, the side that's visible on your HUD is the object's west surface (negative X direction).

I'm aware of #5 but it's enabled by default and if I bought something on MP without redelivery enabled (aside from some specific use-cases), that'd be a big no from me in the future regardless of the permissions. #6 applies to every redelivery system, servers don't have 100% uptime. That doesn't mean the option is useless and I don't understand what your overall point is. "Redelivery isn't always reliable, so no-modify is justifiable so redelivery isn't needed?" Or are you just making the point that redelivery isn't always reliable? What do we infer from that?

You can't export mesh just because it's modifiable... What on earth gave you that idea? Have you tried? Marketplace has redelivery built-in, no need for any external systems. Doesn't apply for in-world purchases I guess.

Trust me I know. I do the exact same thing, here on the forum and in-world. But wanting to do that when it's not necessary is different. If you choose that you want to provide customer service, that doesn't justify removing features once you get fed up with it. (Remember, the original claim was that "no-mod is used because people don't want to deal with customer service.")

All of the "customer service" in this case just comes down to customer self-service. You tell them how to get a redelivery and that's it. Spending time trying to fix their broken product is folly, unless it's a problem the creator themselves has caused.

What does it mean to "rotate around all three axes simultaneously" and why isn't it exactly what llTargetOmega does? After looking at your code, it seems to me that you want the axis of rotation to change over time. This can be done relatively simply by combining 3 separate rotations (for each axis). So let's start small, how do we rotate around one axis over time? float time = llGetTime(); rotation r = llEuler2Rot(<time, 0, 0>); llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROTATION, r]); Simple enough, we can also change the rate by multiplying time. But how do we combine two rotations? The LSL wiki (as complex as it may seem) tells us that two rotations can be combined by "multiplying" them together. rotation r = llEuler2Rot(<time, 0, 0>) * llEuler2Rot(<0, time*0.5, 0>); This'll make the object spin around the (world's) X axis and half the rate for Y axis. It'll make it "wobble" a bit. If the rates were the same, it'd repeat a certain pattern every pi seconds. The more different the rates are (especially if they're not multiples of each other), the longer and less obvious the pattern becomes. Adding the third axis is no different. rotation r = llEuler2Rot(<time, 0, 0>) * llEuler2Rot(<0, time*0.5, 0>) * llEuler2Rot(<0, 0, time*2>); Here's the result.

That's right, if you haven't specifically filtered out other people, anybody can use the command.

I don't even know what the griefer thing means because there are so many different ways to mess with people. You can't modify something you don't own unless that thing is scripted to make changes to itself based on outside forces. (chat messages, usually) Even then, those "outside forces" can be limited only to the current owner of that object, like most clothing/attachment HUDs work. (So that I can't walk into a club with my HUDs and click buttons to mess up everybody else's clothes.) Poorly scripted clothes might listen to others, but that's the creator's fault. I could come inworld to explain. Not true.

You never did own your stuff, ever. What you had was an illusion of self-assurance. Despite that "you knew where the servers were," you never owned those servers. You never owned your land, you can only rent it. You don't own anything in your inventory. Linden Lab, according to their own TOS, owns all of that data and when the time comes for Second Life to close its doors, everything you "own" will vanish into the void as if it never existed. No refunds either. Linden Lab allowing Second Life to grow even bigger (did you know they literally ran out of sims?) by migrating their datacenter over to Amazon has made no difference to our circumstances as residents. All assets within Second Life (including your inventory) has been on AWS for years by this point as well. If you're going to boycott any business that affiliates with Amazon, you're going to have a very, very small world on the internet because they offer such a wide variety of services. Name your top 5 favorite companies or daily activities and I'm sure you'll run into Amazon on at least 3 of them.