Wulfie Reanimator

Alternative solution, if you're using BOM: https://marketplace.secondlife.com/p/Izzies-Small-Breast/19835916

I *think* camera params affect all sitters... who are sitting on that specific prim. I don't know what happens with sit targets or linksets (but I would assume camera params on root affected the whole linkset). Permission requests are per script. Only one set of permissions can be held for one avatar. Making a new request replaces all previous permissions. Edit: Sorry, I was thinking about the two other functions, llSetCameraAtOffset and llSetCameraEyeOffset, not llSetCameraParams.

Name change is permanent.

Even my browser keeps getting ERR_CONNECTION_RESET when visiting manually: https://world.secondlife.com/resident/779e1d56-5500-4e22-940a-cd7b5adddbe0 That said, I'm able to request the same page repeatedly without errors, with this simple script: default { state_entry() { string url = "https://world.secondlife.com/resident/" + "779e1d56-5500-4e22-940a-cd7b5adddbe0"; llHTTPRequest(url, [], ""); } http_response(key id, integer status, list metadata, string body) { // Basic debug llOwnerSay((string)[ "STATUS: ", status, "\n", "META LENGTH: ", llGetListLength(metadata), "\n", "BODY LENGTH: ", llStringLength(body), "\n" ]); // Quick peek, up to 1024 bytes llOwnerSay(llList2CSV(metadata)); llOwnerSay(body); // Get profile picture UUID. integer index = llSubStringIndex(body, "imageid") + llStringLength("imageid\" content=\""); string image = llGetSubString(body, index, index + 35); llOwnerSay(image); } } But curiously, I sometimes get status 200 (OK) but the meta/body is empty...

Notecards have some inherent limitations. A notecard's maximum size is 65536 bytes. All of the content could be on a single line as there's no line-length limit. But scripts can only read the first 255 bytes of a line. So.. you can write a line that is longer than a script can read, but not know about it. But each line takes over 0.1 seconds to read, and then you must process the line. And to read 257 lines (65536/255) sequentially, it would take you an absolute minimum of 26 seconds, or more if the lines were shorter. To bypass that, you would need multiple scripts reading the same notecard. Everything else aside, notecards are just plain slow. Useful but slow.

It would only be possible if you were the one making the mesh. If that was the case, you could split the mesh into more materials, allowing more max-resolution textures to be used. But if you're making textures for existing bodies, there's nothing you can do.

1024 is the current maximum texture resolution for any kind of texture, avatar bakes and otherwise.

Don't let other people define what is and isn't shameful. UUIDs are random (for all intents and purposes) as you know, so inserting meaning to the random space dust is exceptionally meaningless. When randomness produces an apparent pattern, you should shrug your shoulders, chuckle, and promptly ignore it. Then again, people play lotto with whatever "meaningful" numbers they come up with. And I being a little OCD myself, I understand the obsession.

If money was taken from your account, LL's code was working. The vendor that you paid the money to is scripted by another user just like you. Assuming that the script received the money-event, the rest of the transaction is entirely in the hands of whoever wrote the script. Without knowing the scripter (you can find out by looking at the contents of the vendor), it's entirely possible that there's a bug or even malicious intent. Then there's a third link in the chain -- transferring objects. If you flee from the sim before you've accepted the objects you're owed, they're lost in the void. While I've heard the occasional "I paid but didn't get anything," there's never been any objective follow-up on the cause. People just assume that LL messed up somehow, but never show even potential proof.

You can do custom shapes in the viewer, appearance editor. Make sure you have full permissions to the shape you're editing or you won't be able to share it. You can create a base shape from the little + icon in your inventory window. You can use any image-editor on your computer to make skins. You just need some templates to draw over. https://www.robinwood.com/Catalog/Technical/SL-Tuts/SLPages/AVUVTemplates.html

See, that's what I would've said as well. But since I like to illustrate my Blender advice too, I tried doing it myself but was never able to get data transfer to match the vertex normals. In theory, this should do it. You have the un-split object in the exact same position as the separated pieces and use the Data Transfer modifier (with Smooth Shading + Auto Smooth enabled) to give the Face Corner Data from the un-split object to the separated pieces. (It doesn't matter which type of data-transfer we use in this case, since the meshes are exactly identical.) But if I apply the modifier and look at the normals of the two pieces... (pink: vertex-per-face, blue: vertex) You can clearly see that they diverge, and this seems to be the problem. (But I can't tell for sure.) If I try uploading this to SL, the shading-seam is visible in-world and the importer. (I get the same result if I don't apply the modifier but export the Collada with the "apply modifiers" setting enabled.) I even tried replicating this tutorial, using the example sphere, but the result was not absolutely seamless as if the meshes were never separated: https://blender.stackexchange.com/a/105866

What you're seeing is caused by mismatching normals or "directions." To get rid of the seam, the vertex-normals on the edges of the separated pieces need to match exactly, to appear uniform. Personally I don't know how to do that. I tried before writing this post, but couldn't figure it out. I just know that is the issue.

* For the most part. Maitreya especially will usually grow seams along the inner thigh if the skin isn't made for it, and the classic toe-issue. So if a texture is made for Maitreya, it'll only have a chance of being seamless on Maitreya, and vice versa. But in general, the texture mapping errors seem much more lenient on bodies vs faces. So you should probably focus on matching the head first. It really needs to be checked on a case-by-case basis anyway. But also, if you want to make things complicated, you can get neck-blender tattoo layers to make the tone transition smoother. (Not a neck-fix, those are mesh replacements for the neck to make it align with a specific body.)

You need to create (and include) a separate physics shape. Otherwise SL will just generate a convex one for you. A physics shape is just another model. It should be as absolutely simple as possible. Export it separately from the original model and select it "from file" in the uploader's physics tab. Also, the object's physics type needs to be set to "prim" in order to use the custom physics model.

To be fair, it's not even possible to specify what exactly is wrong with a product while reporting it. The choices that are there aren't enough, and there's no additional text field for more details. That said, requesting more categories can be done through the JIRA.

Try these instead: http://wiki.secondlife.com/wiki/LlSetCameraAtOffset http://wiki.secondlife.com/wiki/LlSetCameraEyeOffset

I don't know if I agree with the first part. Sure, the complexity would be "variable" in the sense that lower settings will experience lower complexities -- as you should expect -- but they're not variable in the sense that if/when you are viewing the highest LOD, you get exactly the same complexity result as everybody else on other settings. After all, an object with higher max complexity might be more efficient than the object next to it, depending on how their LODs are constructed. And I would definitely not defend calculating averages, whatever complexity calculations should be based on objective measures, not averages (or estimates), and should not favor specific hardware. Imagine, for example, some mesh object that is simple overall, but breaks all LOD rules by reusing the same LOD at all levels, or just doesn't optimize well. The complexity for this object would be penalized and hike up. Then, next to it, you have a relatively more complex mesh object that has great LODs (not affected by penalizing), but each LOD is more complex than on the simple object. If we only displayed max complexity, one might get the idea that the more simple object has the same or higher performance impact than the objectively more complex object. If the reported complexity was based on the current LOD instead, the differences would ideally be more distinct/realistic. But I do agree that seeing the max complexity for an object is a useful metric for comparing objects at a glance, especially among people who tend to use higher settings and don't get LOD swapping as quickly. Displaying both (max by default, optionally/additionally current) seems like the best of both worlds.

First of all: Thanks, I'm literally blind. That said, I may be more charitable, but I think if a mesh body is currently being rendered as a single triangle (never happens), only that triangle should be considered for the current render complexity as far as the mesh goes. LL does do this though, right? Just looking at getEstTrisForStreamingCost in llmeshrepository.cpp: // in llMeshCostData::init // mEstTrisByLOD[i] = llmax((F32)mSizeByLOD[i] - (F32)metadata_discount, (F32)minimum_size) / (F32)bytes_per_triangle; F32 LLMeshCostData::getEstTrisForStreamingCost() { LL_DEBUGS("StreamingCost") << "tris_by_lod: " << mEstTrisByLOD[0] << ", " << mEstTrisByLOD[1] << ", " << mEstTrisByLOD[2] << ", " << mEstTrisByLOD[3] << LL_ENDL; F32 charged_tris = mEstTrisByLOD[3]; F32 allowed_tris = mEstTrisByLOD[3]; const F32 ENFORCE_FLOOR = 64.0f; for (S32 i=2; i>=0; i--) { // How many tris can we have in this LOD without affecting land impact? // - normally an LOD should be at most half the size of the previous one. // - once we reach a floor of ENFORCE_FLOOR, don't require LODs to get any smaller. allowed_tris = llclamp(allowed_tris/2.0f,ENFORCE_FLOOR,mEstTrisByLOD[i]); F32 excess_tris = mEstTrisByLOD[i]-allowed_tris; if (excess_tris>0.f) { LL_DEBUGS("StreamingCost") << "excess tris in lod[" << i << "] " << excess_tris << " allowed " << allowed_tris << LL_ENDL; charged_tris += excess_tris; } } return charged_tris; } This is a sacrifice I'm willing to endure. And I don't say that because I'm not the one who's having to do the work. Losing creators is bad for everybody, even people who just buy the stuff and nothing else, because they lose options. But considering how bad the situation is regarding to content and performance, I would risk some creators leaving. If a creator who keeps dumping 100ktri clothing on MP like a factory (using Marvelous Designer or whatever, or buying ready-models from somewhere else) decides to leave because they literally don't know and can't be bothered learning/making LODs... good. They cause significant harm to the whole. And consider that any change (including no change) that could be perceived negatively will cause some people to leave, like raising the MP fees... or introducing mesh in the first place and making SL literally impossible to run for some people as a result (never mind creating a huge learning curve for content creation). Some problems don't have a "right" solution and every choice has its own negative consequences.

The reason I called it "lazy" was because I put no effort into optimizing it at all, or even checking how fast or slow the method was. I'd say it was lucky that my lazy code was faster than at least one of the real encryption methods. The code I showed has basically 4 steps: Remove dashes Cut sections Reorder the sections Build the final UUID But instead, if I was being non-lazy about it, it would just be: Build the final UUID Personally, I would design the product so that I would not have to use notecards for storage. Or in the worst case, at least not "sensitive storage" like UUIDs, even if that meant I could only have a limited number of "sets" or the sets could only save a limited number of information. I might even play around with the idea of using more scripts for additional read/write storage, and only turning them on temporarily when the main script is about to interact with them. I got called out from the future.

Official instructions here: http://wiki.secondlife.com/wiki/Bug_Tracker Yes, the "bug tracker" is used for new feature requests as well.

Here's an incredibly lazy (and simple / clear) way of breaking up a UUID and swapping it in 4 sections of 8 characters. default { state_entry() { key uuid = "779e1d56-5500-4e22-940a-cd7b5adddbe0"; llOwnerSay((string)uuid + " (start)"); list no_dashes = llParseString2List(uuid, ["-"], []); string uuid_simple = llDumpList2String(no_dashes, ""); llOwnerSay(uuid_simple); // "779e1d5655004e22940acd7b5adddbe0", string length: 32 list sections; sections += llGetSubString(uuid_simple, 0, 7); // "779e1d56" sections += llGetSubString(uuid_simple, 8, 15); // "55004e22" sections += llGetSubString(uuid_simple, 16, 23); // "940acd7b" sections += llGetSubString(uuid_simple, 24, 31); // "5adddbe0" string scrambled; scrambled += llList2String(sections, 3); scrambled += llList2String(sections, 2); scrambled += llList2String(sections, 1); scrambled += llList2String(sections, 0); llOwnerSay(scrambled); // "5adddbe0940acd7b55004e22779e1d56", string length: 32 string final_uuid; final_uuid += llGetSubString(scrambled, 0, 7) + "-"; final_uuid += llGetSubString(scrambled, 8, 11) + "-"; final_uuid += llGetSubString(scrambled, 12, 15) + "-"; final_uuid += llGetSubString(scrambled, 16, 19) + "-"; final_uuid += llGetSubString(scrambled, 20, -1); llOwnerSay(final_uuid + " (end)"); } } Obviously, you can use smaller sections, and order them in any way you want. As long as you always use the same order and do it in the exact opposite way when converting strings back. And since the UUID format is very static, you wouldn't actually need to use any lists or list functions. You could pretty much directly build the final UUID from the original, using only llGetSubString. I have no energy right now to code something efficient rather than something that's easy to understand. Here's the actual output too: 779e1d56-5500-4e22-940a-cd7b5adddbe0 (start) 779e1d5655004e22940acd7b5adddbe0 5adddbe0940acd7b55004e22779e1d56 5adddbe0-940a-cd7b-5500-4e22779e1d56 (end) There's no way anybody could determine how the final UUID was generated unless they were able to see the input and the output. Even then, it would take a relatively keen eye to notice that the contents don't actually differ, besides the order.

If I recall correctly, rent signs are allowed but they can't be taller than 8 meters. I'm pretty sure "big eyesore signs hovering above 8 meters" is also against the mainland rules. If I were you, I'd report the signs for abuse (littering? not sure) and let the Lindens handle it.

To be fair, it isn't like SL hasn't been DDOS'd as it is now. On one hand, I imagine taking down AWS is a tad harder than LL's own little setup. On the other, we might be affected indirectly as collateral. (I say might because I don't think AWS could be taken down all at once, probably just regionally.) The move to AWS is no more magical than BOM. It's an improvement, it has benefits, but no tech is flawless.

It's a bit higher than that, but that was the point I was trying to make. Floats aren't based on the digits we use, but the exponent/mantissa representation. Between 0.0 and 0.5, there are 1'056'964'608 valid floats. That's over one Billion. From 0.5 to 1.0, you only have 8'388'608 more, so about 1.065 billion values between 0.0 and 1.0. From 1.0 to 4.0, you only have 16'777'215 more, so about 1.082 billion values between 0.0 and 4.0. You can refer to this and check the numbers yourself: https://www.h-schmidt.net/FloatConverter/IEEE754.html But despite this discrepancy in where the representable values "congregate," llFrand return an even distribution of expected values.

Yup. No matter what, your avatar must have: shape skin eyes hair (It's not a "hair base" like mesh heads have -- it's a shape for your LL-hair. They all pretty much just scrunch up the LL-hair into your skull so it's never seen.) The reason why BOM caused your mesh head to turn red was because you were wearing an alpha layer that totally covered your head. It's an intentional feature to let you know you're wearing alpha layers. The reason why all of your outfits were affected is because you're using the same head (instead of a separate copy of the same head) in every outfit. If you want the red "skin" to go away, either don't wear an alpha layer for your head or use an applier to replace the BOM texture with your old skin texture.