Wulfie Reanimator

Nobody in SL can override LL's TOS. These disclaimers are an old fad, they used to be very common in picks, less common nowadays. My profile still has a pick about this as a middle finger to those people. 😂

Ctrl-F brings up search&replace, but personally I use an external editor so I can have my own shortcuts, tools/plugins, code snippets, and code auto-complete in general.

They're talking about store categories, specifically one called "mods," as a lot of furry products are called. (These are usually sets of textures or new components to be used with other, already existing products.) I don't think this is necessary though. The term is too specific (used by a relatively small portion of people) and too broad (it's easier to list things that aren't mods than explain what they are) at the same time. There's just a lot of overlap with other categories, there isn't really any kind of "mod" that doesn't already have it's own category, due to the nature of mods.

Procedural generation is not a bad thing, and you would want the variables to be limited, otherwise you'd call it "random." (What does a nose look like anyway? Sharp spike or something resembling a saw blade? No, there are limits. When something deviates from our limits of "nose," we call it malformed.) No Man's Sky (and Spore, as mentioned in the article) weren't panned because of procedural generation. They were panned for exaggerating and over-promising. That said, I don't think random face mesh generation is viable at all. Too many things can go wrong and I doubt most people would use it. We already have face rigging and shapes, it'd be far easier to make shape randomization instead, and use a well rigged head with good topology to handle the extremes, possibly with different, detachable components for different kinds of noses, ears, eyes, lips, jaw, etc.

The rotating (target omega) link is not going to "break" in any way when the root of the object rotates. The wiki page says that the link will rotate around itself, as you should expect from wheels. There is a different issue though, which is that the rotating object will rotate physically if the root is physical. This means that the rotating wheels will affect the movement of the vehicle unless you set each wheel to have no physics shape (Features tab). You should also use llSetLinkPrimitiveParamsFast instead, like Mikka Luik showed, so you don't need a script in each wheel.

@Oz Linden Save us from this nothing we've become.

It's.. not, though. Let's recap: What you said is a universal truth about all objects in-world. The server (sim) handles all objects this way -- polling for updates and sending those out to all clients (viewers). Whether or not the object is prim, flexi, sculpt, mesh, animated mesh.. same thing. The number of triangles does not increase the amount of work the sim has to do to maintain it. There are different kinds of "changing position," though. Instant changes like llSetPos, or smooth, physics-based like llSetKeyFramedMotion. These also cause the same amount of work for the sim, regardless of the type of object being moved. Definitely, but I don't know what LL's reasoning is exactly. Things like keeping a list of active animations does have a little overhead, but not 15 LI's worth. The simplest explanation might just be that they chose to lump it together with Pathfinding Characters. (Especially if we consider the fact that Pathfinding + Animesh doesn't result in 30 LI like Animats pointed out.) This doesn't bother me though, because 10'000 triangles should be quite enough for a full-body NPC. You can try this yourself by rezzing a prim cube, going into the Features tab, and checking the "Animated Mesh" box. Then you can put this script into it to turn it into a character for pathfinding: default { state_entry() { llCreateCharacter([]); } }

In fact you will have to use some kind of a bot service. Scripts alone cannot send explicit group invites. At best, scripts can send a link in chat for people to click on.

In that case I don't know why you would bring that up as an explanation at all, because the same applies to all objects -- even regular prim cubes -- with animesh bringing no additional overhead over any other type of object..

No. Animesh animations are handled the same as avatars. The server only communicates the state of the object (eg. "playing X animation"), and the viewer handles actual animation playback/rendering. A very easy way to check this is to press Ctrl-S (sync animations) on Firestorm. Animesh objects will be synced as well.

From the Animesh User Guide:

Essentially:

Ever seen The Matrix?

I'm really failing to understand why @arabellajones makes it sound like this feature is somehow a "hack" or "very confusing" and "shouldn't be there." The first three numbers are RGB, ranging from 0 to 255. This can be easily confirmed by checking a fullbright prim with a blank-white texture. White is 255 255 255, black is 0 0 0. While doing this, you'll notice that "alpha" for white is also 255 and black is 0. 50% grey (128 128 128) has an alpha of 132, which definitely seems odd at face-value, but the alpha value can be completely disregarded because you really only care about the RGB values. (And yes, GL_UNSIGNED_BYTE switches the range from [0,1] to [0,255], as explained here) You as the user can't figure out why the alpha value is what it is. The simplest and broadest explanation is that it doesn't measure the transparency of what's on your screen, but what's in the corresponding "memory" (that you don't see). The reason for whatever the value actually is is hidden deep in the rendering code, which most won't dare to venture into. The solution for this "undocumented hack" would be to just not show that fourth value. Functionally identical, just no longer bothering some people. As for llformat (source), that's just a common string-formatting function, it allows you to replace patterns with values, %d means decimal (aka integer). LL's version just has some platform-specific lines, it doesn't alter the input/output.

As someone who has a Vive HMD, what I wanna know is how the screens actually look on the glasses. The screen seems to be on one eye and you can see past it, so how do you comfortably focus on it? More so what's the resolution like, is the tiny text actually legible, and to what degree?

In my country it's called literally "Friend's Day" so the whole world is my valentine for one day and you can't stop me!!!

There are ways for teachers to remotely monitor what every student is doing on their computers, and close programs/windows or lock the computer if they're too distracted. Besides, if we're going to go with "what would probably actually happen," almost none of us should be saying "I'd do X" because most of us have zero experience in being the teacher. The premise supposes that we'd be in charge and capable of doing it, why wouldn't it also suppose that the kids would sorta pay attention? (I also think some people here massively underestimate the newer generations' ability to learn computer-related things like programming or navigating SL.)

I don't think that's what I'm talking about. Doesn't sound like it. I don't mean exporting any assets, I'm talking about the local copy of your inventory that your viewer downloads from LL's database every time you connect, which doesn't contain any actual data but placeholders/pointers to them. You couldn't copy or edit these (not because of permissions but because the new copy/edit wouldn't have a new UUID), only move or delete them and you'd need to send updates back to LL about what you're changing so the real database/inventory is affected, just like normal viewers have to do. It would basically be a text-only viewer, minus chat, with extra tools specifically for inventory sorting. Or maybe (ideally) it wouldn't even require a login until you were done and wanted to send the updates in bulk.

Did you know that your inventory is downloaded onto your computer every time you log in? You could parse and edit this file directly outside the viewer, but nobody has created any tools to do this in a user-friendly way as far as I know.

I prefer typecasts.

If you mean the actual speed of movement, that's not related to animations. The avatar will always try to reach its maximum speed, unless you do something to slow it down. That's actually something scripts can do. They can use force to push against your avatar, causing it to move slower. I can't show how right now though.

"Disguised" as in changing the way the word is written so that word filters don't notice it. Kinda like how you would type swear words like f**k, or ag3pl4y. "Loli" just refers to a little girl, but rarely in a PG way.

Game development involves a very wide range of talents and has a lot of visual feedback which is perfect for "quick rewards." With that in mind, I would introduce the class to SL and let them pick what's most interesting to them, be it making assets (prims, textures, sounds, whatever) or scripting, group the students so that every group has artists and programmers, and have each group come up with some kind of simple game or other project idea that they can work together on. Second Life is a great platform for this because LSL is simple, everything "just works" unlike trying to make something in an editor + IDE (like Unity + Visual Studio). The students don't have to figure out how to implement something as boiler-plate as moving or being able to click on things.

The paranoia most often comes up in the form of "you're too short, you must be a child and I should report you before anybody else gets reported:" The furry/anime community is much more accustomed to small and/or cute avatars, between 4-5 feet, even in a lewd context. Probably because it's further removed from real life and can be more easily justified (like small real life species for furries or not really resembling our idea of a real child). Friends, we're talking about the overall trends and averages, of course there are exceptions and outliers but they don't disprove anything. 😋 (Never mind that there's a thousand ways to slice the pie and we're all talking about our own limited experiences, until someone links actual statistics which nobody's probably bothered to gather.)

Try adding a space between "17" and "LI".. Somebody posted a similar topic recently, and it seemed like LL's filters were picking it up as a disguised "loli."