Wulfie Reanimator

"Stack" is used for run-time memory. When you call a function like llList2String, the function itself takes a bit of memory on the stack and the final list returned by that function also goes onto the stack. If you have too much memory on the stack, the script will crash. The "event queue" is just a waiting list for events like touch_start, listen, control, sensor, etc. When the script is processing some event and a new event is triggered, the new event goes onto the queue. This queue is handled by the region and does not take up any memory from the script itself. Up to to 64 events are kept by the region, any more than that are discarded. So when you have an event/function with a loop, the script will just be busy processing that loop and any new events will go into the queue. The iterations don't take up any memory on the stack by themselves, so the stack doesn't change either unless you use other functions that use memory. list j; // The variable itself is stored on the heap. // All of the compiled bytecode is also stored on the heap. default { state_entry() { llListen(0, "", "", ""); // The function call uses stack. // The memory used by llListen is freed from the stack after it returns. } // When a chat message is heard, "listen" goes into the queue. // If the script isn't busy, it will start processing the next event. // The event will use stack memory while being processed. listen(integer channel, string name, key id, string message) { integer i; // Stack while (i < 1000) // Uses no memory, but the script stays "busy." { // (1000 uses heap because it's a literal.) j += message; // Stack memory grows. ++i; // Technically uses stack, but doesn't really use memory. } if (message == "clean") // "clean" is a literal. { j = []; // Stack memory shrinks. } } // All of the stack-memory used by listen (everything besides j) // gets freed when the event ends and the script is no longer "busy." } You can crash the above script with a stack-heap collision if you never say "clean" near it. Edit: I guess if we go super nitpicky, "i < 1000" uses memory because the expression returns a value (1 or 0), but I don't exactly know when it gets freed but that's extremely insignificant to any script.

I believe this is because "proper mesh" is way more accessible than sculpt maps. The art of prims was pretty elusive as well...

The eyes-rolling-into-your-skull has been a problem for many many years. I remember having this issue back when the Phoenix viewer still existed.

All variables are always initialized to zero-values in LSL. You're right that in some languages, for example C, this isn't case. LSL is a safe language though.

Not quite as extreme of an effect, but yeah, animated capes exist. (Both animesh and traditionally rigged.)

Yup, it plays two animations per "stand" or whatever state the avi is in. When you're sitting, the hair plays a sit animation for the avatar, and a totally separate animation (using bones like tail, spine, leg, etc) for the hair. This way the hair's animations don't conflict with bones the actual avatar might be using. (So for example, if the hair used the tail bones but you have a tail, the hair would cause your tail to wave around as well if it wasn't a separate animesh object.) What might be an interesting thing to do is to into the hair's contents and play one of the hair-animations on your own avatar.

Animesh uses a separate skeleton from the avatar itself, so even priority 1 animations would be enough to not get affected by things like furniture or dances.

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.