Wulfie Reanimator

By the time I replied, the issue was already resolved so all I had was a funny meme. Besides that, two people (you included) have proposed explanations about what caused it, despite the lack of detail in OP's post. I don't think actually elaborating on the good practices does any harm at this point.

It's pretty frequent for attachments to take their sweet time to attach/detach, and then you still have to wait for the actual textures to load on top of that. I wouldn't really call that instant. That said I strongly prefer 3D attachments.

That list comes from your browser, not the website. If you're using Chrome, you can press Shift-Delete when you're hovering over an item of the list to delete that item.

Alpha-sorting is a common problem in real-time rendering. Don't use alpha-blending textures aside from where you need them.

LSL has no way to set the texture at the moment.

The problem isn't BOM vs non-BOM. Both are just a texture. (Unless the skin creator actually changed the texture rather than just putting it into a system layer.) The problem is the new head, for sure. The mesh is what decides HOW a texture is placed on it. A different head will almost absolutely have a different "texture map," which means that the same texture won't look the same. If the head is the same but the "BOM update" looks different, the texture was changed and the only solution is to stick with the old texture.

As long as your outfit is inside of the RLV folder in your inventory, you can use the RLV commands: attach, attachover, attachall, attachallover, and attachalloverreplace. http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI#Clothing_and_Attachments

First things first: No, you can't determine how the script was attached from within the event handler. Besides that, I don't think RLV has any way to change how an attachment gets attached in the sense you're trying to do. RLV is just a bridge between LSL and the viewer, and I'm not aware of the viewer having any ability to tell the sim to "attach this without invoking any events." The same applies to any other event as well; none of them can be suppressed, only left unimplemented. The bigger question is "what are you trying to do?" If you're the script developer, I'm sure you can design your script in such a way that the attach event won't cause problems.

I think it's pretty fair to call it a "mobile viewer," even if it doesn't show graphics. It's just a consistent, well-understood term to the users of Second Life. Though, you might as well just call it the "mobile client" as you did, and you'd be totally correct.

Not true. Well, kind of true. It's the only exception to normal chat behavior I know of. The dialog button is spoken by the touching avatar, but the origin of the message is at the location of the script that called llDialog. The distinction is that you can operate a dialog from an infinite distance, and any object that is within 20 meters of the dialog (not the avatar) will get the message.

What is it about Firestorm specifically?

The basic components of a "tree planter" like that would be very simple. Moving the planter can be done with llSetPos or llSetRegionPos. Getting the right elevation can be done with llCastRay downwards. Planting a tree can be done with llRezObject. As for a good/natural looking tree pattern? That's a whole other problem.

Characters can be counted with llStringLength. "while (peeps < 13)" would most likely cause a very long loop. Instead, you should set peeps to 12 if peeps is greater than 12. That way the loop doesn't need to be edited and you'll never include more than the 12 closest people.

llResetScript will cause the script to reset itself. llResetOtherScript will reset a script in the current prim with a specific name. It can. How are you sending messages to it?

I think there comes a point where 'little tricks' can become a problem on their own. While getting rid of a conditional check can make the code simpler, care should be taken so that we don't replace it with something too fancy. For example, like you said, Quintessa, you could calculate different non-zero values based on an on/off toggle but it would get a bit overly-complicated and hurt readability more than the conditional. Likewise making function-calls can become slower and more memory-intensive than what we started with. Now, that's not to say that these things matter that much in a small script, or that the List2Vector is somehow unreadable or overly complex. I say this as a word of caution in the context of a much larger script where most/all conditionals were hidden as extra calculations, or if you're sharing your code with other people (to whom these things might be unexpected and confuse new readers).

Not only that, but in simple cases like this, you don't even need any if-else cases. integer bulb_lit; default { touch_start(integer total_number) { bulb_lit = !bulb_lit; // Set 1 (true) or 0 (false) llSetPrimitiveParams([PRIM_POINT_LIGHT, bulb_lit, <1,1,1>, 1, 10, 2]); llSetPrimitiveParams([PRIM_GLOW, 0, 0.15 * bulb_lit]); } } The variable 'bulb_lit' directly correlates with the values we want to give as parameters. So if we do that, we don't need to duplicate code and there is less room for errors. OP's case is different though, as both cases have the light/glow on, just a different intensity and color.

This is similar to how land impact is calculated for Animesh objects.

Not being able to move (when you aren't blocked by objects) is usually a sign of being disconnected. SL will often try to regain the connection for about 30-60 seconds before it finally tells you "I give up, we're disconnected."

For better or worse, people can derender your mesh clothes. Wearing system-layer underwear has more utility than you think.

I did not mention this but yes, the download cost of my original model (with auto-generated LODs) was almost 90. I would definitely not accept the model as it was.

When you're making physics shapes for complex objects like this one, it's best you don't try to make the physics shape from that model. The point of a physics shape is to approximate the collisions of an object as simply as possible. What I would do (and recommend) is to create a new, separate model from scratch and use as little detail as you can. Here, I made a quick recreation of your model, with multiple floors: And here's the physics version: Many things about the building can be considered unnecessary if there's little to no chance of an avatar trying to walk on it. Note how the hollow cylinder goes all the way from bottom to top, without the extra ridge near the bottom. The floors are flat cubes (or thick planes?), not rounded. The big pyramid-shape serves two purposes: it's a ceiling for the inside, and it approximates the main roof with the four pillars. There are no windows in the physics model, as you're not meant to walk through them. (Doors are a different hurdle, but not very complicated either.) The two big cubes on the sides are not connected to the main building. With the object scale at about 33x51x64, the physics cost of the building is 2.920, not even 3 LI. Edit: I just realized you linked your Blend file. Oops. I made a physics shape for the first floor based on your model. It consists of 7 separate hulls (joined as a single object before exporting), with a physics cost of 1.720. This includes the stairs for upper-floor access. Here's your blendfile: http://puu.sh/HpNiz/e6c33006cd.blend

A "server" in SL can be and do many things, just like servers outside of SL. If your game needs any kind of shared (or "global") information between sims, you're going to be stuck needing an external server/database because an entirely in-world solution is guaranteed to break every time the grid goes down.

Low LOD seems to have too many triangles. @Drongle McMahon came up with many graphs about how the size of the object affect the "importance" of different LODs:

I prefer the bit-shift method, or just pre-calculating the value if there's a specific multi-bit condition I want to check.