Wulfie Reanimator

It's either intentional roleplaying, or unintentional roleplaying...

imbecilic* What's ridiculous is the tone and the apparent amount of vitriol you have towards people whose primary opinion seems to be "I don't care, why do you?" which is about as neutral as you can get. This is from the blog post you linked: As far as I know, "network providers" don't provide pizza, and SL doesn't run on a cell service. That doesn't seem to satisfy your question because I know you're still very paranoid about "the cloud" as you have little understanding of it, which is fine as you are a non-technical person. But because you are a non-technical person, giving you the full answer might not satisfy you either, because you're hung on the scary "cloud" term. Lots of different things are "the cloud." There is no one "cloud network" type, the term is ambiguous and useless without proper context. Not everything has to be on "the cloud(s)" for SL to work. If you can log into any computer at your workplace/school (especially in separate buildings) and instantly get all of your files on the desktop, that's "the cloud." If you remember SL Go, that was "the cloud." (Same goes for OnLive or any game-streaming service. Cloud gaming.) If your company has ANY software that runs on a remote server, not on the same computer, that is "the cloud." This means that even if/when LL had its own server farms, they were "the cloud." Linden Lab has been using AWS for a good while now, that is "the cloud." (<-- This is the answer you want, even if unrelated to the actual problem.) A presentation of this move was done back in 2017. They've also made blog posts related to AWS even before that, but that post is a different "cloud." "The cloud" is just "a remote server that does something for you." The internet as a whole is "a cloud."

Other definitions include: "A trivial fancy adopted and pursued for a time with irrational zeal; a matter of no importance, or an important matter imperfectly understood, taken up, and urged with more zeal than sense; a whim; a crotchet; a temporary hobby." "A temporary fashion, notion, manner of conduct, etc., especially one followed enthusiastically by a group." "A style or activity that suddenly becomes popular but which usually does not stay popular for very long." So: Money trees, camping, etc. LL disincentivized them for non-legacy traffic results. New avatar releases during events, like those at Gacha Guild. The front of the vendor is full of them all day through the event, but finding one in "the wild" a couple months later is even relatively rare. The gacha system in general. I would also want to say "no-modify products in general" but I don't think that's been very temporary...

What if you set your windlight to something flat like CalWL? That looks like a regular lighting issue, not a texture problem.

Also remember to lower your settings on the viewer that isn't taking the pictures or minimize the window so rendering slows/stops.

One "simple" solution could be to host your own site that's just a blank page with some JavaScript code in it. It's like one line of code. When someone gives your LSL script a link, the script parses that link so that it only extracts the unique part for the video, eg. https://www.youtube.com/watch?v=tv1k0Z2qCHI becomes tv1k0Z2qCHI Then your script sets media using your page URL, with the JavaScript, eg. mypage.com/tv1k0Z2qCHI Then, that page is totally empty except for the JavaScript that has the information in the URL. It can then add an iframe to the empty page, embedding the requested video. The embed options also allow hiding any related videos so people can't change the video after it ends. Since JavaScript runs on each client directly, this doesn't even require any bandwidth (only enough to send the JS code) from your site, even with heavy usage. Even free web hosting options will easily handle this, as long as they allow JS.

If you're getting the debug message twice, then there is a problem with the logic of your code. It's hard to say anything beyond that unless you want to show the script.

What channel are you sending it on? 0 is displayed to the avatar if the target is an attachment.

I pay rent on a small parcel with 50 prims, 180L/month. I'm going to be unhelpful and not specify where as I don't care to advertise, but mainland is cheap. Private land aside, Premium is actually very well priced if you were willing to pay for a full year (which is a big ask, I know), as the free land and the weekly lindens you get pretty much pay themselves back.

*Sets display name to !!llTextBox!!* Also: Edit: Unfortunately "!" is not an allowed character in display names...

default { state_entry() { string test = "123456789 123456789 123†"; // 24 characters llOwnerSay("Length: " + (string)llStringLength(test)); // "Length: 24" llDialog(llGetOwner(), "test", [test], 0); // Doesn't work. } } † is a non-ASCII character. (Two bytes in UTF-8, decimal value 134, where 127 is the last one-byte character.) llStringLength recognizes that it's just one character, but llDialog doesn't want more than 24 bytes. Basically, look up any ASCII table; any character that's not on that list is more than one byte and you can't trust it. As another example, ꖅ (decimal 42373) is a character that uses 3 bytes. llDialog(llGetOwner(), "test", ["ꖅꖅꖅꖅꖅꖅꖅꖅ"], 0); // Works, string length 8, 24 bytes. llDialog(llGetOwner(), "test", ["ꖅꖅꖅꖅꖅꖅꖅꖅA"], 0); // Doesn't work, 25 bytes.

Welcome to page 2. This is an obvious downside of current bodies with "built-in" fun parts. I'm not aware of any bodies that follow the classic avatar's texture layout (LL UV) while also having a toggle for certain details.

Avatar 2.0 doesn't use the LL UV. It requires textures that are specific to that body to look right.

To what end? Why is this distinction important? The best implementation depends entirely on what root problem you're trying to solve.

Of course. It was tongue-in-cheek. There are lots of unstable people who will pick a target with no provocation.

Do programming languages count?

You've laid out the functionality in a pretty straight-forward manner, and you're already using RLV which is almost required for this functionality (unless you were to toggle the animations/visibility of each attached towel instead of actually detaching them). What exactly is the issue?

What sort of SL life do you live if you make enemies that would try to get you banned? 🤔

I'm sorry you have to be on the defensive on three different fronts, but anyway. The point I'm making is that what you suggest is not possible yet. Until it is, it's not unreasonable to concede that BOM does some things better than before, so it's okay to take advantage of those aspects until we can ditch the old system entirely. Yes, alpha cuts are bad, I've said as much. But before, we had alpha cuts AND excessive textures. One problem at a time, yeah?

Yup, you got it. You don't need to use just alphas with BOM, alpha cuts still work (unless I've missed the memo), and BOM supports 11 textures even for those that go far beyond the norm. We figured them out and they're just another technique for creating, with its own downsides. Alpha cuts shouldn't be bismissed just because something slightly "better" exists, because obviously BOM has pretty big downsides of its own, but excessive texture usage is not one, which is why it's a good iteration over what currently existed. You can combine the two features and you don't have to use it exactly as intended.

This is unture. BOM can be used by any avatar/attachment with any kind of UV layout. The system is UV-agnostic, it just bakes.

Even if absolutely everything is cached and all avatars are disabled, there's still a ton of "hidden" data such as object updates to your viewer (even from some that appear to do nothing) and out-bound data to the sim (even if you don't touch the mouse/keyboard).

There can't be an Omega relay for the Kemono because the body UV is completely different from the SLUV. That's a requirement for anything Omega-compatible.

It's not possible because llGiveInventory (which is used to copy the script from the root to every link in the linkset) has this clause: Scripts reach destination disabled (not running, and cannot be made to run unless the destination object is taken to inventory and rezzed again, or the script is recompiled). That clause has a workaround: To send a running script to a prim, use llSetRemoteScriptAccessPin and llRemoteLoadScriptPin. But that's not helpful because setting a pin can only be done for the prim the script is in. That means, you must put a script in each link so that they can use llSetRemoteAccessPin.. but you can't do that automatically because of the first clause.

Don't use scripts. Select the object and go to Object > Scripts > Remove scripts from selection