Wulfie Reanimator

For the past couple days my friend and I have been dealing with some noticeable slowness (5-10 seconds to load a page, normally instant) on the Marketplace, anybody else? The forum and other SL pages are completely fine. The grid status page doesn't mention anything, but requests to slm-assets.secondlife.com are almost timing out, causing thumbnails and other parts of the page to occasionally not load.

The "floating attachments" you mention are supposed to be rigged attachments. But because the rigging data hasn't been downloaded yet by the viewer, the rigged meshes will be visible in the state they would normally be. They'll "snap into place" as soon as the rigging data is loaded.

You can. Right-click > Derender > Blacklist

What you're describing sounds like you're trying to have the cape behave like a physical cape would. You can't do that in SL, all meshes are "static" to a certain degree -- even rigged meshes. The individual vertices are influenced by all of the bones you've rigged them to, regardless of distance. If you rig the cape to the arms, it'll follow the arms no matter how extreme of a movement you do. It won't "fall off the arms" like you might want. You could try some trickery by rigging the cape to multiple bones (like arms AND chest/spine, for example) but that will be more complicated and probably won't do what you want. The "best" solution you have for a nice flowing cape that reacts to avatar movement is animesh. You give the cape its own (separate) skeleton, and rig it to that. Then you create animation-pairs for the cape and the avatar, which you would have to play in sync at the same time. This way, you know when the arms are lifted and you can animate the cape to "fall off" exactly how you want. It's a lot more effort and a lot more complicated, but besides that, you just can't really do long drapey clothes that look great, because SL lacks clothing physics.

This doesn't need to be taken into account in the script I posted, because the value is consumed immediately and never stored anywhere. If, instead, you were to create a listen with llListen(0, "", llGetOwner(), ""), you would cause problems because the listener would stay open (meaning, listening to the original owner) even when the object is transferred if the script was not reset.

integer nearby; default { state_entry() { nearby = llListen(0, "", "", ""); } listen(integer channel, string name, key id, string message) { list id_details = llGetObjectDetails(id, [OBJECT_POS]); vector id_position = llList2Vector(id_details, 0); list owner_details = llGetObjectDetails(llGetOwner(), [OBJECT_POS]); vector owner_position = llList2Vector(owner_details, 0); if (llVecDist(id_position, owner_position) > 20) { llOwnerSay(message); } } } Or, just to make things a little less repetitive, we can turn the llGetObjectDetails thing into a reusable function. integer nearby; vector GetKeyPos(key id) { list id_details = llGetObjectDetails(id, (list)OBJECT_POS); return llList2Vector(id_details, 0); } default { state_entry() { nearby = llListen(0, "", "", ""); } listen(integer channel, string name, key id, string message) { vector something = GetKeyPos(id); vector owner = GetKeyPos(llGetOwner()); if (llVecDist(something, owner) > 20) { llOwnerSay(message); } } }

@animats Why not try some of the more expensive options? (The demos, of course.) If you find something that suits your needs, let us know and I'll cover at least the cost of the body itself.

We've recently had some... very persistent spammers here, making new accounts and filling the forum with terrible content. I imagine that's one reason the whole forum got an update, along with the limits to new users.

Literally nobody thinks LL is perfect or that SL is some impervious technical marvel. Countless threads over SL's entire history are a testament to that. But what good does it do for us to always jump directly to "yeah it's just LL's fault?" The problem persists. What are we supposed to do, shout about it? Then what? Wait for LL to hopefully fix it for you sometime within the next 3 years? I genuinely do not understand what your goal is with these threads. Here's a video of me opening and closing the edit window on the official viewer, version 6.4.4. LL's servers have nothing to do with the position of the edit window to begin with, that decision is entirely in the hands of the viewer that is running locally on your computer. The servers are the same for you and me, but our behavior differs. That eliminates LL as the culprit, at least for this particular issue.

The below script will correctly convert a string to a vector: default { state_entry() { string color = "< 1, 1, 1 > "; vector v = (vector)color; llOwnerSay((string)v); } } The things that break it are: Leading space before "<" Leading space before "," @Phate Shepherd's example is very good.

And move closer to the physical datacenter. If you're in a different continent, no ISP is going to save your ping.

First, a very literal answer: It does not make sense to "flag" stuff that "needs to be redrawn" because as soon as anything on your screen (including the position/angle of your camera) changes, everything needs to be redrawn without exception. Otherwise you would quickly find yourself with very interesting visual bugs. Objects being glued to your screen, disappearing entirely, or showing up through other objects like some weird alpha glitch. What you probably meant: "Why not cache things that haven't changed for an extended period?" Cache to where? The sim? Everything is already on the sim, the sim is just one giant cache we can walk in. Cache to the viewer? We have that, it's literally the viewer cache, but it necessarily requires that you slow-rez the thing first. The viewer cache is also not unlimited, you can't cache the entire world of everything you've ever seen because you'll run out of computer space. And if you were to only cache the things that rarely change, you'd slow-rez everything else, every time you see it.

"Native resolution" is the one that matches the physical hardware. While the laptop screen's "native resolution" might be (for example) 1080p, if you connect a 2K screen to it, then 2K is the native resolution. The reason 1080p on a 2K monitor looks bad is because the lower-resolution image is being stretched in a way that doesn't match the available pixels. To illustrate non-matching (not native) resolutions: I couldn't tell you what the cause of this might be off the top of my head (besides some sort of driver issue), but I'm sure it's fixable as long as the graphics card itself supports it. (And I can't imagine any modern GPUs not supporting 2K resolutions... my 1060 goes up to 8K although it's almost certainly not supposed to perform well there.)

Assuming the HP bar is at link_pos, has size link_size, and uses "slice end" to change the size of the bar... // link_pos: =====.===== vector HP_bar_start = link_pos; HP_bar_start.z -= link_size.z/2; // HP_bar_start: .========== vector slice = llGetLinkPrimitiveParams(link_no,[PRIM_SLICE]); vector HP_bar_end = HP_bar_start; HP_bar_end.z += slice.y * link_size.z; // HP_bar_end: ==========. Something like that anyway. The basic idea is: To move to the beginning of the HP bar, you have to shift your position by half of the HP bar's length, because the center of the object is halfway through the HP bar. Then you can get the slice value, and use it to move from the beginning of the HP bar. Since the "slice end" value is always between 0 and 1, you have to take the HP bar's actual length into account, if it's longer or shorter than one meter. Edit: Incidentally I've made some HP bars for games before (and just for fun) and personally I prefer using PRIM_SIZE instead, because PRIM_SLICE is an instant change while scale/position is interpolated client-side. I think this is similar to what you're trying to do, where the end of the bar has something going on (in this case, it's just an end-cap for a rounded look). But here's an example of a really simple but nice effects you can do with PRIM_SIZE. You can even mix the two, like one of my HUDs does. (HP drops with slice, the damage indicator follows with size.)

I would object to renaming Mono to LSM because "LSO" seems to be the actual name of the specific implementation non-Mono scripts use. If it stands for something, it's never mentioned anywhere across the Wiki that I can find. (And since openmetaverse's domain has expired and is now being used for an adult website, going there is a deadend.) LSM(ono) seems pretty arbitrary since Mono is the name of the other implementation. It's pretty weird how the viewer menu has stayed mislabeled for so long, though. I wonder if @Whirly Fizzle has any insight?

You know, you have a point... Everybody pack your stuff, we're starting a petition to remove mesh. Think of how criminally the "shared experience" was broken when LL rolled out that feature before TPVs!

There is only one official UV map, and it's as unisex as the base avatar. To make a male skin, you would use the same UV template as the female skins. The problem with going with that route is that deformation is hard. You can't exactly model a male chest and then morph a smooth bust out of it. You're (almost) forced to make the model with the female topology, and squish things down from there.

These two are at least somewhat tangible right now. A mobile client is in the works (text-only to start with), and LL got 3(?) graphics gurus back from the Sansar team when it was sold.

I get easily a couple dozen demos before buying anything. More than that for hair. But if I notice a timed demo, I ignore that store.

You answered your own question there. There's no magic involved.

Like I showed you in a screenshot in another thread, here: "Preprocessor include path" For example, a file full of utility functions: "D:\xyz\utilities" You would #include "utilities" as normal, and the preprocessor would look at your local drive for a file with that name. You do need to be in-world to compile and test your scripts, but only the script you're going to run/test needs to be in-world. "wuff.lsl" is an old text file I used to use as my include. I don't really like #includes though, it makes it impossible for another person to recompile the script (with the preprocessor) because they don't have your includes. But it doesn't work as a form of protection either, because the post-processed script (which has all of the included stuff) is always available. It's just messy and inconvenient, especially if someone makes edits to the post-processed script and then someone else tries recompiling the script with the preprocessor. All of the edits made by that person without a preprocessor will be lost. I prefer to just use my own snippets to insert code as I type it, like "os" expands to "llOwnerSay((string)[ ]);" and "osl" expands to "llOwnerSay(llList2CSV([ ]));" for debugging purposes. I would similarly create snippets to insert entire functions to my code, if needed.

Talking about mesh problems on this forum is basically preaching to the choir. All of us regulars are almost always in agreement about how to improve something, with the occasional newbie coming in to ask questions. None of the popular brands are coming here looking for advice, and lord help you if you try going to them. I can kind of see how you would come up to that conclusion, but I strongly disagree that showing bad examples (in conjunction with explaining that it's a bad example) makes people do bad things. In fact, "here's an example, do you see what's wrong with it?" and evaluating work that has been done poorly is a common teaching method.

The correct terms are LSO and Mono. LSL is the scripting language itself. LSO scripts are smaller, using (much) less memory for its data, but scripts are always reserved a full 16KB memory regardless of actual need. Mono scripts are much faster than LSO, uses more memory for its data, but only uses as much memory as it actually needs, up to a maximum of 64KB. You can switch between the two with this little checkbox, which is checked by default.

1. I also use an external editor, I can't stand the in-viewer one. I can also tell from experience that what you're doing is awfully fiddly. 2. I know, which is why I never even though about including another Script directly. Only using local files means that you don't have to keep another Script in the same folder and clean it up after compiling. And if you ever want to recompile the main script, you'd have to find the utility script, put it into the same folder, recompile, and clean it up again. Awfully fiddly. (P.S. I capitalize "Script" to differentiate between an in-world inventory item, and scripts that live on local drive.)

Wouldn't pointing out bad practices before they popularize be better? Telling people to start optimizing their mesh after the market is filled with literally everyone's unoptimized mesh is much harder than talking about it preemptively.