Wulfie Reanimator

While you can technically reflect the world/avatars with PBR materials, it won't work quite right and LL is working on proper mirrors.

What if you hit LL ground, or a sim border, or nothing at all (because of limited ray length)? There's nothing for particles to target there. Maybe your target is in a large mesh room, and the particles from your weapon fly toward the center of that room instead of the wall behind your target (because particles can only move toward the center of objects). Speaking of your weapon, if that's the source of your particle effect, the trail will move and wiggle around as your avatar moves around, which just doesn't look as good as a trail that stays on the trajectory of the ray.

The combat event log is one avenue to help moderating things kind of thing, but yeah, my guess would be that the SLMC crowd would opt out of damage adjustments. I don't think that's necessarily an issue, though. The SLMC is kind of a special case in its wild-westyness. The ability to adjust damage should be a useful feature in broader context, especially in closed systems where most of the potential pitfalls can be designed around.

The damage type is just an extra value that allows the receiving scripts to do something according to the damage type. On its own, it's just data and doesn't do anything. For example, if you were a knight wearing plate armor, a script in your breastplate could reduce all Slashing damage you receive by some amount, but Puncture is unaffected. You could take it even further by having your armor lose durability and becoming less effective at reducing damage. Or the script could increase all damage without even looking at the damage type. Or the script could allow damage as-is, regardless of its type. While no-rez style combat can work and be fun (I really like a sword-fighting system called CornerStone from 8+ years ago), the problem with long-range combat is the lack of feedback between players. How do you know someone is shooting at you from 100 meters away? Raycast weapons need to create some kind of visual effect on every attack, like a particle-trail (which requires rezzing), regardless of hit or miss.

Just to repeat one thing that's been talked about regarding the on_damage event. There's two concerns about its side-effects. How do we handle cases where scripts in separate attachments adjust the received damage in different ways? Although llDetectedDamage can give a script the original and currently adjusted amount, there will be unavoidable race-conditions from the script scheduler, and the different workloads in each script. The adjusted damage value can change after a script has checked it. And now that all attached scripts must finish their event before damage is applied, it'll cause a delay before the avatar actually dies. That allows them to keep going and dealing damage even after receiving a to-be lethal hit. This can be caused unintentionally by the script scheduler or different workloads in each script, or intentionally with llSleep or a "do-nothing" loop. I'd suggest a maximum time limit until a damage instance is applied. This isn't intended to prevent cheating, but rather to keep combat feeling responsive. The feature already kinda exists in detaching attachments; scripts are allowed a short amount of time to execute code in the attach() event, before the attachment finally gets derezzed. I don't know what would be a reasonable amount of time, but the concept seems solid.

That seam will ultimately be visible even if your skin is a plain single-color texture with no details. Because the head creator did not match the vertex normals (technical term) of the neck to the body, shadows will appear differently on the head vs the body. When a new head is created, it's that creator's job to match the edge between their mesh and the body. To be fair, different bodies are likely to have different necks themselves, so it's not simple to match one head to multiple bodies. (But not impossible!) One solution (though not great) is to adjust your personal lighting (environment/EEP) instead of using the overhead sunlight from Midday.

Sorry, I hadn't read the entire conversation and missed the overall topic. The "Websearch" in Firestorm is just Linden Lab's official search page, which is the only way to search anything in the official viewer. Firestorm doesn't control it in any way. https://search.secondlife.com/ I agree that websearch is a much worse search in almost every way. It's slow, the UI and filters are clunky (and lacks many features from legacy searches), and the results are rarely what I'm looking for. The "Land Sales" (and every other tab) are legacy features that Firestorm has preserved.

You already know the answer, you laid it out just a couple posts ago.

You completely missed Qie's point, though. The websearch you showed, or the old "Places" search in the viewer, are used for things other than land sales. The "show in search" option is used by clubs, sandboxes, mainstores, etc. It's not intended for advertising mainland sales. Those results you're seeing are locations where you can find places to rent and pay your rent.

This is the official definition of the term from 2013/14: https://wiki.secondlife.com/wiki/Mesh/Rigging_Fitted_Mesh This page explains which sliders make use of Fitted Mesh (before Bento): https://wiki.secondlife.com/wiki/Appearance_Editor_and_affected_bones Rigged mesh is the general term. Fitted Mesh was an update to the rigging system which added some bones. Bento is "Fitted Mesh 2.0" as it also updated the rigging system with new bones. Fitted and Bento mesh are both rigged mesh. Liquid mesh is a marketing buzzword by some merchants.

The GLTF packer assumes you already have a full set of PBR textures, just to be clear. If you want to create new PBR materials, you need some kind of other software (like Blender or Substance Painter) to design your material first (or just download free ones), then put them into the GLTF packer so you can upload them to SL as a ready-to-use material.

At the risk of extending this argument for another 5 pages... why are we hung up on the circumstances of the reports? No matter what, the people who report listings are not at fault for the creator breaking well-known rules, nor LL's response to the reports, nor the merchant's reaction to the unlistings. If unlisted products can't be relisted by the merchant after making fixes, that's one thing to criticize, and the warning system that was mentioned is also a nice idea. With keyword spamming as prevalent it is (it seems to have gotten even worse with the search changes), I would rather see the offending stores disappear entirely and give room to honest products. Just now I discovered stores with every listing pulling scams like this: The worst part is, it works.

Uploading mesh: https://community.secondlife.com/knowledgebase/english/uploading-a-mesh-model-r274/ Creating a store: https://community.secondlife.com/knowledgebase/english/selling-in-the-marketplace-r88/ TLDR: Payment info is required, and the account has to be 5 days old to create a store.

And you have problems with reading comprehension. Obviously, I'm not saying that you aren't having issues at all. The "OP is fine" was referring to you not logging in for a few months/years, which was the only thing I was talking about in the post you quoted. If your account is genuinely disabled, which it seems to be, then the reason for that is not because you did not log in for a while, but something else. There are a whole bunch of different reasons that can cause an account to be disabled (someone trying to reset the password, abuse reports, charge-backs or other outstanding balance, etc.), not just because they're inactive. What even gives you the idea that's the reason? Has support said "whoops our bad, we thought you weren't using it?" That'd be a pretty important detail to mention.

Sure, but do you think that applies in this case when OP said "I might not login for several months"? I have an account that hasn't logged in since 2011/04/30, and I had no trouble logging in just now. I think OP is fine. 😋

LL does not deactivate accounts even if you don't log in for years.

Lindens definitely check them, the response just naturally varies based on how egregious the keyword spamming is, and whoever happens to be checking at the time. Here's a recent thread from a merchant who complained about their keyword spam getting unlisted: https://community.secondlife.com/forums/topic/505602-product-marked-as-spam

Because the URL your script creates is incorrect. 😋 Your URL is this: secondlife:///app/teleport/Shermerville%20Central%2F114%2F125%2F16 When it should be this: secondlife:///app/teleport/Shermerville%20Central/134/97/27 To fix your script, replace llEscapeURL(region+slurl) with llEscapeURL(region)+slurl That said, the broken URL does cause the teleport-rate limit to show up on first attempt. That just indicates a bug in how the viewer or server handles the failed teleport / invalid request. Edit: Eh, better 2.5 weeks late than never.

I would build a list and apply everything in one call to llSetLinkPrimitiveParamsFast. Script efficiency doesn't really matter when something is done as infrequently as 20 seconds. Even if the whole operation takes a full 20 seconds to complete, or you end up sending 15 individual object updates, it's not very significant in the grand scheme of things. The benefit of SLPPF is that all of the colors update at the same time. If you loop or just have a long list of llSetLinkColor, we can see each individual object being updated (or the script might even be forced to idle mid-update by the sim) and it just looks kinda silly (unless it serves some stylistic function, of course).

That article has links to both sites: lslwiki is very old though, I'm not sure it's been actively worked on in years (but it is a nice archive). It was working recently (I checked like a week ago), it might still get fixed.

Oh yeah, you're right. They replaced the flat fee with a sliding scale in 2021. That changes things a little bit, but buying more is still cheaper than buying less.. or I should say more economically efficient. If you buy 3700L right now, your fee is $1.50 (10% of total cost) If you buy 2000L right now, your fee is $1.49 (16% of total cost) Although the second option costs less money overall, you're also paying for nothing. To save money in the long run, you'll always want to buy at least $15 USD's worth of lindens so you match that minimum fee, even if that means waiting longer between purchases.

For what it's worth, buying in large quantities is cheaper. Every time you buy, you have to pay a flat fee regardless of how little you buy. Instead of buying 3000L after 2 months, you could buy 6000L after 4 months and save the fee. Sounds like it could make a significant difference for weak currency.

I don't recall, but I checked anyway and yup, the banline texture depends on your viewer skin. For example: viewer/skins/default/textures/world/NoEntryLines.png viewer/skins/starlight/themes/silver_pink/NoEntryLines.png You can replace the texture with whatever image you want, and it'll be tiled across the parcel boundaries.

I understand your point but I don't think it's a good one, because even if all SLMC groups restricted their sims to only using weapons from certain creators... you've just created multiple closed systems (each sim having its own "approval list") that are really annoying and impractical to maintain when new groups are created or new devs join existing groups. This wouldn't be adopted by the SLMC, I would bet a significant amount of money on it. Other combat sims might, but I don't know of any existing combat things that aren't already closed-systems like VICE or roleplay sims using external GPHUD scripts. Even if you were using a closed (creator-exclusive) system like this, you would still have to moderate the kinds of weapons people use. Currently SLMC groups might ban individual weapons of certain groups/creators, not the whole group/creator. (Some groups allow vehicles or movement boosters, others don't.) And there will be cases where those creators have more than one theme available. Like modern vs futuristic, or medieval vs fantasy.

By the same token, someone could come in with their own magic spell to kill everyone. What about creators who make magic spells and modern guns? I think a problem like this is easily solved by normal moderation, the shape of the weapon doesn't really matter.