Wulfie Reanimator

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.

No, you don't need to have "modify" permission in order for a HUD to work. If the object contains a script, the permissions on that object don't affect it. Basically, an object can always modify itself.

In theory yes, but not in practice. Continuing with the 8x8 example... repeats = <1/8, 1/8, 0> This gives the tile size of 0.125, so far so good. offsets = <x/8, y/8, 0> For example, if x and y are both 0, the "tile" being displayed will be the corner in the exact middle of the texture, not the top-left corner. The position needs to be adjusted by half of the tile's size. The left column (X) tile position begins from: -0.5 + (0.125 / 2) = -0.4375. The top row (Y) tile position begins from 0.5 - (0.125 / 2) = 0.4375. A simple script to do the calculations for us... This should also work for any tilemap dimensions, I tested it with 4x8. tile(integer x, integer y, integer link, integer face) { key tilemap = "b8d4bd8b-e09b-53eb-97fd-a63b8ad23d75"; vector size; size.x = 1.0 / 8.0; size.y = 1.0 / 8.0; vector start; start.x = -0.5 + (size.x / 2.0); start.y = 0.5 - (size.y / 2.0); vector offset; offset.x = start.x + (x * size.x); offset.y = start.y - (y * size.y); llSetLinkPrimitiveParamsFast(link, [PRIM_TEXTURE, face, tilemap, size, offset, 0]); } default { state_entry() { tile(7, 7, LINK_THIS, ALL_SIDES); } } Also yes, we need more resizable HUDs. Being able to hide it is not the main problem.

You can, absolutely, mod a rigged item. The fact that the mesh is rigged only restricts size and position -- but there are literally dozens (note: plural) of other ways to modify an object. Besides, why does "you can't do it anyway" justify going out of your way to try and further prevent it? I've seen a few stores sell colors separately with the white version being more expensive than the other options. I think that's reasonable. Or you can just deal with it since I can't imagine most people (on average) buying multiple colors separately. If white is the most sold color, that doesn't necessarily mean you've lost any significant amount of money. Besides, white is not the perfect solution. If the texture has highlights, they'll get tinted too in a way that doesn't always look good (looks "flat"), so buying the other color options becomes necessary. Even if I agreed on the tinting "problem," making the object no-modify is such an oppressive solution to all customers even if they had no intentions to buy white and tint it. 99% of the time it's very easy to tell whether a script is tinting the texture or swapping the texture altogether. A color tint is instant (after script lag), but a texture swap is noticeable because the new texture needs to be downloaded and you'll visibly see the grey/blurry texture as it loads. The exception is when there are multiple variants within the same texture, and the script is simply changing the offsets, which is also instant.

First things first: VR Chat is not on the track to overtaking Second Life. It's a niche within a niche. VR Chat doesn't have as many total users as Second Life. VR Chat's all-time-high for concurrent users (never mind daily users) is way lower than Second Life's daily average. VR Chat's concurrent numbers aren't even in an upward trend. 3D chatrooms such as Second Life, VR Chat, IMVU, or any other "virtual world" are inherently harder to get into than the wider world of gaming, which is why it's never going to reach numbers like Minecraft, or most MMO ("massively multiplayer online") games. That said, Second Life is still on the top of the food-chain when it comes to others like it. You've got no reason to drink if that's your only fear.

It's not a security thing, it's purely a simplification thing. Without Omega, you as the skin/tattoo creator would have to create many appliers for different products, for example: You need to get Maitreya's dev kit to make a skin/tattoo... You need to get Catwa's dev kit to make a skin/tattoo... You need to get Apricot Paws' dev kit to make a skin/tattoo... And so on for every no-modify body-part and addon you can think of... But the body-part creators can help you by scripting their products to listen to Omega appliers. This way, you as the skin/tattoo creator only need to create an Omega applier, which will work for all of them. Omega is just an established standard that makes things easier -- it does not make your textures any more or less protected than any other applier script (or no script). You need the Omega dev kit, it's free: https://marketplace.secondlife.com/p/Omega-System-Dev-Kit/6070969

Instead of the string "happy", you get a string from the list using llList2String. You will also need a loop to iterate through every entry of the list. That's the core of what the above examples are showing you.

What I find endlessly fascinating is how someone can spend the better part of a decade doing something and not knowing pretty simple things about it. Banlines don't extend all the way into the sky. They're actually very low. Animations are purely visual, they don't actually move your avatar's location in the world. Banning an avatar from the parcel (or using your security orb) doesn't protect you from this. Bonus: You can hold Alt while clicking on a point, to focus (and orbit) your camera around it. You can sit on objects through walls and across the entire sim. Assuming your home is at ground-level, within banlines, you can also enable "parcel privacy" to hide avatars from others while you're inside and they're outside. Animation offsetting into the parcel won't allow them to see the avatars inside (because remember, animations don't change the avatar's location in the world). You won't be able to see them either. They will still be able to see your name/profile and exact location in the Nearby window, but they can't see your avatar.

Reinstalling your viewer would not fix a problem like this. You should definitely contact Linden Lab support in this case.

Yes, your tint should be set to pure white unless you have a specific reason to adjust it.

integer count = 0; default { state_entry() { llSetText("Click my head to pet me", <1,1,1>, 1.0); } touch_start(integer n) { count += 1; llSetText("I've been petted " + (string)count + " times", <1,1,1>, 1.0); } }

Add another llListen to open a listener on some other channel. Whenever you need a textbox, use that second channel for it. This way, you can do: listen(integer channel, string name, key id, string message) { if (channel == menu_channel) { // menu stuff } else if (channel == textbox_channel) { // textbox stuff } }

I checked your Marketplace and it seems like you're only selling gachas. Gachas belong into the "Gachas" category, not any other like you've done. You need to move all of your products into the correct category or all of them can be flagged as wrong category / misleading.

Another hint: Don't try literally adding another "timer() { }" into the script.

There are other changes as well. Scripted Agents won't receive messages from group chats, and some other details I can't recall off the top of my head. But generally speaking, you'll still be able to log in normally and do the things you need to do.