Wulfie Reanimator

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.

if your friend had edit rights to objects rezzed by you (which were transferrable) and your friend linked your objects to their own objects, the ownership of your objects was transferred over to your friend. She now owns all of the objects, so you can't take them back or delete them without permissions. In case that was confusing: you own an on object the object is Transfer your friend links that object to someone else's object the object now belongs to someone else

It isn't. Just hold your "jump" key, assuming you know how to jump.

Without doing any kind of tests myself, I would guess that a simple llGetAgentSize or similar avatar-specific function could be used to check whether the avatar is known to the region. That might not work for many reasons, but if you just want a delay, llSleep will work. But there's no knowing what amount of delay is enough for all cases, and adding artificial lag back into your script kind of defeats the purpose of fast region crossings. It's also possible that these issues could be avoided by writing a new script from scratch, but that's not always desirable either.

Ah, this went off the rails very quickly. I thought this was going to be a technical discussion. Personally I just want someone to upload the internet to my brain, and my brain to the internet after my death. That's enough transhumanism for me.

https://marketplace.secondlife.com/p/P-Ungulate-Legs-Regalia-MASCULINE-rez-to-unpack/19779221 https://marketplace.secondlife.com/p/BBMM-Equus-Legs-Regalia-Fatpack/19282250 https://marketplace.secondlife.com/p/BBMM-Corvus-Legs-Regalia-Fatpack/19018680 https://marketplace.secondlife.com/p/C-Regalia-Raptor-Feets/18329972 Some furry bodies come with human feet as a built-in option, other times, people will make an addon that's worn at the same time as the body itself.

We don't blame the people who buy what's available. We blame the creators second and LL first, for enabling creators to bring us into this situation we're in. The best solution we have is a reforming of the Complexity calculation (called project ARCTAN in the past, if that's still around), which should cause most complexity numbers to shoot up because the vast majority of SL content exploits Complexity, knowingly or not. Once LL gives people a new framework to work within, it'll naturally guide most people to better practices the same way as up until now the "best practice" has been exploits.

The stated reason for the UV map is (I'm paraphrasing) to make it easier for creators to make "seamless" textures for the body, since it's all one connected texture. LL isn't "lying," they're just dumb. The way Complexity is officially calculated is flawed and easily exploitable.

The biggest technical hurdle LL would have to solve is the fact that anyone can change the world in any unpredictable way. Sure, you can have multiple instances of a sim, so that 500 people can exist within it, even if only up to 100 of them can see each other. But what happens when somebody rezzes an object? Does that object get rezzed in every shard? And what happens when objects are scripted to interact with avatars, such as speak to them or even follow them? It would be pretty weird to see objects floating about and interacting with non-existing avatars. Or maybe whenever a new shard is created, it starts from some backup save and the changes in one shard don't affect another. But then what decides that backup point and how do you make sure it can't be used to exploit something like the permission system? What happens when an avatar leaves the sim (shard) and immediately teleports back in, into a different shard which might be in a slightly/completely different state? Even the persistent worlds of other games are relatively static, with the dynamic content (items you can pick up, enemies, some mini-events, etc) being separate but predictable because the players are inherently more limited in their abilities to affect permanent free-form change in the world.

Shards are definitely used for persistent worlds as well, it could theoretically work for Second Life, but probably not in practice. Regardless of what we call it -- you'll have to explain what you mean by "sharding." Otherwise this convo is going to be pretty aimless.

Easiest way to freeze the viewer with a snapshot is to increase the resolution. Make sure you're not trying to do 4K shots or something. Or if you are, expect the freeze.

Ah sorry, I think I understand now after also re-reading the earlier comments. If you rented land on the last day of the month, you would get charged for that month. If you then release the land on the next day, you would get charged for that month as well. If instead you rented land on the first day of the month, you would only be charged once. That does sound a bit backwards.