Wulfie Reanimator

llSetPos(llGetPos() + <0, 0, height>);

You would create a set of materials for your model in Blender (or export the model into another program like Substance Painter) and bake those materials into a static texture. The baking process requires your model to have its UV map already set up, so you're good on that front.

I think you're missing the forest for the trees. The purpose is to automatically update the hovertext based on the name of the object. That's it. There is no changed event, or other convenient way to do that without the user interacting with the object, so we need to check the name regularly. There are two (apparently three) ways to do that. A timer, a loop, or resetting the script. If we used a timer, that wouldn't be functionally any different from an infinite loop, since the script does literally nothing else. It's just extra typing, more events, and more complexity. If we reset the script as soon as it starts, it's going to use more script-time than anything else, and it's basically an unthrottled/uncontrolled infinite loop. We could use a sleep here, but resetting the script for one function call is still overkill. If we used a traditional while(true) loop, we can control each iteration, improve performance, reduce complexity, and cause no unnecessary events. It's three lines of code, there's no obfuscation, it's exactly fit-for-purpose and needs no exit-condition. Can you come up with a condition for the loop? You're welcome to suggest one, but so far I haven't seen you do that.

You don't need a mesh dev kit to create skins. All you need is the correct template (doesn't need to be a PSD, or use Photoshop), so you know where to put the details. LeLutka heads have two different templates if I recall correctly, one for classic skins (Linden Lab system avatar template), or EvoX (their own proprietary template). You can use the mesh head you already have to test what your skin will look like.

As long as the value is greater than zero! Otherwise llSleep doesn't do anything. default { state_entry() { llOwnerSay("loop"); integer i = 5; while (i--) { // Prints the same time multiple times without sleep. llOwnerSay((string)llGetTime()); llSleep(0.0); } } }

llGetLinkName returns "00000000-0000-0000-0000-000000000000" if the link number doesn't exist, so you must've mistakenly put it in a linkset. It's mentioned by the wiki page: "If link is out of bounds, NULL_KEY is returned." Also like VenKellie said, those two lines in your script cause an infinite loop in a pretty fierce way. I hope it's just a build-helper and you don't share objects with scripts like that in them. A more gentle way to do the same thing would be something like: default { state_entry() { while (TRUE) { llSetText(llGetObjectName(), <1.0,1.0,0.0>, 1); llSleep(2); } } } ...with as long of a sleep as you can deal with.

We don't have any kind of testing framework to work with, so test-driven development for LSL is impossible (or super impractical). We can't trigger events (especially touch) or observe most behavior externally. The only way you could test anything is to have the tests in the same script as the implementation, which eats at your bytecode and active memory a lot. Instead of having a listen event with LSL code in it, you would only have a bunch of user-function calls in the listen event. And for each user-function, you would also write multiple user-functions to test every aspect of that function. This is a very limited way of testing things and not worth the effort IMO.

You can call llDialog again in the listen event, after you're done processing the first menu. 🙂 The second menu will then be handled in a separately-triggered event. Here's a complete example of Frionil's suggestion: default { state_entry() { // Listen on multiple channels: llListen(1, "", "", ""); llListen(2, "", "", ""); // Open first menu: llDialog(llGetOwner(), "Menu 1", ["one", "two"], 1); } listen(integer channel, string name, key id, string message) { if (channel == 1) // First menu { llOwnerSay("your first answer is " + message); // Open next menu right after: llDialog(llGetOwner(), "Menu 2", ["three", "four"], 2); } else if (channel == 2) // Second menu { llOwnerSay("your second answer is " + message); } } }

The downside to notifying people that you've blocked them is that it can incite them to further action. "Oh, you think you can block me? I can just make a new account, you'll see!" If they get no reaction, people are a lot less likely to seek more ways of forcing your attention.

I've been down this road with C at school because of overly-restrictive mandatory style-guides. The answer is... Don't. 😞

It looks like if an object only has one face, it will be shown as ALL_SIDES (which will also happen if you select all faces on a mesh with multiple faces). So, since both meshes have face 0, they probably have multiple faces each. The solution is still the same though, if you want the two faces you've shown to be different numbers, you'll probably want to join them in Blender/Maya/whatever before you export/upload the model to SL.

From the wiki: "If unsuccessful (usually because of specifying an out of bounds array index) it returns JSON_INVALID."

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.