Kyrah Abattoir

You do know it's a different system right? Just because there is an import function doesn't imply identical results.

@MollymewsThat's a good approach yes. I understand the necessity in this case, due to the potentially complex math involved to allign the pieces. It is slightly concerning how few of SL residents are actually able to use the built-in tools to their full potential.

Just because MD can produce quads doesn't make it produce good topology unfortunately.

The only problem i see is from a grid health standpoint, users almost never hit the "delete script" button, because this brings permanence and commitment to choices.

Leave at least 8-16 pixels of padding for your UV islands.

@ChinReyif you use the fast config trick I posted earlier you can probably get away with a master script with a few "flags" to change its behavior. But i'm more questioning the benefit of having scripts at all in a modular road system.

Allright, this is old as hell, but fairly underused. Rather than using a configuration notecard, which is slow and requires asynchronous parsing, there is a trick you can use: Rather than using notecard lines, you use the inventory directly. Instead of looking for notecard lines, you read the names of the inventory items and use that as your lines. You can quickly iterate through llGetInventoryName(INVENTORY_NOTECARD, i) and fetch the name of every notecard in inventory. Then it's just a matter of coming up with a configuration format, such as "key=value" (example: "operation_mode=owner"). As an added bonus, you can use the card description and content as a help file for this specific configuration entry. But it doesn't stop there! For configuration options that are essentially "flags" (on/off or other values the system expects), you don't even necessarily have to "load" the configuration, since reading it is pretty much instant: if( llGetInventoryType("operation_mode=owner") == INVENTORY_NOTECARD) will give you instantly whether the flag is set or not. The object inventory itself can potentially be seen as a quick access "rom", so long as you know in advance what you are looking for, or that you are willing to iterate through every entry of a given inventory object type. It is obviously not limited to notecards, in some items i use texture names for each entry.

My rant is about people who cram scripts in every prims, just because you need a couple scripts to target specific prims doesn't mean you are in that category... I'm staring at an 8 prim pose blanket here with 56 scripts.

Sensors internally "most likely" do a region wide check. for llGetAgentList() restricted to a parcel it depends what is the most likely scenario between having people outside or inside the parcel.

Indeed and it is potentially easier on the region, I have no idea.

Alternatively llGetAgentList can be configured to detect avatars only on the current parcel, however, unlike sensors it doesn't have a range limit.

I'd rather buy something unscripted than something cobbled together by someone who can't script. I mean how do you even provide tech support then?

Did someone make the opposite? A naughty message that shows only when people have ALM off

A lot of creators put a fake shadow under furnitures. Note that it has nothing to do with the actual "shadow" graphical setting, Those shadow planes are just a static texture.

Makes sense, I've done uniforms in the past but not for multiple bodies, so I totally understand the problem.

Do keep in mind that models generated by MBLab are under AGPL/CC-A-4.0.

Warning, this will be an opinionated answer: If you model cleanly and efficiently, you typically won't because a model made on one body is typically designed to fit that body and follow the edge loops, density and flow of that specific body and no other. Now sometimes if you're lucky (or if you use 10 times the polygon count and thus deserve to be burned at the stake), you can actually massage the mesh into the shape of another body (if modeled efficiently you will be limited to bodies that are fairly "close" to your original target of choice). I can think of a few tricks, but one that I do know works is that you can use deformation cages (Blender & 3DsMax i know have them) and "massage" the mesh into the new proportions. One advantage of this approach is that you MIGHT be able to re-use the same deformation cages across multiple projects for the same body. (but sometimes not) As for the weightpainting aspect, i can't think of any good trick, body creators each have their own idea of what is "good weighting". Some will try to make it really simple, some will have some really complex shoulder/neck influence in an attempt to be "realistic", some bodies will try to preserve areas that are commonly used in conjunction with unrigged attachments (nipples, ears, neck, wrists, ...), and there is obviously the last group who doesn't know what they are doing but as long as it bends, even if it looks like a wet cardboard tube, they call it success. Weight copy obviously gets you about halfway there, but you're still gonna have to do a lot of manual painting. Mirror painting is your friend. (I'm not an autority on rigging so feel free to chip in anyone) My advice? stick to 1 or maybe 2 bodies that you like, actually use and want to promote and grow in market share. By trying to please everyone you will over-burden yourself (just imagine if you discover a problem that need fixing, 1 month after releease), end up pleasing no one, and you will be lost in the sea of other creators. A few important things when comparing yourself to other creators: Many creators are teams of people, even if they sell all under the same brand/avatar. Some contract other creators to do work for them or participate in joint projects. There are a few brands that even contract out all the creation process to other people and are effectively just "managers". Some are hobbyists and others do it full-time.

Do we?

People tend to forget that software is written by real people, with real stomachs that eat real food.

The visible and collide-able part of a model are completely separate. For performance reasons the collision mesh has to be as optimized as possible, because collision detection is a very expensive operation. Auto-generated collisions meshs are nearly always unuseable, expecially for hollow structures.

Assumed goal. Last time i demonstrated this at a linden meeting and implied that a lot of people wear them now, they shuddered.

Yeah i figured this was why, shame, but I will survive

This is probably not the answer you are looking for, but not all mesh bodies take an eternity to load.

You can also add to that pile: Custom permission revocation conditions (scripters hate this one so much) Blocking llMapDestination (first time i see this option, it does explain why some of my customers never see map prompts from my scripts, sigh) Look at target hiding/ (does manipulate some data sent to the server in an unintented manner) I mean, don't get me wrong, it's great that we have such a passionate community modding viewers in interesting ways.

The lockdown appears to have been very beneficial for the environment. I'm just hoping most people will see some benefits in a more frugal life. Sometimes, less is more.