Wulfie Reanimator

It's worth noting that whenever a game moves to a new version of an engine, it doesn't necessarily mean the game is going to look any different (or is going to have that pretty physics destruction). The tech demo is also definitely impressive, but similar destruction was already possible with Unreal Engine 3. (Also the debris created from the mayhem does disappear, fall into the ground, etc. You can see it pretty clearly if you look closely, for example at 2:55 on the left-side wall as things are falling down, and on the street below when the camera focuses on the little robot.)

That's just a limitation of the in-world profiles. They're always scaled down as far as I know. My profile picture on the web profile (same as in-world) is 600x600, not sure if it can go higher than that.

Have you tried changing the physics type?

Oh, no, I don't care what you actually do. Copybot all you want, whatever you want. It's no skin off my back whatever you do. I'm just baffled by the mental gymnastics you're (not?) doing to justify it. There is. The permission system. I've shown you the part of LL's terms and conditions that specifically says "the permission system is a license," meaning that when a merchant sells you a HUD with a script (and just those) and sets them no-modify, that means that: You haven't bought textures, only an applier. You have no rights to the textures being applied to your avatar. What you have bought is no-modify, meaning you cannot make modifications to them without breaking the license. Even if the applier was modifiable, you would only have the license to edit the HUD/script itself, not the textures. Only when the textures are provided and modifiable could you make the argument that bypassing the permission system (going into your cache, if they aren't full-perm) to make personal modifications to the textures is fine. But you don't seem to agree, because apparently you're not understanding what the terms and conditions actually say.

Thanks, my forum title is very deliberate. It was given to me years ago on another forum and I quite like it. I know the textbook definition of stealing. The one you've given me doesn't even cover piracy because you can't "steal" a game, you're just creating a new copy of it without deriving someone else of anything. Obviously piracy is considered stealing, but you need to use better definitions if you're going to start copy-pasting literary to me. I also understand the first-sale thing and it makes perfect sense. However, it's not absolute and it can be overridden. Video games -- besides the physical disk (or technically even the disk I think?) -- aren't covered by it because of End-User License Agreements. They specifically say you aren't paying for the code required to run the game, and you aren't paying for the assets required to represent the game on your screen. Linden Lab has this stipulation too (terms and conditions): As @OptimoMaximo pointed out, Second Life's agreement specifically states that the permission system is used to define the license to use the content you buy. You aren't buying the content itself. P.S. Answer the other example in my previous post above yours.

Because you're too daft to understand what you've purchased. Hint: It's not the texture. Can you explain the difference between you buying an applier and extracting the actual texture, and me buying a video game and extracting the textures from that? Let me guess, is it something along the lines of "games cost more or are bigger than just appliers?" Or a more relevant example again, when you buy yourself a mesh body, why do you think it's not okay to extract the model and make adjustments to it? I guess you already explained that "you have to do it locally," but you have to do that with textures as well so that doesn't count. What gives? Could it be because people can easily tell when you've re-uploaded an edited model?

I can't believe I knew what you were going to say. 😂 Your logic is flawless. I would literally have much more respect for you if you just said "I don't care if it's stealing," but what you're saying is "it's not stealing because it's so easy." Following your logic, it's not stealing or trespassing if you try to open someone's front door and it's unlocked. Clearly the lack of protection implies you're free to just walk in. I don't even understand what you mean by "locally." When you "point your web browser into your viewer cache directory," that is "done locally," you're never accessing anything online. The distinction of local vs remote doesn't make sense to begin with. Everything you see on your computer is local. Watching youtube? The video exists locally on your computer so go ahead and find those files and upload it back on Youtube. It's yours! Playing a video game? All of those textures, models, animations, sounds, etc. are yours to use since you installed it on your computer, no worries!

For some additional context, since I did talk to OP: Supposedly, 4 avatars on the sim as fine, but 9 was causing noticeable lag. The homestead sim is running at 50% scripts while the total script count is ~1200. I can only think of other homestead(s) being overloaded on the same server and/or things like physics problems, but I didn't visit the sim myself. It's important to note that scripts are the very last things to run, after all other tasks. If the sim spends a lot of time working on non-script related processes, scripts won't get much time to run no matter how "low-lag" they are. You mean LSO. Also, LSO scripts initialize much faster during teleports and while the object is being rezzed. The difference is huge, especially noticeable during teleports (in the arriving sim) and fast-rezzing things like bullets. Though, LSO runs much slower than Mono, and uses less script time overall. /ramble

Assuming you own the whole region, here is a very simple script that: Checks the script count of every avatar in the region, every 30 seconds. If they have too many scripts, it will: Send them a message, explaining that they have too many scripts and how many. Send you a message (if you are in the same region), telling you how many scripts they had. Eject them. You can put this script anywhere in the region, as long as it's rezzed. integer frequency = 30; integer too_many = 100; default { state_entry() { llSetTimerEvent(frequency); } timer() { list avatars = llGetAgentList(AGENT_LIST_REGION, []); integer total = llGetListLength(avatars); integer avi = 0; while (avi < total) { key avatar = llList2Key(avatars, avi); list data = llGetObjectDetails(avatar, [OBJECT_TOTAL_SCRIPT_COUNT]); integer scripts = llList2Integer(data, 0); if (scripts > too_many) { llRegionSayTo(avatar, 0, "Hi! Your script count is too high (" + (string)scripts + ")," + " please be considerate of other people and reduce the amount."); string profile = "secondlife:///app/agent/" + (string)avatar + "/profile"; llOwnerSay(profile + " had " + (string)scripts + " scripts."); llEjectFromLand(avatar); } ++avi; } } }

I also use Dark Reader with the forum's light theme.

When you set up a listener with llListen, you're also creating an initial chat filter. llListen(channel, name, id, msg); If the message doesn't come from name or id, and doesn't contain msg, no listen event will happen. If those filters pass and a listen event is triggered, you can ignore any that aren't from the owner: if (id != llGetOwner()) return; And you can ignore any that don't come from avatars sitting on the same object: if (id != llAvatarOnSitTarget()) return; if (id != llAvatarOnLinkSitTarget(link)) return;

As long as it's under a hundred... Avatars can have up to 38 attachments. If they have more than two scripts per attachment on average, somebody's doing it wrong. Not everybody even knows how to check their script count, and/but there's not always a way to remove scripts from attachments, so it's a little subjective. The biggest impact of script count happens while the avatar is in the process of teleporting in. After they're already in the sim, kicking them out won't help very much. The majority of overall script lag comes from permanently rezzed things in the sim, so that's where your optimization should focus.

Can you explain the difference between ripping a texture and ripping a mesh?

You must not have used multiple mesh bodies then. There's no way you'd say any of that if you had ever tried using an Omega applier on two different bodies and actually paid attention to what the body looks like afterwards. Get yourself an Omega applier. Apply it on Maitreya. Look at the feet. Use the same applier on Belleza Freya. Look at the feet. They aren't the same, the texture is completely off. Yes, it is a problem with the mesh and that's what I was trying to explain. OP isn't asking only about the system avatar, so this problem is very relevant. (P.S. As a small technical side-note, BOM or Omega doesn't "remap" anything. It is the mesh that has the information about which parts of the texture go where, and it doesn't care what the texture looks like. The BOM update just made the already-existing bakes available to be used by scripts.)

Sure, but if the mesh you're applying textures to has a UV layout that differs from your template, you'll see distortion/seams. A good example is toes. Maitreya and Freya are both based on the default LL UV, but if you take a texture tested for Freya, you'll see a different result on Maitreya and vice versa. Same thing with inner thighs and even nipple placement between some bodies. This is just a byproduct of how the UV layout is transferred from the default avatar to a new model. It's unavoidable to some degree even if most of the problems can be fixed. There can't be a universal template that "works for all bodies" because the bodies themselves have at least minor differences in UV layouts.

Even when you create synchronised animations (as is the case), there's no guarantee that they will stay in sync. It only takes a fraction of a second in delay between the animations to risk them clipping into each other; animation changes are handled over a network which is subject to lag, and animation loading is dependant on the viewer (network/disk) which might not be fast enough. Another zit on the face of content creation.

I don't know how/why I glossed over this line, but it's false, depending on what you mean. If the "sweat" is an actual texture, you can have that with BOM too. If it's supposed to be a "material," onion layers don't do anything BOM can't do. If you have a skin material on and you try putting just a sweat material on a layer above it on a transparent surface, the material won't show up and it does nothing. Same thing, assuming we're talking about diffuse textures.

I would love to rewrite those scripts so that they fit into a single script. Obviously I don't know the specifics yet, but I'm very curious. You can PM me if you'd like that. Undressing should be just an alpha swap and an integer to keep track of the current state... It's very small and simple code on top of texture changes. I understand it's a bit different when creators buy ready-made scripts without knowing LSL, but that's why I try to offer as much help as I can wherever I can. And there should still always be a way to delete all scripts from an object, even if it meant adding one more script into the dang thing.

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.

🤔