Wulfie Reanimator

There's an adoption place that has something around 20 bots scattered evenly across the sim at 4000 altitude on a flat plane, all empty profiles, unmoving, and using starter avatars. I've reported these a couple times but I'm fairly sure not even one bot has been removed.

This is most likely caused by the hair being rigged mesh (probably Bento), and her viewer doesn't support that feature. The first thing your friend should try is change to a more recent viewer, like the official SL viewer, Firestorm, or Black Dragon.

Some also call this "griefing" (or "griefer"). Some of the most common types of targeted griefing include.. locking you into an object, preventing you from moving pushing you around, sometimes very high into the air ("orbiting") rezzing objects that follow you on the sim, often spamming chat or playing loud sounds or blocking your view But doing these is not possible in many places. Pushing (by scripts) is disabled in most places, and rezzing objects at all is relatively uncommon outside of sandboxes. Any kind of harassment or severe disturbing of peace is not allowed, and you can file an Abuse Report (AR) about the person. Blocking them only prevents you from seeing them and their messages, but they can see you normally and might not even realize you've blocked them. You can also sit on the ground by pressing Ctrl Alt S, this prevents anything from moving you at all.

What you need is not a function, but a specific way to write it into chat. You can create clickable text by enclosing the link in square brackets, and including the name of the link after the url, like: [https://www.google.com Click me!] becomes Click me! Or in code.. default { state_entry() { string url = "https://www.google.com/"; llOwnerSay("You can find anything on [" + url + " Google!]"); } }

I want to dare you to make a thread calling out "that one brand you love to hate" and see how it goes, but... I'd probably get blamed for it too. I don't care to debate something as open-ended and common-sense as forum guidelines though, you win.

I don't think there is any public documentation for this as it's all proprietary "back-end stuff" and we don't need to know. I think Fionalein is mostly on-point though. When you upload a texture, it gets stored in the asset server and I don't think you can get rid of it. I'm 99% sure that if you were to try uploading a texture and write down its UUID before deleting it entirely without applying it to anything, the UUID will keep working. (Either applied by a viewer or a script) As for copies of the original asset... assuming you even technically can, there's many ways it could be handled, like creating a full copy, creating a partial copy where you have a pointer to the actual asset and only create new data for what is different in the new copy, or creating almost "weightless" copies that only hold pointers to real data in other places. Trying to explain this is a whole lot of guess-work and anything I proposed might not even be what's going on. As for what happens to the ownership of a deleted inventory item (which really are just pointers to data in the asset server, but they do not exist on the asset server themselves), it doesn't matter because it doesn't exist at all and therefore cannot have an owner. It's dead, Jim. (In bold under Inventory Basics)

I'm glad you can see the issue.

Scripts have an "event queue" of... 64? So even if a script is busy processing a listen event when a new message arrives, that new message will just wait until the first event resolves. That's the general theory anyway, but I think someone did a test recently, showing that chat messages will have an even longer queue, something to do with how the sim stores chat messages unlike other events. But even if that wasn't the case and you could only queue 64 messages, by the time the 65th message arrived, the script has probably already finished one or more events, allowing for more messages to be caught.

If you manage to contact a creator with an active store and tell them "their skybox is bad" and then get them to send me a .dae so I can "try to fix their work," I'll gladly spend hours on sciencing™ it out.

You can do the "scan" with llSensor, it creates an event if things are near enough, then you can do what Rolig suggested. If you have a notecard somewhere, you can read lines from a notecard with llGetNotecardLine, but writing a notecard reader might be pretty complicated if you aren't familiar with LSL, especially events, handles, and string matching. Though, unless you want to write everybody's information into a notecard yourself, you'd probably want the scanner to hold the user's information and communicate (llListen, llRegionSayTo) with every other scanner to get information from other people.

There are 7 avatars in that area (shown via minimap on bottom-right) and one avatar generates up to 1440 traffic (Traffic rate is 1 per minute (if they stay over 5 minutes) per avatar per day) so we're looking at about 10K, plus the visitors they get by being in that 10K range and being brought up to 20K. This is also very easy to spot, they are almost always avatars with no last name, huddled together in a small area and wearing the starter LL avatars (created by Moles and Lindens). Those are definitely starters / library avatars.

I understand, and I'm not going to start trashing any products. I regularly use the Steffi myself. I just want to give out some perspective on how significantly the SL performance could be changed if everybody was well educated on the importance of performance alongside actual features. And trust me when I say this, almost all of the "human head market" is in a similar state to Steffi, so there's no point in me trying to specifically pick it apart. Without even having looked at the Genus head, I guarantee that the same applies, especially with all that @Elinah Iredell said in the opening post.

@Gabriele Graves I don't think Chic meant a head she's making, just a head she uses. Right-click and Inspect, mostly. I'm going to use two of my heads as examples to compare and hopefully give some perspective of how different heads spend their resources for appearance. They will have almost identical features (appliers, alpha toggle, Omega, etc) I'll highlight some things at the end. Catwa Steffi (bento rigged): Land Impact 8, Complexity 3662 The head has over 80K triangles and uses 19 different textures (40MB video memory including mesh, A LOT!) Utilizator Normie (bento rigged): Land Impact 17, Complexity 9160 The head has little over 2K triangles and uses 6 textures (10MB video memory including mesh.) Paws Maned Wolf (unrigged mesh, several mouth/eye states): Land Impact 8, Complexity 2120 The head has 62K triangles and uses 3 textures (5MB video memory including mesh.) I threw in the Maned Wolf head for a third point of view of a more outdated/unusual head, as it's for furries unlike the first two, which are entirely human heads. I have more heads on another account but it's already very uncomfortable navigating with a laptop and a trackpad. Before I go further, just look at the numbers and the given complexity. Steffi uses 40 times the amount of triangles and 3 times the amount of textures, but somehow manages to have only 40% of the complexity of Normie. Does that make sense? Here's what the heads actually look like: Steffi http://puu.sh/CrPUP/c577245230.png (world view) http://puu.sh/CrPVr/6b0a7be2cf.png (wireframe, face, onion layers NOT visible) Note the mid-section of the upper lip and tooth caps Remember that there are 1-2 additional copies of the face, double or triple everything. http://puu.sh/CrQ1h/f8b7c329c5.png (wireframe, teeth from inside mouth) Each tooth is individually detailed Normie http://puu.sh/CrQ9h/7ab9d85afd.png (world view) http://puu.sh/CrQ9N/4889f9c880.png (wireframe, face) http://puu.sh/CrQai/fa8b535161.png (world view, teeth) Teeth are not individual, but one connected face with some crevices and additional shadow from the texture. Steffi only uses the High and Medium levels of detail, Low and Lowest are set to a minimum, eg: 15912, 15912, 5, 5 and 23790, 23790, 93, 8 Normie uses more stepped levels of detail, eg: 5598, 1398, 350, 176 and 1722, 861, 214, 54 So my point is, when people say "less tris" or "lower poly," they probably (hopefully) don't mean as low as the LL system body. (I think most can agree that it is outdated and lacks a lot of polish, like that sharp belly!) They just mean "reasonably low." Even if you were to go in and remove every other edge loop in Steffi's topology (mesh form), the difference would be indistinguishable to the plain eye. There is so much unnecessary (unnoticeable) detail in a lot of mesh that could be safely and easily reduced. Things like the teeth on the inside of a mouth do not need to be individually modeled for everyday use. That kind of detail should only exist for people who want extreme closeups in their SL photography with real intent on showing the teeth. The problem is, even if you made two versions of the head, one optimized and one with "ultra realistic detail," the uneducated masses (the average consumer) will probably want the one with more detail, because it's prettier, right? They're probably not wrong to think that either, especially when SL doesn't have a restricted camera distance like almost any regular game, but the trade-off is that everybody suffers when anybody is using it outside of its intended context. Not even a full-body character in a modern (major) game with all of its clothing and accessories is going to use as many triangles as most bald heads in SL. There are lots of numbers on many recent-ish releases to cross-reference, even if they are kind of unspecific. And now that I got started, I could keep going into hair, props, and texture use, but... I don't want to spend my vacation writing an essay on a pretty boring subject.

Granted, but your code style and variable names are indecipherable to anybody else. I wish for... a new wish that cannot be corrupted.

I still strongly disagree that avatar rendering complexity is of any real value in its current state. Not even as a "rough estimate." It is way too easy to manipulate the value, knowingly or not.

??? One of the main goals for BoM was to reduce the need for onion layers, and you're calling it smart to have a toggleable BoM with the layers unchanged? What you said earlier was the actually smart thing -- having two versions of the head, or just layers separately. Low complexity is infamously easy to obtain, have you checked the LODs on the individual parts of the head? (Rez the head on the ground for easy selection. Also could you name the brand or send it to me privately? If they're genuinely good, I'll be glad to throw money at them.) I totally agree on appliers staying for a long time after BoM, though.

That only applies for the web search. The legacy search (in the screenshot) can only be sorted by name or by traffic.

This is incorrect, you can read no-mod notecards that you didn't create, even if it was given in a box. This would make sense because you can even read notecards that only exists in someone else's inventory, if you have the UUID. What are you trying to create, exactly? Low channels make sense for chat commands, but not much else. I can't imagine the practicality of "I want sequential channels for each copy of the product, starting from 1, that is unique to each person." Whatever you are doing, surely there must be a simpler way to do it? What do you mean by "faking a UUID given a root number (which is always 1 for linksets and 0 for unlinked)?"

If you haven't visited them, try Oracul (Kuso sim), they have lots of very fluid AO sets for cheap. (150-600L each AO, 10L per animation name and you get 1-5 height variants)

Avatar movement? As for framerate issues.. it's hardly the fault of mesh itself. Like I already said, prims are mesh too. It's the amount of it that creators use for the high/highest LODs, even going so far as to reduce the lower LODs in order to be able to put more in the higher LODs, and as a result a lot of people are using LOD factor 4 or higher because otherwise most mesh looks terrible (because of creators).. and they're always rendering absolutely everything at the highest LODs which is not at ALL how you're supposed to handle real-time 3D rendering. What's your LOD factor set to anyway, @Alyona Su?

Even if you could name the function, that wouldn't be an argument. Pussycat and I are talking about the language itself, its environment, goals, features, and how it's designed. One "stupid" or broken function doesn't encompass any of those subjects.

I am 100% certain that the main reason why most of the mesh that seems to cost inconceivable amounts of LI is because nobody makes proper (read: simple) physics shapes for their mesh. Importing a tree? Let's let the importer calculate a mesh shape for it, yeah! Or even better, let's use the model itself as the physics shape, that way it's more accurate! And the server would scream if it had a mouth. Keep in mind that all prims are auto-generated mesh as well, even if they don't necessarily use the same LI calculation (unless you set them to Convex). The biggest difference is the simplicity of their physics shape, which avoids lots of little computer pitfalls, like small gaps (complex physics calculations). There was this one mesh that was basically a series of hollow hexagonal tubes with a small gap between them and using the model as a physics shape. It was about 8 LI at its regular size, but if you scaled it down just right... I think we got it to 517 LI at worst. If the entire mesh was encased with a simple cube as its physics shape, that couldn't have happened. Similarly, I've seen quite a few skyboxes that have a very basic, one-room box shape with no excessive use of mesh, but the LI is still way higher than it should be and I bet it wouldn't be even half if it used a cube with inverted normals (to keep you inside) or just a hollow, reasonably thick 16-face box for its physics.

Out of curiosity, what are some specific flaws you're referring to?

No products will need to be updated as long as there is an applier for the BOM-specific UUIDs. After the BOM UUIDs are applied for the head, you can wear system layers and they will work as you would expect.

I was guessing that was what you were doing. In that case, I'd suggest a little trick: Creating a channel from the object owner's UUID, plus a base channel for the specific product. integer channel = (integer)("0x" + (string)llGetOwner()); To explain that a little bit, you can write integers in a hexadecimal format (up to 8 characters after 0x), for example, 0x601693cb is 1612092363. All UUIDs use only hexadecimal characters, so you can use any UUID for this. For example (using my UUID), the code "0x" + (string)llGetOwner() gets you "0x601693cb-8c20-4a28-86f1-073d9e23bab2". This is too long to be an integer, but when you typecast it to an integer, it gets shortened to be a proper length and you get 0x601693cb. This is now a valid number you can use as a channel, and add whatever numbers you want. This way, the same line of code always gives a unique channel for each user and you only need to change that base channel for completely different products.