Wulfie Reanimator

As long as it feels comfortable for you then I guess there's no harm, but... movies (non-interactive media) tends to play at 24 FPS or higher. For interactive media (such as console games, but anything interactive counts), the standard minimum acceptable framerate is 30 FPS. With a modern PC you should ideally get at least 60 FPS which makes controls feel very fluid. 60 FPS is absolutely not necessary for SL, but personally I would start getting annoyed around 20 FPS. Higher FPS is objectively better, but your tolerance for less is entirely subjective.

I was on a Netflix binge and did one more to do a properly complex object with many parts. Mainly based on this image. Unfortunately the radius for this mesh is so small that I just can't use more than 20 triangles on the lowest LOD and stay under 1 LI, so I couldn't make it anywhere near as clean as I wanted. With a lot of experimentation on LI results...

Differentiating "FPS / frames per second / framerate" and "ping / latency / delay" is the only useful way to talk about the issue of "lag." That little word means nothing on its own.

Assuming you have the latest V5 Lara, go to the "Skin/Base" tab in your HUD and click on "Bakes On Mesh." This will put a "magic texture" onto your body which will allow you to wear classic system layers on your mesh body. If you have not updated yet, or want to do the same on other mesh bodies that don't have a button like that, you can use one of the many free Omega appliers to get that magic texture. For example: https://marketplace.secondlife.com/p/Apricot-Paws-Bakes-on-Mesh-Omega-Applier/17969534

As a Scandinavian who's been to America: Yeah that's pretty spot-on. It's very weird and awkward when a stranger tries to start a conversation in public, but many Americans seemed really chatty.

I think the cap is around 500? That said, what do you hope to achieve with blocking them? It's not like they're talking anyway. You have a separate blacklist for derendering things, you can use that instead if low FPS is the issue.

I have no idea what could cause it, but I really dislike Gyazo because the page it uses to display images is horribly made if you try to zoom in. ShareX seems like the superior alternative in general because you can choose where to upload, like Imgur. It has a lot of features though, kinda daunting for a new user. Personally I use an old and simple thing called Puush, but I don't think the client I'm using is even available for download anymore.

http://wiki.secondlife.com/wiki/Angle_Between_Two_Vectors float angle = llAcos(<1,0,0> * target - llGetPos) Or rotation rot = llRotBetween(<1,0,0>, target - llGetPos); float angle = llAngleBetween(ZERO_ROTATION, rot);

Problem with this is that it's not uncommon for the textures to be hard-coded into the product itself. For example, not only did I recently help someone implement this in a concise way, but I've also personally written certain products so that they only listen for non-UUID messages and then apply a fixed UUID from a fixed list. Even if I told you the exact channel, there's nothing you could do. That's not even deliberate, it's just a side-effect of wanting to be secure and not transmit UUIDs over any channel, especially when the channel is just "0x" + llGetOwner(). (Never mind that they can be found in your cache, but still.)

No, LSL doesn't have wildcards. Your best bet would be to filter by type, and then look for those names (or a partial match).

We're talking about very nebulous things right now. The question essentially boils down to "does it take longer for the sim to parse my longer message string than the speed increase of using a higher/lower channel?" There's no way for us to objectively determine that, and even LL's internal answer should be "it depends." It doesn't even matter how "fast" the channel is because the main bottleneck is the script-scheduling system. Then how the listener is set up. Then how the listen event is set up. How many checks it's doing and what order all of the different commands are checked. SL is not built with speed or precision in mind. You're not going to be doing 360-no-sight decapitations no matter how performant your particular script is. Sometimes the sim just won't let the script run because other scripts need to go first.

The tire was a fun example so I tried another more tricky "curvy" shape. It's a simple shape (about 50 mins from scratch to 1 LI with subsurf), but also 0.696 LI. No split edges or bevels but it still looks very smooth and sharp. Also note how I didn't remove any significant loops from the original subsurf for the highest LOD, but still reduced the tri count massively (from 1856 to 432). Anything that contributed to a curve stayed. I'd also like to shout-out this gem from 2011, it still holds up:

Assuming it was considered a bug, it's not likely it would be changed anytime soon. Few things are. Whether or not a type of update should be reliable vs unreliable is a matter of technical debate and trade-offs. It may be intentionally left this way. I don't actually know, but my assumption from simple observation is that the things you see while changing (dragging) the color in the edit window are updated client-side, but only after you press OK or Enter, your viewer will send a "hey update this object with this color" packet to the sim and basically ignore/discard your local changes until the sim calls back with "hey this object is now updated with this color." Edit: Or, I guess the updates are just sent live and this happens, using 1000 prims: llSLPPF has the same problem when there are more than one full linkset (500 prims exactly) trying to change color at the same time. (I used a listener in each linkset.) I saw no artifacts when I only had 250 prims changing at once. It's very much a volume/connection thing.

The issue is caused by object updates not reaching your viewer -- a connection quality problem. For me, it only happens with manual edits, never SLPPF. I don't think you should concern yourself with clientside problems as repeating the SLPPF even with slightly different color has no guarantee of working any more than it did the first time. It's not making any fewer changes after all, the problem might just be in other prims this time but the color difference is lesser so you don't notice it. But there's no way for you to predict which prims have the problem and those prims WILL vary from other viewers experiencing the same problem.

To be fair, sometimes the creator doesn't even know the channel and doesn't know how to figure it out, because they're using someone else's scripts.

You should make a new thread about this question in the scripting forum. https://community.secondlife.com/forums/forum/304-lsl-scripting/ It's entirely possible to have scripts working separately in the linkset -- even in the same prim. Nothing dictates that some script needs to "take the lead."

Not quite right. Try selecting a sphere prim. Also, even prim cubes actually have 9 quads per side -- that's 18 triangles, 108 in total. Go ahead and rez a new cube and go into wireframe view. If you make the cube hollow, it'll jump to around 270 triangles. (The numbers as easy to check because you can export any fullperm object, even prims, out of SL and put them into Blender.)

You don't click on the map... Watch the video clip again. You click on the red arrow itself. <-- That one. Just left-click it. You won't even need to open the minimap.

No need, I know what you're talking about as it's the case in every viewer besides Black Dragon. Yes it would be nice, I also often hide selection highlights in Firestorm. That said, my screenshots/clips prove that the other issues are not the viewer's fault but something in your settings. I changed absolutely nothing from the defaults.

All of these were done on the latest Second Life Release 6.3.6.535003 (64bit), fresh install that I downloaded just to make this post.

If the list index is out-of-bounds, it will return whatever the default (zero) value is for that type. ZERO_VECTOR is equal to black color. List indexes start from 0. Your last index is 2. llGetListLength returns 3 because your list has 3 elements. Your random_integer adds 1 to the result. random_integer(0, 3) returns (0 + llFrand(3 - 0 + 1), which means the highest result is (integer)3.99999 or 3. That's not a valid index and you get ZERO_VECTOR.

I've already helped you as much as I'm going to, I'm not that interested in actually accomplishing what you're trying, I'm just interested in the technical theory. That said, you can't just "choose a random number" because you need to pair the other objects somehow. For example, if you have a product and a control HUD, the HUD can't just llFrand(999999999) and use that, because how is the product going to know which number was chosen? At some point, there must be some kind of static or statically-generated channel between the two, and that's what you want to catch. Unless you meant the creator themselves picked some arbitrary channel, in which case I should point out that people aren't random. People are actually terrible at picking random numbers even when they try, and this is very well demonstrated by psychological studies and just layman's observation in things like games. Even if someone was to use a random number generator, many will react to the first result with "well that doesn't look random enough" and keep "randomizing" until they find a number they like, which might end up being predicable in some way like a certain range.

Is there an actual cap on the amount of scripts an object/sim can have? A practical limit maybe, but a hard limit? That's not mentioned on the Limits wiki page. (I've also had no trouble with 650 scripts in a single object... besides disconnecting myself while trying to transfer more inventory to the original.) I did get this error while cleaning up, though. Whatever the reason and whatever the limitations, most products use either fixed channels (very easy to start guessing) or base the channel on the owner's key. In the latter case, it's pretty easy to narrow down the initial starting point. Often, the channel is based on the first or the last part of the key because they're conveniently sized for a 4-byte hex number. Then the most common things to combine with that are 0x80000000 or 0x7FFFFFFF or some other hand-picked but small number. It's only going to take months if you don't try to narrow things down before you begin.

You'll need to be more specific about the kind of "glass material" you're trying to create. If you just want a clean, shiny window, that's pretty simple. You can literally just use the default blank texture as a specular texture. But if you're trying to get some kind of distortion effect like frosted glass, you're out of luck because that's not possible in SL.

Like this? Took me about 90 mins to go from scratch to initial model to 1 LI, plus the time it would take me to properly UV unwrap and texture it. I'm not gonna do that, but I'd share the .blend file. The underside of the rim-front-thingy doesn't have faces even in the highest LOD because you'll never see them from any proper angle. The back of the wheel is a pretty simple cone to a single vert. (Here's the highest and lowest LODs.) This is how big the wheel can be in-world before going to 2 LI, and how far you can view it before it leaves the highest LOD: