Wulfie Reanimator

Okay well I have no idea what that means then. What is the "hud slave" doing? What is the "undress-me functionality script" doing? Why aren't they just one script?

You can either quote the whole post and then remove the text you don't want to include, or you can highlight a part of the post you want to quote: Yes, but if you have 4 objects, you only need 4 scripts. You said 6. What are the two extra scripts doing? I assume you would have 3 scripts in the HUD? You can easily handle all 3 separate attachments from one script in the HUD. It takes less than a minute to create a folder for every group, rename the folders accordingly, and drag the objects into their folders... The "better option" is going to take much longer than that to implement. Even if you're going to consistently name your products (so that they can be parsed by the script) and account for the fact that sometimes you might not include the same body options, the folder method is going to be faster for at least a hundred products.

Okay, I think we're mixing the context a little bit. Yes, if you only have literally one surface for body and head, you can't add a material specifically for the lips if you already have some other head material (without replacing it). No, there isn't anything particularly wrong with materials and BOM. In that post, I was debunking a statement that "you can't use materials with BOM."

What do you mean by the term "slave" then? The way I understand the term doesn't make sense in the context you're using it in. And to have multiple multiple folders in your Marketplace products you would create a folder like this in your Marketplace inventory: product └─version ├─body1 │ ├piece 1 │ ├piece 2 │ └piece 3 ├─body2 │ ├piece 1 │ ├piece 2 │ └piece 3 ├─body3 │ ├piece 1 │ ├piece 2 │ └piece 3 └hud object If you created the folder structure correctly, you can "Test Delivery" from your listings page and you'll get a folder with the HUD, and each body in its own folder.

What I've shown in the post that I linked is exactly what we have right now with mesh bodies without BOM. I've already went through this in the other thread and I made arguments for both sides of the conversation. Onion layers should not be used for clothing, besides for one extra layer that is not form-fitting and covers gaps like butt and clevage, like an "undersuit." You can't currently have more than one set of materials for your skin, just as is the case with BOM. There's no downgrade. Materials are just as static as the baked avatar textures. There's absolutely no difference between them, besides how they are interpreted for lighting, and it's the lighting and shading that's "real-time." You can see that BOM textures themselves are affected by lighting, as you can see shadows and different colors from different sources of light on them, even without materials...

1. Your math seems off. A 3-piece set only needs one HUD, not 3. That's 4 scripts total, not 6. I'm a scripter, I know these things. (And incidentally I tried talking to the Undress Me creator about ways to improve things but I got stonewalled as is typical of all no-mod clothing creators.) 2. The number of inventory items per product doesn't matter. People should package their products with separate folders for each different body. It's extremely simple with Marketplace. If you're a shopaholic with 300K+ inventory items and it's causing you performance problems, that's a whole other problem. The only legit worry is the number of attachment slots, but since the current trend is to make literally all clothing no-modify, you're not going to be linking sets together to reduce them anyway. That means it must be the creator's choice, which is even worse.

🤔

I tested it. I blocked my alt. Then I wrote a script that sends them a full-perm object, and accepted it. Then I tried to IM myself from the alt. Still blocked, no IM. Took me about 30 seconds.

The solution can be explained in very simple layman's terms to the ones with no idea about how BOM works. "If this slot doesn't look right on you, please try one of the other two." You can add additional details like "it's conflicting with other BOM slots," but that's up to you and less is probably better. They don't care as long as it works. I would also avoid calling them "channels" because that's a technical term that will inevitably just confuse the people who don't understand BOM.

What's the point of making animesh wearable if you can only have one of them on at the same time? Just make a version for each 3 aux channels. It takes like 3 seconds total.

You can switch between light and dark mode at the bottom of the page where it says “theme” but that’s about it You can get a browser extension called Dark Reader that allows you to adjust what kind of "dark mode" you like. The page isn't white-on-black for me, more like light-grey-on-dark-grey.

Now THIS we need to be outraged about.

Of course, here you go:

And the negatives are that the invisible parts are still streamed to your viewer and cached. They might not be visible, but they still affect performance. Any piece of clothing should either be modifiable (in a perfect world) or at least have the option to remove all scripts.

We do have some kind of LSL compiler somebody has pulled from some viewer source, but mainly no. We don't have the exact source implementation for any functions or data, especially since even compilation is server-side these days. All we have is some studies of memory usage and speed, by users, by using inworld means. http://wiki.secondlife.com/wiki/LSL_Script_Memory There are also some really old tech talks by Lindens themselves, and while interesting, they're like over 10 years old so the exact details are probably not the same even if the concepts are still there.

They're not SL specific. jump and @label are just C's goto ~ is One's Complement (bitwise operator, also from C) - (minus sign) just simply means "negative of" as in "-2" is "negative of 2" Broken down one at a time: integer len = (~-(llStringLength(from))); integer len = (~-(llStringLength("hello"))); integer len = (~-(5)); // 5 = 00000000000000000000000000000101 integer len = (~(-5)); // -5 = 11111111111111111111111111111011 integer len = (4); // 4 = 00000000000000000000000000000100 // And again... if (~4) // -5 = 11111111111111111111111111111011 { // Any non-zero value will pass. // Do stuff with "from" } Or if you just want to see simple output: Weird function: The "if" will pass when NOT 0. llStringLength(from) 0 -(llStringLength(from)) 0 len = ~-(llStringLength(from)) -1 (11111111111111111111111111111111) if (~len) 0 (00000000000000000000000000000000) Weird function: The "if" will pass when NOT 0. llStringLength(from) 1 -(llStringLength(from)) -1 len = ~-(llStringLength(from)) 0 (00000000000000000000000000000000) if (~len) -1 (11111111111111111111111111111111) So when the actual length of the string is 1, the final if-check gets -1. If the length is 2, it gets -2, and so on. That's what it does. This explanation is probably not very useful, but here it is anyway. I think bit-operations are interesting. Regarding the speed factor of the one-liner vs other implementations; The one-liner method should in theory be much faster compared to any other. LSL code is subject to the time-slices doled out by the sim. But every time you call a function, the sim has to take a step back to process that function, just like we have to define our own functions. The speed at which the sim will perform llParseStringKeepNulls and llDumpList2String is several magnitudes faster than anything you can do in "pure" LSL. For example, your loop may be forced by the sim to pause before it finishes and to continue later, while the two individual functions are guaranteed to finish in one go. (I'm 99% sure there's no space for a "yield point" ((that's a whole other technical topic)) anywhere in the function, so the whole user-defined function should be guaranteed to run.)

Maybe so, but I've also advocated for the benefits if having one extra layer on a body specifically for "clothes." I don't think clothes and BOM are meant to go together, even if the system inadvertently supports it. It's bodypaint -- unless that's what you want, in which case body shine isn't a problem. A clothes layer should bridge the gap on things like butt and cleavage. Obviously, BOM can't be used for both, but that's kind of besides the point. Baked-in clothes is a bad idea all around. We should forget those as a viable product besides for historical purposes. BOM should only be used for things directly on the skin itself, add-on mesh for everything else. That's my interpretation anyway.

Define "active." I still log in sometimes, not every day, or even every week (especially if each account is considered separately). As far as the furry(/anime?) community goes: There's just very little interesting stuff going on inworld for me. The days of social sandboxes where people build stuff or play with random toys is basically gone. Hangout areas are dead silent with everybody talking in IMs, afk, or waiting for someone to ask them to bang. For the human community: I don't even know. It's always been weird.. Like either stuck in 2010, or just full of "normies," and I mean that un-ironically. Residents who are just tech literate enough to interact with SL as a chat room but without any knowledge of how SL works or how to use the edit tools, or any interest in other games. Residents with generally weird social etiquette that feels really... out of touch? Out of place? Naive? I don't know how to describe it. Whenever I log in, it's at my own private home so I can write some scripts, or friends asking me to come over to work on their projects. Just like with inworld, I'm here mainly out of habit. But also because I like helping, answering questions, and going "actually..."

If your goal is to actually learn, a "working script" isn't going to be helpful. Instead, I would point you at a basic LSL tutorial or even just the wiki page for "listen event." Basically, what you need is to: 1. Detect a touch 2. Send a message. (Like llSay) 3. Listen for a message 4. Play a particle effect Just Google for any of those and add "LSL how to"

You don't have to pay someone to be out of touch. It also doesn't matter that you're out of touch if your audience is equally out of touch.

That's true, but that's not what most people are talking about when they say "you can't use materials with BOM."

And to prevent any script errors... integer anim_status; default { on_rez(integer start_param) { llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION); } touch_start(integer detected) { if (llGetPermissionsKey() == NULL_KEY) { return; } if (anim_status) { llStopAnimation("sit"); anim_status = 0; } else { llStartAnimation("sit"); anim_status = 1; } } }

This is a false-equivalence. Just because 100K+ triangles sounds like a small amount by SL's standards, that doesn't mean it is a small amount. What you've done is just point out how incompetent most creators are at creating real-time content, especially the big names that popularize that bad content and hurt residents the most. No modern game spends that amount of detail on that small of an area. It's ridiculous at the face of it and the literal antithesis of optimization.

I script and can work Blender decently enough. The process is simple on both sides and it baffles me how slowly everything is moving on the creator side. That doesn't really matter though. If you want your BOM body to have materials on it but you don't have a "material applier" (they exist, I have one), you can just find any skin applier that *does* come with materials as well. Apply that skin, then re-apply your BOM. Now you have materials with BOM without anybody having to write a new script. Also, if the body uses Omega, you don't even need a BOM update because you can just get the free Omega Dev Kit and put in the BOM textures so you can add BOM to your body yourself. Anyway, I hope it's clear now that there's no problem adding materials to your non-onion bodies. 🙂

Yes, I've also said as much. That's kind of correct, but it's a little more nuanced. If an avatar changes from using onion layers (assuming every layer has a unique texture on it) to onion layers (same textures) + BOM for skin, there's no difference. Once you begin adding tattoos and makeup with BOM, the value of that feature goes up even if it still takes "as many textures as before" to render you. The body is now displaying more detail that it wasn't able to before, but without any additional cost to anyone's viewer. One of the (I think) two main goals of BOM was to reduce texture load. As long as people are using BOM with more than one layer, that's achieved. The other main goal was to reduce onion layers, but that's going to take longer to achieve because it relies on creators removing backwards-compatibility or maintaining multiple versions of mesh bodies which takes more work.