Wulfie Reanimator

That's not something you can fix. It's a mismatch problem between the two mesh objects. Specifically, the "directions of the face-normals" are different at the seam. To fix it, the creator would have to get both models and make them match, then upload the updated to SL so it can be given to customers. You can tell this is the issue because the top of the body's neck (below the "seam") has a shadow on it, but the neck just above it doesn't. If the "face-normals" of both mesh objects matched exactly, lighting would behave identically on both of them, making the seam disappear because they'd both have a seamless shadow or no shadow.

People need to stop confusing (or vaguely describing) user-functions written by other people with actual LSL functions. These are very distinctly different things, presented in a very different way on the wiki.

Hold up... Wasn't that Upland?

How many games have you heard about that are similar to Second Life? I tend to agree but... SL has (2018) around 500K monthly active users. Roblox has (2019) 90-100 million. Monthly. I can't actually find a report on SL's revenue, but Roblox is estimated to have annual revenue around 400-440 million USD. These virtual sandboxes are not numerous, but LL certainly has competition on both fronts (Tilia and SL).

Off the top of my head: Klarna Skrill Venmo Cash App Google / Amazon / Apple / Mobile Pay Others that seem to be widespread: (I found so many more but these stood out) Payoneer Stripe Square FastSpring

You can't really compare Second Life with just any MMORPG. These are two very different genres. The crowd that's interested in MMORPGs does not inherently care about SL, even if SL looked and ran just as well. Second Life is in the same genre as, say, IMVU and Roblox. (Sansar and VRChat are their own VR-genre but are no match anyway.) They are sandboxes where users create and share the content using built-in features. The quality of that content at any point in time doesn't define how "good" the platform is.

I don't think that's right. There are many other money services similar to PayPal. I could probably almost count user-driven virtual platforms with one hand, and none of them can complete with SL in terms of size and economy. IMVU might, no idea.

I might have some time to help during next week, but depending on the dimensions of the build, it can't be done as a single upload.

Yes, I know. I play with glow settings a lot. But if a random user had been tweaking them (or they get randomly changed for some unlikely reason), it's easier to just guide them to set everything to default.

I've seen it done for some unpackers, for example. The unrigged parts are displayed as a normal HUD you can click on, but at the same time -- although you only attached one thing -- your avatar will also have a shopping bag or something show up in their hand and play an animation. From your perspective, it's quite neat. I definitely went "wow, how does that work?" But from another avatar's perspective, your avatar is just playing a random hold animation with nothing in their hand. Not the weirdest thing to see, but definitely not the intended effect.

Is this the same build you were offering 10K lindens for, but ended up paying 250 USD?

I can almost guaranteed that what you're seeing are renders from the same 3D modeling software the skybox was created in. It's not a representation of what it even can look like in SL. In fact, the overall grainy-fuzziness (especially on all the white surfaces and in the top-center, behind the window and in the staircase) that covers the screenshot looks awfully familiar to results you get from Blender... But as far as "jagginess goes," that can be fixed with anti-aliasing. The best kind is to take a screenshot with a much greater resolution, for example in 5K, then scaling down the image to the intended viewing resolution. Saturation and overall lighting can be tweaked with windlights, especially by creating your own (edit a preset), and using Firestorm's Phototools (Alt-P). Reflections are tricky, considering how real-time reflections are costly to render, but Black Dragon for example does have Screen Space Reflections.

Holy ****. I just read the wiki page since it was finally linked and I have context. Yes. It has nothing to do with sit-targets. None. It doesn't even use them. It doesn't even try to fix the issue of "no room to sit." It's literally just a more complex way of keeping track of which avatar is where in the world. [uuid, position, rotation, uuid, position, rotation, ...] That page and script was written by a regular user just like you and me. You don't even understand the description of the intention of the code. Not a single thing I've said in this thread is inaccurate, not even my very first post when I didn't yet know exactly how sit-targets work. My explanations apply 100% to the problem you're having. You don't even understand why "I wasn't shocked by PrimPossible." You haven't understood one word of what has been said by anyone in this entire thread. You are helplessly clueless. You read something on the wiki, misinterpreted it, and believe it as gospel. You remind me of Steph Arnott.

It's not perfect, but search for "maitreya AND petite" or "lara AND petite". The 'and' must be capitalized. That said, I found this and it's hilariously perfect: https://marketplace.secondlife.com/p/PCP-Toilet-Paper-Stuffing-White/19936479

If you're on Firestorm: Alt-P (Phototools) "DoF/Glow" tab Click the "D" (default) button on everything under Glow Settings This sounds like the third time someone posts about this issue in recent memory. 0.22 = 22(%). That's a lot of glow, not "nothing." It gets even more intense during default "midday" windlight. It's the least bright during the night because glow is affected by the emissiveness of the surface, and the surface shown in the OP is fullbright.

Your posts are very difficult to parse but hopefully I understood: You're using llLinkSitTarget to give enough links (different ones...) a sit-target. Your object is actually a linkset of multiple components, not a one-piece mesh chair. You're still getting "No room to sit here." Below, I've linked together two prims which are placed in the exact same position, one of them is just twice as big: state_entry() { llLinkSitTarget(1, <0,0,1>, ZERO_ROTATION); llLinkSitTarget(2, <0,0,1>, ZERO_ROTATION); } You can see that even though my linkset is completely encased by another (solid) physics shape and both seats are inside of each other and both sit-targets are in the same place, I am able to sit onto the seats with both of my avatars. This would never be possible without sit-targets. So, if you're using llLinkSitTarget and still getting "no room to sit" errors, you are not setting them correctly. There is no problem with the sitting system, sit-targets have always worked like this. "Back foot?" Do you think I'm trying to defend some opinion here? I've spent five hours today with @Profaitchikenz Haiku, trying to figure things out and explain them to help you. I'm glad I at least wrote the above before I noticed this part, so others can benefit. I'm done, good luck figuring out your own mess. What an absolute waste of effort. I have no words.

Alright my dudes and dudettes, it's illustration time. Let's continue with my example of a tiny cube, with a sit-target one meter above it. When an avatar selects the "sit" option, a request is sent from the viewer to the sim. Because the object has a free sit-target, an avatar can always sit here, even though the blue box is actually occupying that space and would normally prevent sitting. Now another avatar wants to sit on the same object. Since the sit-target is already occupied, that cannot be used. Instead, the sim will now use the old method of "try to find the closest suitable surface to sit on." If I right-click on the back-edge of the prim, this is where the check happens: Here, keep in mind that the blue box is a real object, with its own (identical) physics shape. The red box is the new physics-shape being checked by the sim, and clearly it overlaps with the blue box, so you will get "No room to sit here" and the viewer will not complete the sit-action. All of this happens before the script even becomes aware that someone is trying to sit on the object. If I move both boxes out of the way so the sit-action can complete, the avatar that is already sitting and technically occupying the space above the second one seems to be ignored because it's on a sit-target. (And for illustration purposes I've moved the red box back into place after the sit has succeeded.) The point I am making here is that you can have multiple avatars sitting on a single object. You can even have multiple avatars sitting on a single object which has a sit-target. But any avatar after the first will not be placed on the sit-target, but rather gets placed "normally" as if there was no sit-target at all, which is subject to physics-checks and can fail. It's easy to conclude that "you can reset the sit-target to allow multiple avatars using the sit-target of a single object," but that's not what's actually happening. If you check llAvatarOnSitTarget, you will always get the avatar who sat when the sit-target was free. Also, if you were to move the first avatar 3 meters forward (for example), the second avatar would still be subject to physics-checks around the original location of the object, not where they would be placed after they have already become part of the linkset.

The avatar's physical shape is not accurately shown in any of the debug views built into any viewer I know of. The exact shape can be revealed with simple raytracing using a script with llCastRay. For example, below you can see standing and ground-sitting avatars. An avatar sitting on an object is similar to ground-sitting, except the flat-top pyramid would be stretched forward like a wall. It does not need to overlap with the other object, it only needs to overlap with the avatar that's about to be seated. The avatar will require much more space than the chair itself. I don't know yet. I'll have to do more science to figure that out. It may very well be that he just thinks it works because of the fallback-method.

Elementary, my dear Watson. But you must not have any other objects too close to the seat. Your piano is too close. In the first picture I showed, the table and chair are all one mesh object, not a linkset. But you must touch the object before you can sit, which causes it to rez a new object, which is a linkset with enough links to seat all intended avatars. That rezzed object is more than 1 LI, so PrimPossible is "cheating" a bit.

1 prim chair-set from PrimPossible: (If you try to sit on this, you get "No room to sit here.") After clicking on it: (This mesh "shell" covers the original object completely, and can be sat on.) A seated avatar becomes physically very wide, which is why they tend to block each other from sitting. However it's not completely impossible to sit directly on the same spot as another avatar, but this is what I would call a bug or at least "very quirky." Here I've rezzed mesh cube that's 0.2m on all sides. Whether or not it has a sit-target (set in state_entry and my test dummy is already sitting on it), I can sit on it just fine: video ("Fine" is a relative term.) I believe the exact position my avatar is being put in this case is the flat-top of the already-sitting avatar's physics shape. Because avatars become a part of the object they sit on, the physical shape of the avatar is added to the object and the closest sittable surface just happens to be on top of the first avatar. But if I place another object 1 meter above the first avatar or sit-target, I get the "no room to sit here" problem. I believe this is because the physical shape of my avatar's seated state collides with the other object I added above the intended seat. The same is caused by the table's physics shape for the PrimPossible set, and the piano next to Kitten's seat. I should also point out that no matter what, if the object has a sit-target with no avatar sitting on it, you can always sit on that object regardless of what objects are around it. This is why I suggest that people use at least one link per seated avatar. When all sit-targets are occupied, SL will try to use the old method of finding the nearest surface to sit on, which can easily fail. Sit-targets work the same for prims and mesh. One link = one sit-target, whether or not it's a prim or mesh. Having separate physical surfaces in a single mesh object does not enable multiple sit-targets.

If you want multiple llLinkSitTargets, you need multiple links in the linkset. The chair you're sitting on looks suspiciously like a single piece of mesh, unless the piano (which seems to be a separate object from the chair) is also supposed to be sat on. Also, llLinkSitTarget should be called in state_entry and not changed afterwards, in case you're trying to set a sit-target in the Changed event.

@Pussycat Catnap Here you go.

That's no excuse to try to make rezzing the items impossible. Maybe the owner is even okay with that LI-cost.

What does the log say?

Memes are my favorite meme.