Wulfie Reanimator

If a mesh has multiple materials, each material becomes its own face in SL. Your meshes are separate from each other, so they only have one material each, so they both have one face. Sounds like you should join the meshes before export, and make sure to assign different materials to each.

If there's no logic after the if-checks, then there is no measurable difference. Stuff like this could considered a micro-optimization (or non-optimization), since there should be no case where one of these makes the code faster, especially in a high-level language like LSL. (You can find similar discussions in other languages.) The upside is that you can freely pick whichever you prefer. 🙂 I'd probably be more partial to the if-else-if chain because it reduces the chance that I'll forget to add a return at the end of every if. At the same time, I do use the if-return style a lot as a form of early-exit, when I know no more work needs to be done after that point. (But in this context there is always more code after the return.)

This is correct, but you can see a simple frame-by-frame timing breakdown in the statistics window. (You know, the funky rising red dots that are spread all over in most cases. Each dot is a single frame.)

They behave exactly the same way as all other prim properties. 🙂 Assets instances on a sim are saved when they're de-rezzed, regardless of whether that's detaching, sim restart, etc.

All variable types are initialized to sane "zero/empty" values. We don't have to worry about random values or real nulls. P.S. Don't prefix your variables with dollar signs since it doesn't become a part of the name.

Reflections like what you're seeing in the material preview mode depend on your camera angle and environment. The rendered preview mode has a different environment, so it looks different. The baked texture also looks different for the same reasons. You also lose realtime reflections when you bake a texture, since you're basically turning everything to a static image. We gotta wait for the upcoming PBR update for SL.

It's not useless, but for the purpose of profiling a script's performance, it lacks resolution (being limited to server frames), and it's inflated on top of that because it doesn't track running time (time passes even if the scheduler doesn't run the script).

Can you show the weight paints and which bones they're rigged to?

This is normal, and it can happen anytime there are two Alpha Blending textures on top of each other. The solution in this case is to make sure the skin texture on the head is set to Alpha Masking, or even None.

Rig it, and join it to the shoe before exporting. That way it can't be derendered without the shoe as well.

Since it's an animation, it's purely visual. The avatar's position does not change, so they still exist (and are able to physically collide with things) at the ground level. Scripts will detect them normally, they can hear and speak normally, etc.

I don't know the details, but deformations of the skeleton do not go away when the animation stops. This means things like changing the size of bones, or their positions. (And that can only be fixed by playing using an "undeformer", AKA another animation that sets bones back to normal, or using the Reset Skeleton option.)

The eBody is modifiable, so that's a big plus especially in the long term.

They may be thinking of using != to substitute llGetListLength: integer length = [1,1,1] != []; // 3, the length of the non-empty list integer difference = [1,1,1] != [123]; // 2, subtracts length of A from B

The furry community is pretty mod-friendly. You have lots of different creators creating different avatar components, and then there are creators that create a "mod pack" which is a collection of textures for all of the different components from different creators. Most furry avatar components are modifiable, so they often don't come with applier scripts, so we end up with loose textures in mods, so we can apply those ourselves. 🙂 Maybe by distance (doesn't seem like it, I get max resolution textures on objects across the sim), and not by screen space. The smallest object on your screen can have a fully loaded 1024px texture.

I know it's a bit confusing to watch since my cursor wasn't visible, I click on the tail texture in the texture picker list at 0:13. It displays it in the texture slot (but not on the attachment) and complains about no-copy/no-transfer. Then I close the picker list and also try to drag textures from my inventory. That's on Firestorm, and it's been like that for years.

🤷 https://imgur.com/gipxbAc - Most textures are not copy+transfer (for very good reasons) so you end up with this. Dragging a (no transfer) texture onto a modifiable attachment fails to apply it, unless you rez the target object on the ground first. (Dragging the texture onto the slot in the build window also copies the texture into the object's contents for no reason.)

The value will be an empty string in the event, which is also mentioned as a caveat on the wiki page: https://wiki.secondlife.com/wiki/LlLinksetDataWrite

It hasn't been possible to drag textures (or use the texture picker) on worn attachments for a loooong time, even if you have modify permissions.

There are over 76'000 results for "furry" for products rated General, and 1212 results for "kink" (with the products ranging from Dec 2022 to June 2010). The General-rated products with "kink" have it in the tags and description, so we know that word doesn't affect the rating. The only standout word I was able to find was "Sellah" which only has one product (+ demo) rated General, but that one's probably not it since there's only 24 listings across all ratings.

Or more like we'll get one really nice looking object, with the rest of the world textured in glorious 128px downscaled textures because the viewer refuses to keep more in memory.

A common pitfall is reading input from a user, like if you're getting vector data in a listen event, for example while you're processing chat commands. A user might say "color, <1,0,0>" and you might convert this into a list with llCSV2List to get ["color", "<1,0,0>"] If you try to use llList2Vector to access that second list element, you'll get ZERO_VECTOR because the value is actually not a vector, but a string. The list access functions don't do automatic typecasting* (which I think is an oversight). This is why you have to sometimes use llList2String instead, and typecast the value yourself. *Edit: And just to make things more annoying, llList2String is smarter than the rest: llOwnerSay(llList2String([<1,1,1>], 0)); // Output: <1.000000, 1.000000, 1.000000> For that reason, typecasting the value from llList2String is a universal solution which won't break due to type differences.

It's just one LSL command: https://wiki.secondlife.com/wiki/LlRequestAgentData That'll tell you any account's creation date, payment info, and current online status.

It is normal, because certain feature (like sharp edges) generate new geometry (like edge splits).

I had nothing better to do. Money object: default { // Let the rezzer know who touched this object. touch_start(integer total_number) { list data = llGetObjectDetails(llGetKey(), [OBJECT_REZZER_KEY]); key rezzer = llList2Key(data, 0); if (rezzer) { integer channel = (integer)("0x" + (string)rezzer); llRegionSayTo(rezzer, channel, llDetectedKey(0)); llDie(); } } // Set the object's lifetime based on rez parameter from llRezObject. on_rez(integer seconds) { if (seconds) { llSetTimerEvent(seconds); llSetStatus(STATUS_PHYSICS,TRUE); } } timer() { llDie(); } } Money rezzer: integer channel; // Unique channel is generated for this rezzer string money_object = "money"; // Name of rezzed object integer money_amount = 1; // Amount paid per rez integer money_max = 1; // Max lindens to pay out integer money_given; // Running total float rez_radius = 10; // Should be no greater than 10 float timer_min = 5; // seconds to rez float timer_max = 10; // seconds to rez integer rez_lifetime = 10; // Seconds before money object disappears default { // Main setup run_time_permissions(integer permissions) { if ((permissions & PERMISSION_DEBIT) == FALSE) { llOwnerSay("Status: No debit permission, can't give lindens!"); return; } if (money_object == "") { llOwnerSay("Status: No money object defined!"); return; } channel = (integer)("0x" + (string)llGetKey()); llListen(channel, money_object, "", ""); llSetTimerEvent(timer_min + llFrand(timer_max - timer_min)); llSetText("Balance: " + (string)money_max, <0,1,0>, 1.0); llOwnerSay("Status: Ready"); } // Rez a money giver within a random position around this object, then randomize timer. timer() { vector pos = llGetPos(); pos.x += llFrand(rez_radius * 2) - rez_radius; pos.y += llFrand(rez_radius * 2) - rez_radius; llRezObject(money_object, pos, ZERO_VECTOR, ZERO_ROTATION, rez_lifetime); llSetTimerEvent(timer_min + llFrand(timer_max - timer_min)); } // Give money to a key heard from a rezzed object. Shut down when threshold is reached. listen(integer channel, string name, key id, string message) { if (money_given >= money_max) { return; } key avatar_key = (key)message; if (avatar_key == NULL_KEY) { return; } llGiveMoney(avatar_key, money_amount); money_given += money_amount; if (money_given < money_max) { llSetText("Balance: " + (string)(money_max - money_given), <0,1,0>, 1.0); } else { llSetTimerEvent(0); llSetText("Balance: 0", <1,0,0>, 1.0); llInstantMessage(llGetOwner(), "Out of money to give"); } } on_rez(integer start_param) { llResetScript(); } state_entry() { llRequestPermissions(llGetOwner(), PERMISSION_DEBIT); } }