Wulfie Reanimator

I'm like 99% sure that you cannot create a particle that moves in a circular motion like this with llParticleSystem. You can cause particles to be generated in a ring, but not cause them to move along that ring. Technically it could be possible, we can even see an viewer-side effect like this when an object speaks. (You know, those white particles that rise in a spiral motion.) But that effect can't be replicated by scripts because we don't have the right parameters available. As a workaround, you could make the emitter itself spin with llTargetOmega, and then work on the particle system. This method just has some caveats that complicate a general build.

Last I checked, any objects that are attached to the head-related bones (skull, eyes, ears, etc.) are hidden when you enter mouselook. Make sure your rigged objects aren't attached to something silly like your right hand (which is the default location for all objects).

If you have an MFA token (for a service that generates your keys, such as Linden Lab's login system), you can store that in Bitwarden for free. If you want to use Bitwarden's service to generate those keys, that does require premium, but that wouldn't work for logging into SL. Edit: You're right actually, it didn't work the way I thought. You would need the subscription to generate keys locally.

I use BitWarden, which works on desktop and mobile, has browser extensions, doesn't require an online connection, and it's free/open-source. The only serious recommendation I would give is: Don't use LastPass. They've had four security breaches this year alone.

There are also merchants like Izzie Button who make extra layers specifically to add cleavage shading to (or hide it from) skins.

Right-click the hat in your inventory, then select "attach to..." and "skull." This way the hat will be positioned relative to your avatar's head.

Well, if the item uses BOM (Avatar-Bakes On Mesh), then it would be normal that it doesn't come with an alpha layer. Your system body is automatically hidden while you're wearing an attachment with BOM. But if this item (the body?) is supposed to work with BOM, and your system body is still showing, you've possibly changed the texture of your body. Maybe you clicked one of the skin options in your HUD. It's hard to help since we don't know anything about your attachments or that item name.

Would also be nice if Marketplace had an option for merchants to bundle variations of a product (different colors, permissions, whatever) as a single product listing. That's pretty basic stuff for online store design. There'd be less need to copypaste keywords when you're planning to upload dozens, let alone update them later.

Looks like you've simply taken off your mesh body's alpha layer, and now the system body is showing through it.

While it's technically possible (to render textures from one model to another with shrinkwrap etc), I'm pretty sure most creators just redraw/fix the skin for the heads that are incompatible or significantly different in certain areas. Most heads will use roughly the same UV mapping (the LL head UV map), so the texture you've created for one head can be used on most other heads that share the same UV base. You don't need a devkit for all of the heads you wish to sell for.

Give them time to investigate. What's your sim called?

The TOS doesn't prohibit sims from excluding avatars based on their appearance, or things they do/don't own. Personally any RP place I've been at has never forced people to buy anything to participate in the way they like, so in your case I'd start looking for other places.

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.