Wulfie Reanimator

Sorry, I'm one massive brainfart.

It must have been sculpt studio. llCastRay is very accurate, I can't imagine its accuracy being any worse than regular floating point rounding errors. For example, here's a gap between two 0.1 cubes, and llCastRay is able to fit right between them. This is a simple visualizer I've scripted myself:

The inspector will use the current information at the time the object is selected. For example, but that doesn't seem to apply on textures.

It was @Fenix Eldritch with the raytracer. It displayed a completely random pattern where the mesh surface should've been. Didn't the trailer we were puzzled by use loose verts to adjust the physics shape, instead of triangles?

4MB? You might wanna check your numbers... Even a losslessly fast compressed 1024x1024 JPEG2000 doesn't each 1 MB. The inspector is at least partially affected by LOD changes, the number of triangles it reports changes depending on the LOD of the object.

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.