Wulfie Reanimator

The reason for high LI is usually either too many triangles (not the case here) or something about the physics shape. An easy way to skyrocket your LI is to make a physics shape with small gaps in it. What does the physics shape for your photo frame look like? Did you make it hollow? It should be just a solid rectangular box. (Don't go for realism when making your physics shapes, keep it as simple as you can get away with.)

This is most likely caused by a bad internet connection. The "stuck walking straight" is definitely a symptom of it. What actually happens is that your viewer is trying to predict what's going to happen until it gets new information. When the last thing the viewer knows is "this avatar is walking straight" before losing connection for a moment, you will see your avatar walking forward forever, because the viewer is extrapolating from what was happening.

I can post an effect here later that inverts the colors behind the particle.

This seems like the kind of problem that happens when your connection is bad. Each time you select an object, your viewer is requesting more detailed information about it. If your connection is especially bad or you are actually reconnecting (you won't notice this), your viewer won't even know what the object's name is when you select it. This may also cause the edit option to be disabled.

But you cannot flag a product as "copyright infringement." Try it. While LL could use common sense and just purge all of the known brands, they cannot, due to their safe-harbor status. They must rely on DMCA claims to act. There must have been something else wrong with your product listing for it to get taken down. I can speak from experience and say that this is almost definitely the case, because we've had so many threads about unlistings that are easily explained.

64 KB * 2000 = 128000 KB = 125 MB, not 2048 MB (2 GB) Unless you're going to have over 10 scripts per object? That said, scripts rarely use anywhere near the reported amount of memory, it's just the maximum limit they're allowed to use. Regarding Homesteads, I don't know if there's a flat amount of memory a Homestead sim can use, but multiple Homesteads (4?) share a single core on a server, so your sim will be affected by other sims you can't control.

I don't understand the point of the question. We can already replace every vital organ in your body with a machine to keep your brain alive. They can breathe for you, they can circulate your blood for you, and we can feed you paste through a tube. You are still you at that point.

Speaking as someone totally uneducated on the subject, I don't believe you could "move your neural connections over to the machine over time." Maybe, but as things are right now (I don't mean technologically but our definition of the mind), I don't think you can do away with the brain without losing the mind. You could absolutely do away with the body if you could still keep alive the brain, at least. To clarify the distinction a bit -- what is "you" is the byproduct of how your brain processes its environment. Your skin, muscles, organs, or skeleton is not you. The closest thing to the physical you is just your brain, everything else is a mechanism for self-preservation of the brain. Moving your brain onto a machine is probably similar to the Ship of Theseus. Is it still the same "you" after the transition or did "you" die somewhere along the way? Maybe that can't be answered and it's as irrelevant as the fact that all of your body tissue is replaced multiple times over your lifespan, but your perception of yourself is continuous. I only believe that creating a perfect simulation of someone's brain is not the same person.

Second Life has far too much technical debt to survive into the future. VR is not for Second Life and vice versa, on a very technical level. Similarly, to "exist forever in a computer" is misleading. Even if we had the technology to create a perfect copy of your mind, your life will still end when your brain dies. That perfect copy running on a computer is not an extension of you, it is an entirely separate person with your memories. Other people may be able to enjoy your preservation, but you won't. My expectation for SL specifically is for it to largely carry on as it has been, maybe for another 10-15 years, until it's superceded by something better or the current death-spiral somehow picks up.

Do you use RLV? RLV can force chat messages to a separate channel. From the API documentation: Basically, go into your RLV attachment's settings and disable the feature.

Try googling "secondlife skeleton" "Rig" or "rigging" means binding your model to the skeleton, so that when a bone moves, a part of the model moves with it. Textures are created in a photo-editor, using the UV mapping as a template. Almost any modeling program should allow you to export the UV map as an image of the wireframe that you created. Clothes can be created exactly the same way as the body itself.

I've been wearing the same hoodie IRL for the better part of 10 years almost daily (I've had to replace the sleeves and the hood seems to be next.) and I've bought new pants twice to replace the previous, exact same ones. It may be uncommon but it's entirely practical! Same applies for Second Life, kind of. While I have (many) multiple avatars, each one has one assigned outfit. My main avatar's outfit is like 4 years old and comfy af.

These are the software-independent steps to follow: Create the model (mesh, unwrap, texture, LODs) Import the official Second Life armature (bones/skeleton) Rig the model Export to .dae Upload model and textures to SL If you are a beginner, as you clearly seem to be, trying to create a whole body as your first project is most likely going to be too complex for your skill level. Try smaller things, like a hand/glove. There's plenty of room for things to go wrong with just that.

Or Omega applier but no Omega compatible/installed body.

This may be against TOS, specifically the Skill Gaming policy. I'd highly recommend talking to Linden Lab first.

Could you possibly link (or PM) the .blend file for the problematic part of the model?

The only difference between "gaming" computers and any other computers is... the marketing. There's nothing particular about them that makes them better for games and a lot of them won't even run the latest and greatest. What you're paying for (if anything) is some edgy design and pretty lights, not better performance. If you're on a budget, you should be picking individual parts and either putting them together yourself or paying a store to do it for you. Computers have, generally speaking, 3 very important components. The processor (CPU) It's the most important part because it's going to be doing most of the work in most situations. For gaming, you'll probably want 4 cores. Less isn't enough and more won't really help. For speed, anything at or above 3.6GHz should be okay, based on personal experience. Memory (RAM) The second most important part because if you don't have enough RAM, your CPU will have to start storing its memory to the hard drive which is incredibly slow. No matter how fast your CPU is, everything on your computer will lag without RAM. These days, 8 GB is the minimum you'll want. (Two sticks of 4 GB) I would recommend 16 GB (two sticks of 8 GB) if you use a lot of programs at once, browse while gaming, or tend to use a lot of tabs. Graphics card (GPU) Now, just because this is only the third most important part doesn't mean that it's not worth the budget. While your computer should be fine with a bad GPU (or none), games are quite dependent on it for good performance. GPUs come with their own dedicated memory. Anything at or above 2 GB should be enough for comfortable SL and browsing. I know less about GPU speeds (at least over 1000 MHz or 1 GHz), but I would assume that almost anything that has 2 GB or more memory is also fast enough for SL. What you will also need is storage (HDD or SSD, SSD is faster but smaller and more expensive), a case (duh), 1-2 fans, power supply, and a motherboard, which is the "base" that all of those components connect to. Which one you'll need depends a lot on what parts you get. You can probably find the CPU/GPU you might want and then go ask a store for help. There are also websites like this one that only show you the parts that are compatible with what you've already picked. There are other much less important details, like what kind of HDD/SSD you should get or what kind or how fast your RAM should be. These details are something you would only worry about if you wanted absolute peak performance in modern games -- which SL isn't -- or wanted to play on absurd resolutions like 4K or 8K. I should also point out that no matter how good your computer is, SL will have low framerates. (20-40 on average, depends a lot on where you go.) Don't go spending over a thousand dollars on a computer you'll only be using for Second Life. It's not worth it. Laptops are also not worth it, you'll pay more for less, unless you need to be able to move it around. Usually the reason for people buying laptops is that you just have to buy one thing and it's easy, but it's not going to last as long because it's going to gather dust and slow down while being very difficult to clean.

I'm a little fuzzy on the details, but according to some notes I wrote to myself in the past: Angular motor direction is the vehicle's "velocity around the Z axis," meaning how fast it's currently trying to turn to the side. Angular motor decay is how fast that velocity decreases to 0, meaning the vehicle will stop turning without input and just driving straight. Linear friction timescale is how fast the vehicle will "roll to a stop" after you stop accelerating. Angular friction timescale is how fast the vehicle will stop "drifting" sideways for example after making a sharp turn at high speed, or bumped by another object. I don't know how accurate these statements are. I haven't really used vehicle params.

The problem with this is that there are few ways to move the avatar in a scripted way. The most control you can have is llMoveToTarget, but you can't effectively control the avatar's rotation at all. An avatar will tend to slowly face towards the direction it is being moved with MTT, but you can't speed up or slow down that rate. Similarly, you can't tilt an avatar forwards/backwards when going up/downhill, so you will have to rotate the attachment itself for pitch. (And create animations for each angle, if the avatar is meant to be visible.) Speaking of slopes, since you won't be using physics to control the vehicle's movement, you'll have to use multiple llCastRay calls to determine the angle of the surface you're on, or if it's even driveable. The problem with this again is that if your vehicle is meant to be driveable out of mouselook, you can't place those raycast checks to accurately match the orientation of your vehicle. I'm not saying it's impossible, just fairly complicated.

Just to reiterate -- you cannot raycast from an attachment. You can only raycast from the center of the avatar (positionally speaking) because scripts can't know where an attachment is relative to the avatar and its animations. That said, I would primarily recommend llSensor with a low arc (<180 degrees). llCastRay is too precise for melee weapons as it has no width. If your melee weapon has any kind of swing to it, it won't feel good because a swing is generally a relatively wide attack. Even for thrusting weapons I would recommend the same, because what you see on the screen isn't very accurate and an avatar might move out of the raycast's way due to script lag. The minor inaccuracies of llGetRot are marginal when using an arc. You can still use llCastRay from your avatar's position to the target's position, to make sure there are no obstacles between you two. (Line-of-sight check) That said, if your weapon can only be used while in mouselook, you can use llGetRot to get 100% accurate results.

llGetPos/llGetRot don't behave any differently based on which point the attachment is on, though. They're not getting the attachment's data at all. Let me illustrate a bit what this "inaccuracy" looks like. I'm using an unattached prim with this script in it: default { state_entry() { llSetTimerEvent(0.1); } timer() { list od = llGetObjectDetails(llGetOwner(), [OBJECT_POS, OBJECT_ROT]); llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_POSITION, llList2Vector(od, 0), PRIM_ROTATION, llList2Rot(od, 1)]); } } So all it does is try to mimic the avatar's physical position and rotation. You'll notice that: The rotation can be off by around 45 degrees occasionally. (Best seen at the end.) The rotation does not follow the avatar's facing direction while walking sideways or backwards. (Client-side effect) The rotation changes on its own when no movement or turning is happening. (Alt-cam) The rotation changes when the avatar's visual representation doesn't change. (Turning less than the visual threshold)

"i have several intruders every day!" "Where?" "I'm just pointing out a problem with the system." 🤔

This (dynamic/weak typing) is essentially what JavaScript does. It has problems though, such as the compiler (if there was one) not being able to make sure that the script won't error or crash because of a type-mismatch. a = 123; b = "abc"; c = a + b; // no warning while saving the script, but will error/crash Whether or not this would cause the script to crash entirely can be determined by how the feature is implemented. The script could, for example, just give a debug error and keep running, but it will either start producing more errors or not doing what was intended if the script relies on that third variable. What would the type even be? Look up "gatekeeping."

The only way to make 100% sharp boundary in your rig is to split the edges. (Look for "Edge Split") If you have a continuous face (everything connected), there's always going to be a visible stretch between the weight boundaries.

Doubtful. RLV doesn't do anything to violate privacy to begin with, and it already controls your text chat by being able to disable it or redirecting it to a different channel. I'm guessing disabling voice is what's being asked here, which is reasonable but I don't know how possible (since SLVoice is a separate process and it would've probably been implemented already).