Wulfie Reanimator

I recall there being a little online page that would evaluate LSL expressions but not entire scripts, a couple years ago. Does anybody remember the same thing or can locate it or who hosted it?

The conversion won't work in emails because the email service can't resolve the URI. Also, I think the hex will only consider up to 8 characters since that will cover all 32 bits. I'm not sure what happens with "0x123-" but I would assume 0, because that's what happens with C's atoi function. That's not really a valid comparison though. You're right, the conversion stops at the first non-hex digit. string hex = "0x" + "1-2-3-"; integer i = (integer)hex; llOwnerSay((string)i); Depending how many dashes you remove from the string, the result will be 0x1, 0x12, or 0x123. 0x12345678 is a valid integer (as it should be), but 0x123456789 is -1.

100L? What a rip-off, lol. It's practically one line of code. I'll make a fullperm copy and put it on my own MP.

Guys... Don't make it complicated. Store the avatar keys into a list as people come and go. Any time you send a message that is supposed to include the avatar's name, just use the URI. "secondlife:///app/agent/" + (string)avatar_key + "/about" (uses the viewer's setting for names) "secondlife:///app/agent/" + (string)avatar_key + "/username" "secondlife:///app/agent/" + (string)avatar_key + "/displayname" "secondlife:///app/agent/" + (string)avatar_key + "/completename" The conversion is done by the viewer and doesn't depend on the sim knowing what the key is. Similarly, if you're creating an integer from a key, you don't need llSubString. (integer)("0x" + avatar_key) will produce the same result as with llSubString(avatar_key, 0, 7).

Yes, I have seen the screenshots and I completely understand the problem you're describing. What I'm saying that using someone else's animations isn't going to help because the mesh those animations are made for is rigged in a specific way.. not with unrigged stuff in mind. Making your own animations is the right solution to get rid of the weird offset. That way you can move the pivot point up to the spine so that the tail moves like this: Since you haven't specified; if you're talking about making a rigged tail base, that would work too but it'd be less universal if you wanted to use the same avatar across many different avatars, as you'd need to re-rig the base for each one (and it wouldn't work for new bodies or ones you aren't aware of). Instead you could just make a small set of the tail animations with different offsets from the spine to account for different shapes.

Couple things: You can adjust speed and such of the wag with scripts too, but people are lazy and don't tend to make them adjustable. But yeah, scripted wag (changing rotation) is both jerky and subject to script lag. You won't need mesh to fix any issues though. Animations are what control how and where the bone moves, meaning all you need is a bento animation to adjust the exact position of the tail "base," even if the tail is purely made out of prims.

And then there's LL.

Weird how confused a lot of people seem by the description. I felt like it was simple enough, unless I too just think I got it. You want to use bento animations to move the tail attachment point. On that point, you want a flexi prim because it can react physically to gravity and motion. Only problem is the offset of the attachment point, which is controlled by the bento animations of different tails, making them not always compatible with non-rigged objects. Totally doable. Not many have done it. More people should do it. Yeah?

Debit permissions have their own unique dialog with no way to recreate it without changes to the viewer itself. In fact any permissions have their own dialog that cannot be recreated.

You don't have to be a newbie to make mistakes. However I'm a scripter and I can say with confidence that there is no way for a script to charge you more than you paid or charge you without debit permissions, or gain those automatically.

To be able to charge you, the sploder would need to request permission to debit you via a big scary notification with warnings written all over it, and you must have manually accepted it. Why did you? I assume you don't own it, but if you do, the sploder probably takes a flat fee (30L) for every round.

It doesn't seem like you exported the bounding box correctly. It's not showing up in the importer preview and your physics weight is still over 19. In Blender, while you're exporting the .dae, there's a little gear icon on the top-right corner. Click on that and pick the "SL static" preset. That will change a couple things, mainly the global orientation, apply modifiers, and enables "selection only" for exporting. I have a feeling you've exported multiple meshes at the same time and using them for physics. Is the earring a single mesh? If it's multiple parts, you won't get under 30 L$ for the upload cost and including proper physics gets slightly more complicated. I don't have any clue why the texture looks like that in the importer. Have you tried uploading the mesh on the preview grid, Aditi? You start with about 50'000 L$ there and a Linden will give you more if you run out. Your inventory will mirror the one you have on the main grid.

What's in that 2600 line doc? I'm really curious.

That's totally fair and I don't disagree with the want. But I would point out that Ctrl-W is also fairly standard. It works universally in Windows and Ubuntu (unless the app overrides it), I think Mac too, and for example browser (Firefox, Chrome, Opera, Edge, Internet Explorer, Safari, etc) tabs.

I insist!

The knowledge base says: I'm guessing from your screenshot that your physics model is very complex. What is the "physics weight" of the model? What about the "download weight?" You should definitely make an explicit physics shape for the earring to lower the cost. I made this mockup (3400 triangles): Even after using the hardest simplify settings, the physics cost is still 23.5 (that's a LOT)! Depending how I "simplified" the physics shape, the upload cost went as high as 51 L$, so it's never a guaranteed method. You should always make your own, especially when physics don't matter. So instead I just created a new cube in Blender and sized it roughly the same size as the model itself. Then I exported the cube (no seams or UV maps or anything) and used it as the physics shape. Whoa, 0.3 physics weight!

Why exactly do you want to start a new account? Because you have "too much stuff?" Seems absurd to me. And I'm not saying that creating new accounts is absurd -- I have many. I have a couple I use for entirely separate circles of friends each, but I also catch names I like. For example, "llScriptProfiler" (a real LSL function) and "Bonkable" (you can figure it out) are both avatars I own because the names are clever or amusing.

This is important to point out. Just the hole in the main triangle has 32 inner edges (2 triangles between each) and 64 verts, all of which will have to connect to one corner of the main piece thus creating more triangles. The problem is that the hole will be only a couple pixels big on the screen at most (99% of the time) but each triangle must be re-calculated every frame. If the hole was 16 or even 8 edges, there wouldn't be a noticeable difference 99% of the time. I would also think that a more angular hole would fit stylistically with the piece. Don't get me wrong; it looks good. It's just expensive to render. Also, if I squint closely, the curved surfaces aren't set to smooth shading. Maybe that's one reason for so much topology. In Blender, go to object mode, select any curved parts, and type "shade smooth" into the command search. It's going to work wonders. You can then go into the Object Data Properties tab and check "auto smooth" to have sharp edges where needed. The left one has 504 triangles, the right has 156. Can you tell the difference?

There's a button called "Collapse/Expand" at least in Firestorm, should be in LL viewer too. You can close windows exactly like that with Ctrl-W, Ctrl-Shift-W might close all but I'm not sure. There's a setting to not preview opened items. Isn't this possible with EEP?

When a new body is created, it needs to be UV unwrapped somehow, so that the mesh knows where parts of any given texture should go. Instead of unwrapping things manually, you can get another already-unwrapped mesh and transfer UVs. This way, the new body can have its UV layout almost identical* to the original system body. *The layout won't be 1:1 because any difference in the shapes of the two bodies will cause the UV map to be skewed. This can be helped a little bit with manual editing, but it will never be 100% accurate. You can't map a ball to a square and expect perfect results. "Any difference is handled at the creator level" is correct in the sense that the creators must make sure that the mesh's UV matches as close as possible with the system body. "Just as the Omega system translates that, so does the BOM system" isn't true because they don't "translate" anything. There is no way for scripts to know anything about a texture (size, content, etc) or manipulate it. Omega works just like any other applier, it does nothing special aside from being widely accepted with its "universal interface" for making appliers. The Omega-specific listener script in each body just applies the textures different links/faces depending on the order and how many components the body has. BOM is the same deal, it only says "hey Mesh, this is your texture now" and the mesh goes "ok, let me apply it exactly as I was told to do by my creator." To @Alyona Su specifically: Do you sell that skin you made? If you don't, would you mind showing some screenshots of the toes from each body with your skin applied? Exactly. 🙂

All avatars and assets (objects, sounds, textures, etc) have unique UUIDs that can never be changed. However, depending on the reason why you're asking this question, parts of UUIDs can be identical. For example: Avatar A: "12345678-abcd-0000-0000-000000000000" Avatar B: "12345678-abcd-1111-1111-111111111111" So, if you're using only parts of a key (either a full section, or random characters), you might find two avatars (or anything else) that produce an identical result. The chances are low, but theoretically possible.

"Micro" mesh is just regular mesh with a trick. For example, look at my beautiful jewelry part: Marvelous, I know. The problem is that this part can only be sized down to 0.01 because of SL limits. That's too big! But what if I put a box around my work that's twice the size? It can still be sized down to 0.01, but now the detail I want people to actually see is 0.005 in scale! So what happens when I try to scale this up? Well, SL has a maximum scale of 64. That means people can only see the inside at a size of 32 meters.

First question I would ask: is it really the only animation in llGetAnimationList? What kind of situation are you in where the avatar's only animation is one to open their mouth? Not sitting on furniture, not using internal animations, nothing?

Not quite right. According to this wiki page, "Generally, above 15 FPS is good. The higher it gets, the smoother." I haven't heard them give any specific number. The servers operate at 45 FPS, meaning the sim will start a new round of calculations for everything (positions, rotations, scripts, etc) in a region every 1/45 (0.0222...) seconds. This is why the minimum event delay for scripts is 0.022 seconds for example. If all the calculations are finished faster than that, the sim will sleep until the next "frame." What we call "viewer FPS" is completely different. Viewers don't depend on updates from the server and it will never "duplicate frames." Server FPS is basically how often the world is updated. Viewer FPS is how often a new image of the current world is rendered, and there are no relationships between the two. This is most noticeable when you move your camera around. Even if you couldn't tell a visual difference between 15 FPS, 30 FPS, and 60 FPS, you can feel it. Let's imagine you orbit your camera around an object in one second. This is how many angles you would see the object from if your viewer was running at 15 FPS vs 60 FPS. Here's a gif of the 15 FPS (slowed to half) version and 60 FPS version. Or in the case of watching something else move while your camera is stationary, it doesn't matter how many keyframes are in an animation, the viewer will calculate create all the in-between positions. For example, your viewer will create this from a looping 2-frame animation (depending on FPS), regardless of whether it's a prim moving or an avatar waving their hand: There doesn't seem to be any proof of this. Ping, aka latency, is just the round-trip time of a signal going from you to the server and back. It doesn't make any sense to combine that information with things like server FPS or especially viewer FPS.

That sounds really clever, but how do you "sort" the vertices? Can it be done in Blender or am I gonna have to edit the .dae by hand? Does it need to be done for all LODs or just one?