Wulfie Reanimator

Whether you have a graphics card by Nvidia or AMD, both of them can limit the framerate of any app (including your viewer) even if they lack a built-in setting for it. All viewers should have a Vsync option (which limits the viewer to your monitor's refresh rate, usually 60), and most third-party viewers should have a "max. framerate" slider. Higher framerates won't cause things to "slow down" or "become hard to control," but can have other effects you won't like, like heat or fan noise. While the region will update avatars/scripts/objects at most 45 times per second (also known as "server frames", "server FPS", or "tick-rate"), many things can be updated much faster than that by your own viewer: camera movement, avatar animations, texture animations, rotating objects, moving objects, particle effects... etc.

Actively do anything? Nothing any other random passer-by couldn't do. Most bots, especially the ones that pop by for a few seconds, are only there to collect data. Bonniebots are a known example.

This is super simple and doesn't require a lot of code, I'm not sure what you meant by "it would suck to double the amount of code" after mentioning llDeleteSubString. string truncateFloat(float f) { integer dot = llSubStringIndex((string)f, "."); return llDeleteSubString((string)f, dot + 2, -1); } Or as Bleu pointed out: string truncateFloat(float f) { return llDeleteSubString((string)f, -5, -1); }

Keep in mind that notecards never change. When you edit a notecard, you're creating a new notecard with a new UUID. If you use the old UUID, you'll be reading the old contents.

Firestorm has a performance tool to genuinely measure which of your attachments take the longest to render (meaning they have the biggest impact to framerate). If can be found under Advanced > Performance Tools > Improve Graphics Speed > Your avatar complexity This will show just how inaccurate Complexity (= ARC, Avatar Rendering Cost) is as a measure of how "well" or "badly" something is made in terms of performance. Just in the picture above, there are 3 attachments with 1000-2000 complexity that take significantly longer to render than an attachment with 39'000 complexity.

Script time is an average over the past 30 minutes.

When have we ever? 😋

Neat, just tried it. It's not great, it's almost detrimental. If you add an animation to the Asset Blacklist (there's a button in the Animation Explorer to do that), Firestorm will check for that animation every second and stop it. The animation plays for everybody until your viewer stops it, so it's not going to prevent griefers from playing animations on you. (Realistically there's nothing viewers can do to prevent this, because animation-state is enforced by the sim.) And while you don't see the animation playing on your screen, other people will. If a griefer plays a deformer on you and you blacklist it, you won't even know when it happens again. The "reset skeleton & animation" option is client-side, so your avatar wouldn't get fixed on other people's screens even if Firestorm did undeform the avatar while stopping blacklisted animations.

Animation permissions cannot be revoked from objects attached to avatars, so the suggested option won't work if the griefer is wearing the object (which is almost guaranteed).

The only things you can do is report them (Help > Report Abuse) and avoid them.

Web profiles are being phased out in favor of the profiles you see in your viewer. You can't change your web profile's picture and probably shouldn't spend any effort in using it.

Link for easier access: https://github.com/secondlife/viewer/blob/77395eddc911e0801e50fd693f7bbaee8046aa95/indra/newview/llviewerobject.cpp#L6907 And yeah, the problem is obvious. It's not smart to make hundreds and thousands of cumulative changes with floats. I'm fairly sure this function could be rewritten to just not track cumulative changes but always calculate the new rotation based on the original rotation + total time passed. Obviously, precision issues will never go away, but this should avoid visible drift over time.

The emitter's rotation affects the direction of particles, easiest way to see that is with Angle Cone -type emitters.

Yup. If you add an image to an inventory item/folder and pass that to another person, they will see the image.

It's a free upload. The UUID does exist, but it's intentionally not exposed to you. You can do the same thing to give any inventory object an image, not just in the outfit gallery.

Are you on Mac with shadows on enabled? There's a known issue in the latest SL Viewer release: BUG-234724 [PBR] [Mac] Turning shadows on makes items with alpha blend textures disappear On Windows, things look fine to me.

As hilarious as it sounds (and it does), it's a wider problem and not as hilarious. (BLE itself is the problem -- anything that uses BLE has the same problem!) This is the blog post by Giovanni Mellini they're referring to: https://scubarda.com/2017/10/17/hacking-a-bt-low-energy-ble-butt-plug/ Related (not fun) reading: https://www.evilsocket.net/2017/09/23/This-is-not-a-post-about-BLE-introducing-BLEAH/

Huh, apparently so! Only 3 of their toys (Nora, Solace, Max 2) have supported buttons, though.

That's right. The "flat normal" blue is <128, 128, 255> (RGB) as in <0, 0, 1> (vector) relative to the face itself (in tangent space). The darkest strip of color in the wall's normal map corresponds to about a +30 degree angle on the Y axis, which is a valid value for an overhang. When the object is rotated 180 degrees, the "bottom" of the overhang becomes exposed to light, and shading should disappear. That works. When only the normal map is rotated 180 degrees, the face's shading doesn't change. That's a bug. So the problem appears to be that the renderer's texture-shading part doesn't consider texture transformations at all (rotation nor scale). P.S. I'm glad someone else noticed the slightly-off normals. I thought I was losing my mind or it would've been due to compression. 😋

No way. 🙂 Lovense toys are "output devices" unlike game controllers, they're more like speakers. They don't send any button inputs to any device they're connected to. (Bluetooth or USB -- though USB is only used for charging.)

You can also connect to the user's device (with the app which controls the toys) directly, without accessing Lovense's cloud services. I have scripts for this, but it's not as user-friendly as communicating through Lovense. It requires the device's public IP and possibly port-forwarding depending on the situation. (The phone app hosts itself and accepts HTTP requests for controlling connected toys. The PC IP is easy enough to get automatically.)

I figured, but the toys themselves don't even know that. 😋

Don't worry, the Lovense app itself already tells your partner which specific toy(s) are connected.

Does this drift happen only in the "reflection" or does it also show up in the projected light? (I imagine it must happen on both, but weirder bugs exist.) This definitely should go on the Jir- uhh... Github Issues? Canny? Somewhere.

It's just an automated feature of this forum framework LL uses. Ignore it, it's fine.