Wulfie Reanimator

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

Of course. But my input field had my full address, including my apartment number, but it was not parsed into the dedicated fields. To quote, my apartment number is "null". I can add more specific excerpt from the file later. Edit: Here's one object in the "Billing Address History" list. "---" is info that was filled in. { "City": "---", "House Number": null, "ZIP": null, "Created": "---", "Country": "---", "First Name": "---", "State": null, "Phone": null, "Address 1": "---", "Address 3": null, "Address 2": null, "Apartment Number": null, "Last Name": "---", "Postcode": null } I should also reiterate there's multiple, almost-duplicate records of these. Not the same amount as payment method history or invoices. I don't know if this comes from me, my bank, or other companies that LL shares data with. This is what I was told in the same response as my download link:

There's nothing you said that I disagree with, except this part. You don't know how much data matches with this account and others, because even I don't remember what info I gave.

It took a while, but I did and here we are, again. I made a very casual support ticket under "Account Issues - GDPR Request": Then I was asked to verify my ownership of the account by giving my security answer and a couple other things. Then I waited from Sept 19 until Oct 11 before I was given a time-expiring link to a file containing information about me in the JSON file-format. This file is one line, 22322 characters long, but it's easy to automatically format with a text editor. (I wouldn't recommend an online formatter because you know... personal data.) The first section is about my account. Username (Wulfie) A record of all of my IP/MAC addresses from 2009 to 2019, HDD serial, and access times. Last name (Reanimator) Agent ID (779e1d56-5500-4e22-940a-cd7b5adddbe0) Display Name (Legacy.Name) Email address The second part is about "the customer." Billing address history Date and time First and last name Country, state, city, ZIP/postal code, house number, apartment number, and the address you filled in in the input field. It should be noted that most of this information was just flat-out missing. They got my name, country, city, and input right. Your security questions/answers Date created, date updated, the question and answer themselves Registration date First and last name Date of birth The IP address you registered from Email address history Current, old, and date of last update Country Invoices (Mine is empty, probably $US-related) Payment method history Active? Type Last 4 digits Date added Email (again) It should be noted that this does not include names of alts. I don't know if this is because I haven't used the same (or any?) name for my other accounts, or because I haven't added/used the same payment info, or if they don't include them as a security-reason, or because they don't keep records of connected accounts. It's probably the last one. I never would've considered support tickets, abuse report cases, JIRAs, chat logs, etc. to be personal data. They only concern the account, even if the things you say in chat could be used to identify you, but you're gonna have to get an opinion from a court if you wanna argue that. This means that if you wanted to see/delete ALL of your personal data from LL, you might have to make a separate request from each account.

You guys got it all wrong. The most exclusive party is the Party of One. There's no amount of money or power that enables you to join one. 😁

Unless you own every single component full-perm, you can't. You (probably) paid for some textures, but you don't own the mesh/sculpts those textures are made for, so you cannot export them. Even if you had everything full-perm and were able to export it out of SL, you would still need custom rigging for the VR Chat avatar skeleton, along with fixing the materials.

The problem with that comparison is that SL isn't like Skyrim or other MMOs. Other MMOs have content created by the developers directly. Content in SL is almost entirely created by the users. LL can't keep breaking people's content as it breaks the whole of SL, frustrating creators and end-users alike. Even breaking-changes to closed-source code libraries aren't a good comparison, as the developers relying on those can choose NOT to include the new changes. We can't choose our preferred API version in SL.