Wulfie Reanimator

That's fine, but I bet you're not using the official LL viewer to log into Second Life.

It depends entirely on how the object is scripted. You can't leash to yourself currently because the script is made to ignore either you or all avatars.

Not quite. I assume the HUD name is always the same, regardless of owner? Meaning if I had the HUD, it would be called "Some HUD" and if someone else had the same HUD, it would also be called "Some HUD". If your listener is acting on all messages heard from an object called "Some HUD", it's easy for me to break all of your products. A channel generated directly from the owner's key is not unique nor secure. "0x"+(string)ID creates a hexadecimal number with 4 bytes (8 characters, like 0x12345678). default { state_entry() { string avatar = llGetOwner(); llOwnerSay(avatar); // output: "779e1d56-5500-4e22-940a-cd7b5adddbe0" string hexadecimal = "0x" + avatar; llOwnerSay(hexadecimal); // output: "0x779e1d56-5500-4e22-940a-cd7b5adddbe0" integer number = (integer)hexadecimal; llOwnerSay((string)number); // output: "2006850902" (= 0x779E1D56) } } Note that the first part of a UUID is 8 characters long. It's the same number. The first problem is that there may exist other avatars who have a key that is identical no matter which 8 characters you pick. You can't pick more characters because they'll be ignored when typecast to an integer. Besides that, if I create a new object and rename it to "Some HUD", I can just put my own script in there so it starts sending random messages on channels based on the avatars around me. Even if I don't know which part of the key you're using, the options are pretty limited and I can just send messages within ~200 channel range of different parts of the key. For these reasons, you absolutely should add an additional check to make sure that "Some HUD" is owned by the same owner.

That's not true. The signin page asks for Speedlight account details. You can't login with your SL account. I created an account and added a very old test alt. Here's where you have to finally enter your password. And here we are: I can see the avatar in-world and I sent a test IM. Inventory management: No 3D view.

Are you able to edit the script? All you really need to do is set the leash target to be whoever should be holding the leash, instead of any other object. There's no real difference between avatars and objects as far as "scripted leashes" are concerned.

This does not limit the listener to objects owned by the owner. In that line of code you've created a listener that will never hear anything, because it's listening for a specific object name and a specific avatar key. By definition that's impossible to satisfy, you have to leave out the llGetOwner part and check for llGetOwnerKey separately. See: default { state_entry() { llListen(0, "Object", llGetOwner(), ""); } listen(integer channel, string name, key id, string message) { llOwnerSay("Heard!"); // Will never happen. } } Instead, you need: default { state_entry() { llListen(0, "Object", "", ""); } listen(integer channel, string name, key id, string message) { if (llGetOwnerKey(id) != llGetOwner()) return; // Heard a message from something owned by owner. } } Listens won't "just disappear by itself." It's good practice to close listens when they aren't needed. However in the case of scripted communication, there's no real way to "re-open" a listen without the user directly interacting with the clothing itself. I would just let the listen live forever with the channel and object-name filters.

This is just what happens because of how pages are cached. The search results page is showing an old version of what was in the profile contents.

Following this logic, all of the things you personally experience are fake because they're just signals in your brain.

No idea to be honest... it just irked me a bit So I thought. You shouldn't be irked by something you don't even know to be meaningful. Of all the things you could've been irked by, you chose the worst option.

Is there an actual measurable difference or is this one of those "old traditions?"

Because as you all know, the USD is worthless.

Curious speculation: What if the real fraud is that it's the owner of the account that does the purchase but then falsely claims to LL that their account was stolen in order to get their money back? All that's needed is a proxy server.

Probably running on page files...

The first quote refers specifically to the Linden Dollar Exchange, so that's probably not relevant. The second one though, is pretty literal and the bit they're enforcing in your case. When someone's account gets stolen and that account has payment info on file, the thief can buy more lindens without consent from the owner, which is fraudulent. The thief then spends that fraudulent money to buy your item, so you are now "associated" with the fraud because you have received ("are holding") fraudulent lindens and LL will take that away from you. The lindens you have bought aren't fraudulent, just the ones you received through sales. By the time the lindens are being taken away from you, the stolen account (the source of the fraud) is already under lock and key.

Yes. You can imagine a list as an "array of boxes" or slots or whatever. You would have all 18 textures in a single list, all in the same order. Here's a visual (pardon my poor digital handwriting): Index 0-2 are for the first texture, each with the different kinds of sheer. Index 3-5 are for the second texture, and so on. No. You should add the "level of sheer" to the end of the name of the button you're sending. Change the following: llRegionSayTo(llGetOwner(), cmdChannel, button); llRegionSayTo(llGetOwner(), cmdChannel, button + "_" + (string)sheer); This way, instead of "button_01" you send "button_01_0". Now you've sent the two numbers needed for the clothing to figure out exactly which texture to apply. You would of course need to add just 3 if-checks into the HUD so that you can change the "sheer" value, based on which of the three options you've clicked on. I believe you would also need to remove the "0" from "01" (and any other numbers that begin with 0) because it won't convert to an integer correctly. I might be wrong, but anyway. Then, when you have the two numbers, you know which index to start from (0 to 5, multiplied by 3 because of the amount of variants, giving you a starting index of 0, 3, 6, 9, 12 or 15), and how many indexes to move forward from that (0, 1, or 2) to get the correct sheer texture. This is definitely a reusable technique that you'll be able to use whenever you have variants for each texture. Not the way your current convention works, I think. What I'm suggesting is going to address exactly that.

Are the feet finally rigged for resizing? Wasn't script removal already a thing?

You cannot delete any posts. A moderator has to do that. You could report your own post and request that it be removed.

OH. It's super clear now, thanks for that. If you rename your buttons a little, you could get rid of all the if-checks and use my list method. For example: Let's assign your sheer options some simple values: 0, 1, and 2. Let's do the same thing for the textures: 0, 1, 2, 3, 4, and 5. So the first button would be called "texture_0_" and the last one is "texture_5_" Based on that, you can write your HUD like this: integer sheer; // 0, 1, 2 default { touch_start(integer n) { string link = llGetLinkName(llDetectedLinkNumber(0)); if (link == "sheer 90") { sheer = 0; } // ... else // Not a sheer option { // In this case it sends the message "texture_0_0" llRegionSayTo(llGetOwner(), CHANNEL, link + (string)sheer); } } } The reason why we're counting from zero is because that's how list indexes work... // "texture_01_sheer_90", "texture_01_sheer_80", "texture_01_sheer_60" list textures = ["UUID", "UUID", "UUID"]; default { listen(integer channel, string name, key id, string message) { // In this case, parameters = ["texture", "0", "0"]; list parameters = llParseString2List(message, ["_"], []); // Multiply the first index by 3 because we have 3 variants for each texture. integer index = (llList2Integer(parameters, 1) * 3) + llList2Integer(parameters, 2); string uuid = llList2String(textures, index); } } (0 * 3) + 0 = index 0; First texture with 90 sheer. (5 * 3) + 2 = index 17; Last texture with 60 sheer. That covers all 18 textures.

Ah, I see what you mean. Both Twitch and Youtube give an error about the browser (in-world media) not supporting the stream format.

It sounds like you've created what's basically a small/"indie" version of Twitch/Youtube Live. I can imagine that being a pretty complex project. But for practical reasons, why wouldn't you use the already existing streaming services to do the same thing?

You talked about "DreamVision" but did not provide any links to it or explain how to use it. You linked your club. You linked a Facebook profile for your club. Searching for "DreamVision" brings up a fursuit maker and an actual home theater system "since 1996." Bad advertisement and deflection is bad.

[Moderator Edit: Image with profanity removed]

Just to recap, to make sure I've understood it correctly: 6 textures. 3 variations of each texture. You want the "variant" to stay when the texture is changed. (Or just know which one to apply?) Either way, you want to get rid of the big if-else tree. I guess my first question is why would you need 36 if-else checks if you only have 18 textures / buttons with unique names? You should only need 18 at most. if (message == "texture_01_sheer_90") { // Do stuff; } else if (message == "texture_01_sheer_80") { // Do stuff; } else if (message == "texture_01_sheer_60") { // Do stuff; } else if (message == "texture_02_sheer_90") { // Do stuff; } Right? Alternatively, you could name your buttons something like "texture1", "texture2", "texture3" and so on. Then you have an ordered list in the clothing item, which uses the number as an index of that list. Then you won't need any if-checks (besides making sure you're getting correct input). list textures = ["UUID", "UUID","UUID", "UUID"]; listen(integer channel, string name, key id, string message) { // 7 is the length of "texture", -1 means "end of string" integer index = (integer)llGetSubString(message, 7, -1); string uuid = llList2String(textures, index); llSetLinkTexture(LINK_SET, uuid, ALL_SIDES); }

What's your next tip? Keep variable names as short as possible? Even if what you think was fact, you should read a book or two on "premature optimization."

I assume you're using the latest version of Firestorm, right? It's starting to sound a lot like just general network problems.