Wulfie Reanimator

What kind of "blur" are you talking about, exactly? (You can upload images/screenshots to this forum.) The "depth of field" effect is something that blurs only the background of the image, leaving the main subject in focus. How much you use that (if any) is totally subjective on what looks good to you.

Edit your neck, go to the texture tab, and set the alpha mode to "none." What you're seeing is two "alpha blending" textures being rendered on top of each other in the wrong order. That won't happen with "alpha masking" or "none" modes.

The list method is probably easier to maintain too (which is already a challenge). I think it's unlikely that a HUD like this would need to be concerned about being efficient.

Your scripts are very difficult to read because the indentation is inconsistent, along with the extra empty lines. Many of your conditions could be simplified for easier editing and less errors, too. To give you an idea, here's one way to reduce the amount of scrolling and formatting troubles for the first script. It's not perfect and has some bugs when it comes to the buttons (namely that it will hide non-specified faces too). But there is still more cleanup that could be done with lists which would get rid of almost all of the button code, while avoiding unused faces. integer dChannel; integer lHandle; key id; key AvatarKey; integer isOne; default { changed(integer change) { if(change & CHANGED_OWNER) { llResetScript(); } } attach(key AvatarKey) { AvatarKey = llGetOwner(); llRequestPermissions(AvatarKey, PERMISSION_ATTACH); } run_time_permissions(integer perm) { AvatarKey = llGetOwner(); llRequestPermissions(AvatarKey, PERMISSION_ATTACH); } touch_start(integer num_detected) { //dChannel = ((integer)("0x"+llGetSubString((string)llGetOwner(),-8,-1)) & 0x3FFFFFFF); isOne = !isOne; dChannel = 1; integer link = llDetectedLinkNumber(0); integer face = llDetectedTouchFace(0); AvatarKey = llGetOwner(); integer perm; if (face == TOUCH_INVALID_FACE) { llSay(PUBLIC_CHANNEL, "Sorry, your viewer doesn't support touched faces."); return; } // store the original color list colorParams = llGetLinkPrimitiveParams(link, [PRIM_COLOR, face]); vector originalColor = llList2Vector(colorParams, 0); //WHITE--------------------------------------------------------------------- if (face == 4 && link == 1) llRegionSay(dChannel, "StarSetColorWhite"); //RED--------------------------------------------------------------------- if (face == 3 && link == 1) llRegionSay(dChannel, "StarSetColorRed"); //ORANGE--------------------------------------------------------------------- if (face == 2 && link == 1) llRegionSay(dChannel, "StarSetColorOrange"); //YELLOW--------------------------------------------------------------------- if (face == 5 && link == 1) llRegionSay(dChannel, "StarSetColorYellow"); //Green--------------------------------------------------------------------- if (face == 0 && link == 1) llRegionSay(dChannel, "StarSetColorGreen"); //Torquise--------------------------------------------------------------------- if (face == 4 && link == 2) llRegionSay(dChannel, "StarSetColorTorquise"); //Blue--------------------------------------------------------------------- if (face == 1 && link == 2) llRegionSay(dChannel, "StarSetColorBlue"); //Purple--------------------------------------------------------------------- if (face == 3 && link == 2) llRegionSay(dChannel, "StarSetColorPurple"); //Pink--------------------------------------------------------------------- if (face == 2 && link == 2) llRegionSay(dChannel, "StarSetColorPink"); //Black--------------------------------------------------------------------- if (face == 0 && link == 2) llRegionSay(dChannel, "StarSetColorBlack"); //--------------------------------------------------------------------- //Glow--------------------------------------------------------------------- if (face == 0 && link == 3) llRegionSay(dChannel, "GlitterGlow0"); if (face == 1 && link == 3) llRegionSay(dChannel, "GlitterGlow15"); if (face == 2 && link == 3) llRegionSay(dChannel, "GlitterGlow30"); if (face == 3 && link == 3) llRegionSay(dChannel, "GlitterGlowPulse"); //ALPHA--------------------------------------------------------------------- float alpha = 1.0; if (isOne) { alpha = 0.4; } if (link == 16) { llSetLinkPrimitiveParamsFast(link, [PRIM_COLOR, face, <1.0, 1.0, 1.0>, alpha]); if (face == 0) llRegionSay(dChannel, "ShowHideLowerLegLeft"); if (face == 1) llRegionSay(dChannel, "ShowHideLowerLegRight"); if (face == 4) llRegionSay(dChannel, "ShowHideUpperLegLeft"); if (face == 5) llRegionSay(dChannel, "ShowHideUpperLegRight"); if (face == 2) llRegionSay(dChannel, "ShowHideThightLeft"); if (face == 3) llRegionSay(dChannel, "ShowHideThightRight"); if (face == 6) llRegionSay(dChannel, "ShowHideTummy"); } if (link == 15) { llSetLinkPrimitiveParamsFast(link, [PRIM_COLOR, face, <1.0, 1.0, 1.0>, alpha]); if (face == 4) llRegionSay(dChannel, "ShowHideChest"); if (face == 5) llRegionSay(dChannel, "ShowHideNeck"); if (face == 0) llRegionSay(dChannel, "ShowHideLowerArmLeft"); if (face == 1) llRegionSay(dChannel, "ShowHideLowerArmRight"); if (face == 2) llRegionSay(dChannel, "ShowHideUpperArmLeft"); if (face == 3) llRegionSay(dChannel, "ShowHideUpperArmRight"); } if (link == 14) { llSetLinkPrimitiveParamsFast(link, [PRIM_COLOR, face, <1.0, 1.0, 1.0>, alpha]); if (face == 2) llRegionSay(dChannel, "ShowHideLeftPeck"); if (face == 3) llRegionSay(dChannel, "ShowHideRightPeck"); } if (link == 13) { if (face == 3) { llRegionSay(dChannel, "ShowHideALL"); llSetLinkAlpha(LINK_SET, 1.0, ALL_SIDES); } } } } When it comes to your actual question about needing to click twice for a different face, that's because you have a single "switch" variable for the whole HUD. You would need to keep track of each button/face individually. Again, this can be done with lists. I would also recommend that you don't send a vague "ShowHidePart" message to the body, but instead only "ShowPart" or "HidePart". This would get rid of the need to keep track of toggling parts in the body as well.

The dress' creator did an oopsie with their rigged mesh, the only reliable solution is to not wear that dress until they fix it.

I also forgot that the viewer (read: agent/avatar) will respond to RLV commands via chat.

Can you also give an example use-case where a script will listen to prefixed commands?

It should be totally fine.

How was the key rigged? If you want a rigid/non-bendy object rigged to something, it just needs a single vertex weight at 100%. In this case the entire key should be rigged only to the hand bone, no fingers/forearm (and no automatic weights).

Particle effects are not rendered in the HUD, so right now it's impossible to do this.

The full description for HTTP_CUSTOM_HEADER being: It seems reasonable that this is referring to the X-SecondLife-* headers. Especially because of things like this: If these headers (including owner name, object UUID, location, etc) could be set by the script, they'd be very easy to abuse.

And if you were to go the viewer-code route, you could either make an extension to RLV (since that's a system that bridges the gap between LSL and viewer functionality via llOwnerSay commands), or look into the Lua scripting system used by Cool VL Viewer. I don't think there's a way to get data back into the LSL script though, since scripts run exclusively server-side.

You can log into the Jira with your normal SL account. Here's a partial quote for convenience though: These are Unicode character codes, which can be created with llChar.

If the account is on hold, it's only temporary. You can save your money until after they release (or ban) the account.

And it does! If you only want results for a specific phrase/term, you have to put it in quotes, even if it's a single word.

It probably is a generational thing with mental health problems on the rise and all that. At the same time though, if someone's going out of their way to act spiteful or malicious, what good does it to keep the interaction going?

If you have nothing to contribute, don't. Whether or not Second Life compares to modern shooters is irrelevant to what's being discussed here.

12 years since creation, 9 years since last post. 😄

Username checks out.

If you'd like help in-world, lemme know. Below you can see the steps I took to upload a wall like yours.

Yup, something like this would be tremendously useful! It should be enough to get rid of scripts in most cases and for the vast majority of rezzed projectiles/bullets.

Ah, I see my mistake. This is what I tested with when I wrote my post: My avatar is standing in the gap (mesh is 0.01m thin) just fine, but the model is already convex so that's working as you would expect. (It turns into a cube at 0.2 meters too. I'm used to seeing the shape looking like that square since that's what more complex objects get turned into.) Using an arch also worked as you said.

Utilizator makes very well supported, modifiable, specifically anime-appropriate heads. https://marketplace.secondlife.com/p/UTILIZATOR-M4-Mars-Head/15400618 https://marketplace.secondlife.com/p/UTILIZATOR-M4-Venus-Head/16696802 I would probably use one of these for an FFXIV-styled avatar, since they share a very similar shape. (Savage raider here!)

This isn't exactly true, but it's also more complicated than I can explain. 😅 The minimum size is 0.2 meters, but only for a square object. If the mesh object isn't a square, it can even be the minimum width of 0.01 meters and still keep its custom shape. There is also a certain threshold where a complex physics shape (of any size!) is forcibly turned into a convex hull.

Land Impact will always be the highest cost of Download, Physics, and Server. At the bottom of the upload window, there's a section for "Physics Cost." The line that says "Mesh" is the physics cost your model will get when you set the mode to "Prim." (It's not intuitive but that's how it is.) The physics model should always be the bare minimum in the complexity of its shape, avoiding high triangle counts and concave surfaces is ideal. Using the highest LOD is almost never a good idea because it's rarely efficient as a physics shape. Although we can't really see your model, we can see that it has 156 triangles which is probably not what you need for a wall with a door. I'm guessing your lower LODs are auto-generated, so using those probably won't give good results. To get a much smaller cost (easily 1 LI in this case), you should just make a separate (simplified) mesh that matches the overall shape of your wall and select that as your physics shape, or analyze your model in order to generate one. (The physics mesh does not need to be unwrapped, textured, or anything.)