Wulfie Reanimator

I'm not saying something so reductive as "adding skintones is too much choice." I'm saying that a new user -- who knows nothing about Second Life -- may think that these are all the choices they're going to get when presented with a set amount of starter avatars, or that some aspects of their avatar (such as gender) would be unchangeable. You haven't even finished signing up but you're already disappointed because you don't like your options. There are very few games (even MMOs) that have as much customization as Second Life. Not every game/MMO allows you to switch genders, especially without paying a fee every time. Heck, there are people who play Second Life but have never touched another "game" in their lives. Besides that, it's an extra step in the signup process. Any step, no matter how simple, adds complexity that will turn some people away. LL has said as much and they actually have stats to make decisions with. The removal of last names is the most notable feature they cut because of its effect on new user signups. I'm not here defending LL's decisions, I don't even agree with them. I'm only explaining the what/why.

You don't need one to pee though. 🤔 Certainly missed a couple biology lessons.

Two pinned topics on the LSL Scripting forum:

Careful there. What for. I'm being light-hearted as I'm sure you are too, but what you're saying is that the genitals you have is what defines your gender. P**is = man. No p**is = no man. This line of reasoning is something trans people find very distressing, both male-to-female as well as female-to-male.

Careful there.

More choice = more good, sometimes. There are many reasons related to human psychology to reduce choice. Look up "analysis paralysis" and "beauty in simplicity (in design)" for example. LL has used these to reduce the complexity of the signup process in many ways for new accounts. But I think the main reason for the overall tone of responses in this particular thread (not seen as much in other threads with similar subjects) is the opening line. "I chose non-binary and was given a light-skinned/white avatar." Like, excuse me? Light-skinned/white people can't be non-binary? Or is it the skin color in general that's the issue? They did follow that up with "okay, it's fine" but then made the whole thread about how it's neither okay nor fine. That totally comes off as playing the victim and/or what some people call SJW issues.

What are the specs of your "beefy" PC?

Except you generally don't rent month-to-month IRL, you enter some kind of contract that forces you to pay for a set period of time, no matter how little time you spend there. Even if you were renting month-to-month, you would pay for the full month before moving in and probably not get refunded if you left the next day. The same applies to most subscription-based services, where getting a refund for the unspent time is the exception.

Your problem is a type mismatch. default { state_entry() { list stuff = ["779e1d56-5500-4e22-940a-cd7b5adddbe0"]; key who = "779e1d56-5500-4e22-940a-cd7b5adddbe0"; llOwnerSay( (string)llListFindList(stuff, [who]) ); } } This script will return -1 (not found). Why? Because the list contains a string, and who contains a key. They may look the same, but they aren't the same.

More like a month ago. The old dark theme (or the old white theme with Dark Reader) we had worked well enough. This new theme broke dark mode. (And while I normally use the Dark Reader plugin, this new theme somehow manages to have some parts of the page stay completely white which is worse than reading black-on-black text.)

A+, these are so rare. Also, generally androgynous singers.

The importer in Second Life doesn't support this. You'll have to upload the mesh and texture separately, then add the texture by hand.

I like any vocalist with a wide range, so I tend to like men who can hit high pitches and women who can hit low pitches. For example, PelleK has a really impressive voice: (This isn't a song, you can skip through it.) But the primary thing that decides whether or not I like the songs are the lyrics and subject matter. As much as I like his voice, I don't like most of his covers because of the kinds of songs they are and how he doesn't always go through many different ranges of his voice. That said, on average, my playlist is mainly filled with either female vocals or high-pitched men. I guess I like softer vocals with a bit of low-tones mixed in. Alec Benjamin is a good example of the kind of vocals I like. He varies a lot between low and high in every song, but mostly stays on the high end.

If you're losing money, LL is losing money. LL doesn't make a commission off of in-world transactions, so why would they encourage that after raising their own MP cut? Lay off the conspiracy theories.

The simplest process that comes to mind is... Make your light: Add a curve into your scene and position it how ever you like, then add an Array and a Curve modifier to the single light: (The offsets are up to you, the most important thing is to select the "Fit Type" and "Curve") You'll end up with something like this: And then you can either manually connect the wire, or add another cylinder into the scene and make it follow the curve as well. Next you'll have to figure out LODs because something like this can easily have very high LI if you mess it up. Your physics model will be a simple box and in-world you'll set the object to be phantom so people can't bump into it. An decoration like this has no real use for a physics shape in SL.

You're not doing anything wrong, LL hasn't set the theme up properly.

How is BOM a hassle? Using appliers is way worse... Not using a mesh head also literally forces you to use BOM. There's nothing else.

The #1 strategy to getting people to your hangout spot is to already have the people. If you're alone in your club and a new visitor shows up, they're gonna look at a ghost town with one lonely person in there. That's not a very interesting place to spend your time at. If you have a dozen or so friends who you can get to stick around your club, you have a better chance of getting new people to actually stay around, and slowly grow that way.

This is a repost/rephrasing of my original comment from another thread: Let's say you have some rotation (for example, another object, or some orientation of your choice) and you want to calculate a new rotation around that. This can be done by converting the rotation to a vector, and changing one(!) of its components. In this case, let's say you want your object to rotate around a vertical (Z) axis, just like how you would spin if you were turning around while standing up. This can be done by simply adding the desired angle to the Z component like this: ("rad" is short for "radian", instead of degree) rotation rotate(rotation R, float rad_angle) { vector V = llRot2Euler(R); V.z += rad_angle; return llEuler2Rot(V); } So what's so special about this? Well, the cool thing is that if instead of ZERO_ROTATION (where the Z component matches the world's Z axis or "up" direction) we had some totally arbitrary rotation, such as <0.297147, 0.872802, -0.380856, 0.069782>, the Z component would still be the "up" direction of that rotation. Let's use proof-of-concept to show that it works: rotation rotate(rotation R, float rad_angle) { vector V = llRot2Euler(R); V.z += rad_angle; return llEuler2Rot(V); } default { state_entry() { key target = "9c5cce0f-5559-6fd8-d023-8672ad91b9a0"; while (1) { rotation target_rot = llList2Rot(llGetObjectDetails(target, [OBJECT_ROT]), 0); rotation r = rotate(target_rot, llGetTime()); llSetRot(r); } } } The target is the blue arrow, pointing along its Z axis. Every time the loop repeats, the white prim (with the above script) will match its rotation with the blue arrow, with an angle (based on time) added to it to make it appear to spin around itself. The same method can be used to move the object itself around some point. rotation rotate(rotation R, float rad_angle) { vector V = llRot2Euler(R); V.z += rad_angle; return llEuler2Rot(V); } default { state_entry() { key target = "955211a9-9398-a1c3-a63b-b34d03efb805"; while (1) { rotation target_rot = llList2Rot(llGetObjectDetails(target, [OBJECT_ROT]), 0); vector target_pos = llList2Vector(llGetObjectDetails(target, [OBJECT_POS]), 0); rotation r = rotate(target_rot, llGetTime()); vector offset = <0.3, 0, 0>; llSetPos(target_pos + (offset * r)); } } }

There may be a time when you want to move physical object(s) around some point, for example like a tornado. llPushObject can push things in a linear direction, as well as make them spin around themselves, but the physics system in Second Life is not complex enough to simulate air resistance in such a way that could make spinning objects with "curved" trajectories (besides vertically due to gravity). So here's a pretty simple script that demonstrates how to make a series of pushes in such a way that the object appears to be pushed along a more complex path. It works by getting the direction of the target from the center-point, and pushing that target about 90 degrees to the side. When this is done repeatedly, you end up with a circle. default { touch_start(integer n) { key target = llGetOwner(); while (1) { vector dir = llList2Vector(llGetObjectDetails(target, (list)OBJECT_POS), 0); dir -= llGetPos(); // Direction from source to target dir.z = 0; // Ignore height difference dir *= llEuler2Rot(<0, 0, 90 * DEG_TO_RAD>); // Rotate 90 degrees around Z dir *= llGetObjectMass(llGetOwner()); // Adjust the push force according to the object's mass. llPushObject(llGetOwner(), dir, ZERO_VECTOR, FALSE); } } } Here's a visualization: Note: This is a very simple scenario. In cases where the force is stronger, you'll find that the target is gradually getting pushed further and further way (kind of like a spiral). This is because we're just doing little nudges directed away from the circle. To account for that, we could rotate more/less than 90 degrees, like this: Notice how the push direction is going back into the circle (towards the center-point) a little bit? This helps the object "stabilize" into some radius. I say "some radius" because without doing the math beforehand, it can be pretty hard to tell how the physics play out. If you push too far into the circle, you'll pull the target in and might even cause it to shoot past the origin and create an unstable ellipsis like this one:

A lot (like 99%) of the things suggested in that page are sooo subjective and don't really affect your workflow at all when it comes to Second Life. Flip header to bottom Snap during transform by default Enable X-Ray Disable outline Hide Gizmo So much more... Some useful nitpicks from me though: 3D Viewport Viewport Shading (solid mode), Shading Enable Backface Culling (Second Life and most other games do this.) Properties Editor Scene Properties Unit System: Metric (Second Life uses this.) Unit Scale: 1.0 (1 unit = 1 meter) Blender Preferences: Interface Disable splash screen Enable developer extras (Only if you know why.) Keymap Make a keybinding for "Center View to Mouse" I use Alt + Middle Mouse (Optional) Remove the "Play Animation: Spacebar" keybinding (Optional) Add a "Search Menu: Spacebar" keybinding System Increase your Undo Steps

How do you define "SL friendly?" Besides picking the SL preset during export, there's nothing particularly special you need to do.

It would help to see the UV layout (not the texture) as well as the other side of the mesh so it matches with the actual texture. Your second screenshot is showing the backside which adds too many things that could be going wrong. And of course, remove the offset.

The newest comment was made 2 years ago.