Wulfie Reanimator

I don't think those are a very good comparison. Those are entire features that would almost definitely take more work than a single function. llGetMoonRotation at least has legitimate uses (niche or not) with no harmful side-effects. But what about other things like llCastBox or llCastCircle (volume-based raycasting), llDamage without requiring a collision that instantly kills the object, llDamage with negative values (healing), objects being able to detect LL damage (even if they stay unkillable), being able to iterate children of a linkset the script isn't in (eg. you have a root key but need a specific child), etc...

What, page files for the GPU? Oh lord..

I believe the mipmaps are created during the upload process of the texture, by the uploader. The wiki page you've linked explains pretty explicitly that mipmaps exist and how they're used. Lower resolutions are used based on the texture coverage on the screen. I'm not sure what kind of "blurriness" you're experiencing. Do you use anisotropic filtering? Can you include screenshot comparisons? Definitely. Remember that 1024 is four times more pixels than 512.

" corona will pass stop hogging toilet paper you silly people "

You can't create your own skeleton when creating rigged mesh for SL. You have to use the official skeleton. http://wiki.secondlife.com/wiki/Mesh/Rigging_Fitted_Mesh

I mean you can see the verts without even zooming in. If it has a subsurf modifier on it, it's not set very high or the base model is extremely simple... It looks like a plain UV sphere with 64 loops. I can remake it with 1700 tris and no modifiers. (Or 1300 with sharp edges.) You're not wrong to mention the importance of low-poly though. 1700 or 17000, there's always room to improve things.

Sure, timer is generally better than a loop for many practical reasons. That said: An infinite loop won't "use 100% of the server's CPU," it gets scheduled its own time-slice (we're talking tiny fractions of a second) just like every other script. The script has no other events/interactions and needs to run "as far as possible" because it's a very short-lived object. (Moves very fast and won't exist more than a couple seconds.) This isn't my first rodeo either, I'm very aware of all the implications and timer-based updates perform much worse in the environment the code is expected to run in. Slowing down the timer is only going to make things worse because the velocity remains constant. I might as well have written "while (llVecDist(llGetPos(), target) > threshold" and the loop would not really change. The important thing I specifically need is that the event does not exit before that or a couple other conditions are met. "while(1)" just allows me to clearly describe the flow of the loop (when each condition should be checked) without writing comments. That's not the point of my post anyway. My case is specific, but the calculations are the generally correct answer.

Based on the Blender screenshot, the shield is Fine™. How did you determine it's too dense?

Just because it's easy to fix doesn't change the fact that you would have to fix a problem that didn't exist until now. It's dumb design even if it doesn't necessarily affect you (or me). And just to clarify, I don't have a problem with the owner part. At least if the spam gets too heavy, the owner can remove the object.

The "stimulus bill" is basically the government giving out money so people and companies can continue to operate normally. If you're in the US, making less than $75K/year or up to $99K, take the money and support yourself.

Automated avatars don't require any scripts to function. They're literally just automated viewers, so the "code" that runs is on the computer the bot is connecting from. (In fact a lot of the things bots are used for are things that scripts literally cannot do, like sending group invites, IMs in a tab with responses, sending messages to group chats, etc.) I don't know exactly how breedables tend to be just god awful, but animesh is much lighter than breedables that are animated without animesh. With animesh, you just do "one thing" and the animation plays without using any script resources.. unless it has lots of constantly changing animations. Without animesh, you need to do lots of things to move every part of the breedable. The "species" doesn't matter, so asking about "dogs vs horses" is kind of pointless.

The 4 values in llListen, as linked by Rolig, are "channel, name, id, and message." id is short for UUID, or key. They're used to create the "filter" for messages that can create events. For example: // Listen for all messages on channel 0. llListen(0, "", "", ""); // Listen for all messages on channel 0 from the owner. llListen(0, "", llGetOwner(), ""); // Listen for all messages on channel 0 from anything named Object. llListen(0, "Object", "", ""); // Listen for all messages on channel 0 from anything named Wulfie Reanimator (including objects). llListen(0, "Wulfie Reanimator", "", ""); // Listen for a specific message on channel 0. llListen(0, "", "", "phrase"); // Listen for all messages on channel 159 from someone whose name and UUID are the same. (Impossible) llListen(159, llGetOwner(), llGetOwner(), ""); You an also have multiple listeners (just use llListen multiple times). Every time a single message passes a filter, it triggers the listen event. In the listen event, the 4 values are the same, except this time they're variables that contain information about the message. channel contains a number which is the channel the message was heard on. name contains the name of the object/avatar that sent the message. id contains the key of the object/avatar that sent the message. message contains the text exactly as it was heard.

Essentially, you'll need to add a layer of mesh to the area where the "gif" is going to be. For example, a simple square on the chest. That patch needs to have its own material, separate from the rest of the shirt. That way you can animate just that face of the shirt.

Most of the common cases can be handled by llParseString2List itself, since you can use multiple separators. That way you can get rid of commas, periods, exclamation/question marks, and other special characters. Here's a basic example. It's not necessarily how I'd structure the code myself, but this should be easier to follow: list bad_words = ["bleep", "bloop"]; default { listen(integer channel, string name, key id, string message) { message = llToLower(message); // Make everything lowercase for simpler comparisons. list words = llParseString2List(message, [" ", ",", ".", "!", "?", "'", "\"", ":"], []); integer count = llGetListLength(words); integer i; while (i < count) // "Iterate" through every word. { list word = llList2List(words, i, i); integer index = llListFindList(bad_words, word); if (index != -1) { // Bad word was found! return; } ++i; // Move on to the next word. } } }

My only criticism of this method is that you won't detect bad words at the start or end of a sentence, eg: "Darn Rats" contains no bad words.

llParseList2String, separate by spaces. Then look for each list element in your list of bad words.

Well, of course. It takes some time to keep each viewer up to date with the world, but doing that for 100 avatars is not so taxing that you'd notice it. Not until people start actually teleporting in, filling the sim with scripts, moving around a bunch and/or interacting with physical things. If you have a good demonstration on the contrary, I'm all for seeing it.

That went further than I expected. My baby is still in development, there's s couple kinks I need to work on and it's giving me a hard time. Tracking targets is tricky. It's a fun project with friends though, but neither of us are good with physics math. The mesh is on point at least.

SL physics are neither accurate, reliable, nor consistent. Good luck!

I dunno about non-destructive, but the first thing that comes to my mind is to make a cube that's 64m per side, and just copy it in a grid-pattern over your model, boolean, and upload the pieces.

It's not just "up to 100," a full region (100 avatars) can have more than 100 avatars on it if the avatar trying to access the region has a Premium membership, up to 110. Other types of regions have similar "over capacity" for premiums. The limit of 100 is also arbitrary, Ebbe mentioned much higher numbers for educational purposes in a recent talk I watched. And where lag is a concern... it's not because of the avatars themselves. It's the scripts, people teleporting in, and sometimes physics. A managed region can run fine, they're just few and far between.

I can confirm there's no way to detect if someone's mouse is hovering over something, but there is a way to detect if someone is aiming at something in mouselook, or looking at it in free view. It requires regularly doing a raycast check according to their camera's position and rotation. http://wiki.secondlife.com/wiki/LlCastRay http://wiki.secondlife.com/wiki/LlGetCameraPos http://wiki.secondlife.com/wiki/LlGetCameraRot This requires that the thing that's doing the checking has permissions from the avatar in question. Altarnatively, you can detect other avatars' mouselook remotely (no attachment/permissions required) if you just get their current rotation.

"CONTROL_ML_LBUTTON & click & held" will not return true if either condition is true. You're confusing & with |. Wear this: default { control(key id, integer held, integer click) { string text = "held " + (string)held + " click " + (string)click + "\n"; if (CONTROL_LBUTTON & click & held) { text += "click"; } if (CONTROL_LBUTTON & held) { text += "held"; } if (CONTROL_LBUTTON & click & ~held) { text += "release"; } if (CONTROL_LBUTTON & ~click & ~held) { text += "off"; // Won't work with a single button. } llSetText(text, <1,1,1>, 1); } changed(integer change) { if (change & CHANGED_OWNER) llResetScript(); } state_entry() { if (llGetAttached()) llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS); } attach(key id) { if (id) llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS); } run_time_permissions(integer perm) { if (perm) { llTakeControls(CONTROL_LBUTTON, TRUE, TRUE); } } } To explain just a little bit, "value & value" has a non-zero result only when those values have matching bits, eg. 1000 & 0001 = 0000 1110 & 0111 = 0110 1111 & 0000 = 0000

I like to rename "level" and "edge" to "held" and "click" to be more intuitive. One press of the mouse results in two "clicks." One when you press it initially, and one when you release the button. The button is "held" during the first click and until the second click happens. (It's not held anymore during the second click.) if (CONTROL_ML_LBUTTON & click & held) // click if (CONTROL_ML_LBUTTON & held) // held if (CONTROL_ML_LBUTTON & click & ~held) // release if (CONTROL_ML_LBUTTON & ~click & ~held) // not used

This is a very niche use-case, and still effectively a violation of privacy. What if I don't want you to contact me? Imagine that some annoyed customer (or ex/frenemy) starts spamming my personal email because I haven't responded to their questions, either because I haven't had the time yet, or I simply don't want to. I don't know if blocking a resident even affects llEmail. Edit: Blocking a resident does not prevent emails from objects they own. You can already direct offline IMs to your email, and there is no limit to it. The cap only applies to the amount of messages shown to you in the viewer after you log in. This is not the first step and it's not a particularly good one either. This should be an account feature just like offline IMs, not an LSL feature.