Wulfie Reanimator

The whole "one script in each prim" was just a result of a wide-spread script product created and used by people with no real knowledge on how to do it better. Forced delays still exist in all of the functions that had them. llSetTexture and llSetLinkTexture are still being used in mesh products today and the delay is extremely noticeable as relatively few hairs are a single piece of mesh. But note how llSetLinkTexture can have an input of -1 which means WHOLE LINKSET, so there's no need for a script in every link even if you want to use it.

This. I wouldn't even care if we got a new UI window called "advanced properties" or something with just a text field or drop list for each prim property. It's so time consuming to write a new script just to get a few properties how you want them.

The downside is that you still have to 1) rez things, and/or 2) rely on physics. Having an object and a script rez and be initialized just for ~1 second's worth of functionality before it's killed and repeated again isn't very ideal. Especially if it's supposed to be like a general area (imagine a toxic cloud) and you can't rely on the collision event and need one or more repeating sensors.

Another weird thing on a sim called Fluffy: 2222 scripts, 20% +/- 5% run each frame with ~16ms spare time.

Does this mean that you don't think gambling addiction is a real issue that affects the greater good?

That would seem fairly important, yes. I accidentally removed the line while editing my post and now we're past the 24-hour mark and the main post is locked. Here's the script again with the llListen added (so it actually works). Better yet, I also added a script reset in case someone hands this script over to someone in-world. integer channel; list attachments; // UUIDs integer count; list namedAttachments; // Final default { changed(integer change) { if(change & CHANGED_OWNER) llResetScript(); } state_entry() { channel = (integer)("0x"+llGetSubString(llGetKey(), 0, 7)); llListen(channel, "", llGetOwner(), ""); } touch_start(integer n) { if(llDetectedKey(0) != llGetOwner()) return; llTextBox( llGetOwner(), "\n\nEnter an avatar's name in this sim." + " (channel " + (string)channel + ")", channel); } listen(integer channel, string name, key id, string message) { if(llName2Key(message)) // avatar is known to this region { attachments = llGetAttachedList(llName2Key(message)); if( !(count = llGetListLength(attachments)) ) { llOwnerSay("This weirdo hasn't got a single attachment."); return; } while(count--) { key attachment = llList2Key(attachments, count); string creator = llList2String(llGetObjectDetails(attachment, [OBJECT_CREATOR]), 0); string uri = "secondlife:///app/agent/"+creator+"/about"; llOwnerSay(llKey2Name(attachment) + " " + uri); } } else llOwnerSay("No such avatar here."); } }

I understand this may have been a rhetorical question, but, you can easily care about an issue that doesn't affect you. Smoking, alcohol, gambling, poverty/welfare/unemployment/homelessness, child mortality rate, suicides, etc. are all issues that a lot of people care about even when they're not affected. I don't care about loot boxes because they don't affect me. I've played many games with them but never opened any besides the ones you get for free. However if loot boxes are going to be regulated, so should gachas because they are identical in concept. Try it, you can't distinguish a line between them.

I'm aware of the prim-to-mesh process, but the skybox didn't look like the end-result of that. The construction was consistent, there was no "prim-like" wireframe like you would get by exporting, it included shapes that are not possible with prims and a clearly separate physics shape from the model itself. There was definitely some kind of skill on display there. But I digress, it does not matter what the exact reasons are for creating a product like that. I would totally understand if it was a bunch of someone's personal objects linked together for convenience, but that wasn't the case here. It was an "as-is" commercial product, that's not okay under any circumstances and that was the point I was trying to make in my first, in my opinion obviously exaggerated post.

Certainly, but that doesn't mean I have to be accepting of it. (And I won't.) For context, that was a single, unfurnished mesh skybox with materials and normals (272 faces, 453 textures). People shouldn't do it. They will, but they shouldn't. It's absolutely horrible and a crime against limited resources.

Regarding the TOS, sexual activity with feral avatars is not a violation. Regarding the actual question, I have no idea. I'm having a hard time even imagining what you're trying to describe.

THIS 👏 NEEDS 👏 TO 👏 STOP 👏

But the concept of a "gatcha" is not unique to SL, far from it. It also exists in real life, and the "loot box laws" don't even try to cover them. The official point of view is the Gatcha category on the Marketplace.

Sorry, but this has absolutely nothing to do with scripting, LSL, or even Second Life. It doesn't belong here. At best, you could try asking this in General Discussions.

Local textures have UUIDs even though they haven't been uploaded. You can get the local texture's UUID with just llGetTexture. You can then put that UUID into the third-party applier and apply it exactly like a real texture and still be able to edit it "live" on your computer.

You know, if you use Local Textures instead of uploading them, you can edit the local texture's file on your computer and save it to have it "automagically" update in-world.

SL is already in the process of migrating to Amazon's Cloud Service.

But I love hamburgers!!

This is actually caused by a simple FPS limit you can set for the viewer while it is out of focus. If you remove the limit, there is no noticeable difference in FPS while the viewer is in or out of focus. (Based on the statistics window and frame-time information.) On a more general note unrelated to SL, Windows doesn't seem to give specific windows higher processing priority. The active/inactive window system is more about handling user input.

I was bored, tired of trying to right-click on someone's rigged attachment without an extra prim, and apparently some people pay for this. So, here's a very simple script you'd wear on your HUD, click on it to get a text box, and type in the username of anyone on the sim. The script will then go through all of the public attachments (not HUDs) that person is wearing and list their names into chat with a clickable link to the creator's profile. (Example below) integer channel; list attachments; // UUIDs integer count; list namedAttachments; // Final default { state_entry() { channel = (integer)("0x"+llGetSubString(llGetKey(), 0, 7)); } touch_start(integer n) { if(llDetectedKey(0) != llGetOwner()) return; llTextBox( llGetOwner(), "\n\nEnter an avatar's name in this sim." + " (channel " + (string)channel + ")", channel); } listen(integer channel, string name, key id, string message) { if(llName2Key(message)) // avatar is known to this region { attachments = llGetAttachedList(llName2Key(message)); if( !(count = llGetListLength(attachments)) ) { llOwnerSay("This weirdo hasn't got a single attachment."); return; } while(count--) { key attachment = llList2Key(attachments, count); string creator = llList2String(llGetObjectDetails(attachment, [OBJECT_CREATOR]), 0); string uri = "secondlife:///app/agent/"+creator+"/about"; llOwnerSay(llKey2Name(attachment) + " " + uri); } } else llOwnerSay("No such avatar here."); } } Example output of a friend's current attachments: Each attachment is said separately because of the character limit on llOwnerSay, which isn't enough to show all attachments at once in most cases.

Just to chime in on this a little bit to clarify my earlier post: The main reason why I would demand different UI options from the LL viewer is because the LL default UI takes far too much space on the screen in every aspect, but there are also some weird annoyances that I can't really logically explain why. As an example from BD (I think this was the same in LL viewer?), the Conversations window. On Firestorm, the vertical tabs (which I can rearrange) are on the left and the chatbox is on the right. On BD, it's the opposite and there's this weird uncomfortable feeling having it that way around and/or keeping my conversations window on the right side of the screen rather than left. It's like swapping the knife and fork -- I can do it and bear with it for a while, but it does not feel natural because I've been doing it the other way for so long. Not to mention that I can't think of a single game where the chat defaults to the right side of the screen.

There's a lot of repeating ourselves from a lot of sides, including me literally quoting myself, lol. Inevitable after 30 pages on any subject.

This also perfectly demonstrates that it's not really possible in practice to have two different bodies that both support the same UV layout equally. Super easy example: Find an Omega applier that works perfectly for Maitreya or Belleza. Then try it on the other body and look at the toes. You won't find a texture that works for both at the same time.

If creators were to adjust the UV mapping of their bodies to work seamlessly with BOM, all of the existing appliers would start having issues instead. "But what about having a separate BOM body?" said the Strawman. To that I say "Why didn't the creators make onion layers separate from the body? BOM would've probably never come around if that was the default MO."

A good first step would be to implement some quality-of-life features present in the TPVs, and offering alternative UI (maybe as a hidden option to protect the "new user experience" they want).

I would greatly prefer this over the current Firestorm implementation, of which I am deeply guilty of exploiting. I can't help it, I'm curious as frick but lord help me if somebody sees me oogling.