Raven Huntsman

The point in using undeformers comes down to the use case. As there is no LSL script API to trigger the reset skeleton feature* (as far as im aware). So products/tools etc which work with deforms will ultimately need undeforming animations and the like.

The above sounds a little like misinformation (or out of date information?) because in my experience, an 'undeform' or deform reset animation that has the bones keyed to zero puts the bones back to zero as expected. Given the age of this thread though, maybe things changed during that time however I thought I'd update as this post came up when I was searching. This is easily testable too, with a deforming animation and a reset animation on a single bone. Enable developer joints/bone view. Play the deform animation, stop it, then play the reset, and then use the in-viewer 'undeform' and 'reset skeleton' options. You'll observe no change between the reset animation and the in viewer undeform. Therefore functionally this is perfectly fine for user-experience. As for the OPs question, you can achieve a facial deform reset very easily by simply creating an untouched rig and keying the face bones (translation + rotation) to zero and exporting a .anim with bone translations.

You likely want to animate using a combination of FK (normal animation (forward kinematic)) and IK (Inverse Kinematic). Avastar provides an IK setup within it's rig that has decent results. See

LSL Scripting in general + Particles (also done through scripting). Note that more advanced aura and visual effects can also use a combination of unrigged and rigged mesh attachments in conjunction with Texture Sheet Animations (https://wiki.secondlife.com/wiki/LlSetLinkTextureAnim) Some relevant links: https://wiki.secondlife.com/wiki/LlParticleSystem (particles like auras, footprints etc, note that particles arn't always the only solution to stuff like this). https://wiki.secondlife.com/wiki/Collision_start (Doing stuff in response to a "bump") https://wiki.secondlife.com/wiki/Control (Doing stuff in response to the wearer providing input like movement)

Not entirely sure what you mean by "put different textures for an aura". Your question is very generic so I'll provide a generic answer, you can do a lot of things with HUDs and such and most of that power comes from LSL Scripting.

Does anyone know of any stores or animation products that provide facial expressions/moods that are provided in Priority 1? I'm working on a personal face/ao and I'm stacking it up fairly meticulously. I need P1 looping expressions/moods but finding it hard to find that specific detail about products and packs. For anyone curious, I'm setting it up as follows: - P0 Default Face Looping Animation (this ensures when a higher priority animation stops, any un-animated bones return to the default position (no randomly open mouth)). - P1 Looping Moods/Expressions - P2 Specific Eye and Mouth poses - P3 Anything non looping that is sort of reactionary to some avatar addon, clicker etc.

Thanks for the outline. I am indeed using a single script which houses a lot of my core functionality, one of which is a single 2 second timer which other scripts subscribe to with a variable tick rate and this core script will send out "timer link message callbacks" which everything else uses. I didn't want to over complicate the example but it does seem like SPPF seems to be the way to go!

This is the solution for alphas which glitch/clip through one another right. But is there a known fix for prims/objects with alpha blended textures glitching/flickering to black/dark depending on the angle you look at them when using ALM and in an environment with point or spot lights? (I don't consider FULL_BRIGHT a solution, as the result isn't as expected). In a typical render engine, you'd be able to disable the receiving of and casting of shadows on objects but they would still receive ambient lighting which would result in the ideal visual, as opposed to full bright which disables receiving shadows but also makes the prim fully lit at all times 'bright'. Using the mask blend mode isn't really a solution either because that defeats the purpose of using smooth alpha blending and isn't always applicable.

Thanks for the advice everyone. That's given me a lot to think about and consider for a final solution. Yep, this is basically what I was doing initially and as you said, it's not very sane but I was concerned about the performance if I did in a tidier manner (lists/loop). I've basically just got a number of rigged prims, you can think of them as cut out onion layers over a mesh body and each one can dynamically have it's alpha decreased to make the prim more visible via some user input. These then need to decay/alpha out over time based on a predefined but potentially change-able rate. Nothing overly complex but I am rewriting this logic so I'd like to be as performant as possible.

I'm unsure of how to implement the following in the most performant way. Could use some advise. Let's say I have a system whereby there is a timer tick (every 20 seconds). This timer will always be on/active (due to other dependencies that don't matter here). Now I have a number of integer variables storing links inside a linkset. Is it more performant to: Get the alpha of each link, check if it's non zero, lower it by x and then apply the alpha via llSetLinkAlpha. Repeating this logic for all let's say 15 link targets, every 20 seconds. Or Instead to add the link to a list when it's alpha is changed. And then every 20 seconds, iterate on this list and repeat the other alpha adjustment steps. The difference here being a choice between a large chunk of processing every 20 seconds, or a small memory overhead for much more optimal processing every 20 seconds. In my current system this would be operating on about 10-15 integers (link targets). It's probably negligible overall, but I am curious as to which would be performant within SL.

I was working on a script and now I'm unable to save changes, hitting save results in the following error: Unable to upload (some uuid) due to the following reason: Service unreachable. There appears to be market place maintenance going on but I wouldn't expect that to have knock ons here. Any one experienced this before? Just curious really, I've already backed up my changes. Edit: Still happening after a viewer restart (firestorm). At first I thought a restart resolved it, but I realised the scripts Im working on had their "Running" and "Mono" flags disabled. When I re-enabled them, the error popped back up and changes are no longer saving. It seems like disabling "Mono" for the scripts allows them to save, weird. Solved: Found the problem. I had duplicated some code where the same jump marker "@break;" was defined twice. Once I renamed the duplicate, the script saved/compiled as expected. Not sure why it didn't just throw an error there, maybe because I'm using the Firestorm pre-processor or this is just an unhandled exception /shrug.

Can you elaborate? What is this object that they are adding text to? Is it part of an attachment they're wearing? Something rezzed on the ground that they own? Or don't own? Is the text you want shown just using SLs built in floating text? Or are you talking about something like dynamic prim text (FURWARE) etc? Not enough information

Checked out Izzie Button's store? Lots of bom skin detail addons

I've been using ray casts recently and noticed an annoying issue that I'm confused by. Namely, custom static mesh planes which do have collision, seem to be ignored by llCastRay. I tested this by first confirming proper physical interactions. By creating a prim cube (Object A), enabling physics and dropping it on top of a custom mesh plane (Plane A), and then a prim cube (Plane B) scaled down on the Z axis all the way to 0.100. In both cases, Object A collides with both planes as expected. Next, I setup some touch logic in Object A, to cast a ray downwards and report the hits, placed over both planes at the same height/distance. Object A ray casting down onto Plane A reports nothing. Object A ray casting down onto Plane B reports a hit as expected. Is this intended behaviour? I've confirmed this raycast failure inside mesh buildings where the floor is a flat plane, the avatar is colliding with the floor and able to stand on it, but raycasts dont report a hit.

Thanks for the testing that, I was also curious so I stripped down to just my Shape/Brows/Eyes/Skin + Firestorm bridge object (can't detach that) and can still observe the issue. In fact for some reason the rate at which the end and start events repeat themselves increased ever so slightly with nothing attached. 😅 The attachment points you used caught my eye also, so I tried on right hand, avatar center and hud center. Same result, still repeats the events. Edit: I also managed to remove the Firestorm bridge object as one of it's target features is a move-lock (not that i use this feature) which I thought might be related, no change, behaviour still occurs.