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.

I've been doing some scripting work recently which makes use of the land_collision_start and land_collision_end events. What I'm observing is that a script as simple as: default { land_collision_start(vector p) { llOwnerSay("land col start"); } land_collision_end(vector p) { llOwnerSay("land col end"); } } Once attached to an avatar will repeatedly trigger each event, alternating at a consistent rate. I can see this occurring on other parcels too, as long as I'm standing on the ground and not moving. Rotating my avatar will prevent this behaviour until I stop pressing any inputs. Is this intended behaviour? Am I not accounting for something, because ideally I'd like to keep my EPS (events per second) to a bare minimum, but If im stood on land this becomes an issue as my collision logic triggers other semi-resource heavy logic (raycasts and such). Note that with the avatar hitbox visible via developer metadata, the hitbox is completely stationary, at least visibly.

The base movement velocities/speeds of an avatar are pretty well defined on the wiki for different states like walking/running. Im trying to find out what the speed is for avatar rotation at it's maximum (so ignoring the user adjustable deadzone). Preferably in something workable, degrees/rads/revolutions per second rather and force/torque values. Is this documented anywhere? Thanks.

Thanks for the thoughts everyone. It was interesting to see how people perceived this. Many were observing the animations at play. I wanted to gauge what people saw first and thought was interesting. There were a few who noticed what is really going on behind the scenes here. The actual wear and unwear animations were just a proof of concept/me having some fun with what is possible with these feet. To summarize, the feet, stockings, heels and accessories are all custom rigged mesh, for the purpose of having a single 'foot mesh' which can be animated to shape to any of the existing foot shapes that have become a standard (flat, low, mid, high, pointe). These feet can bend at the ankle, the foot (a central bone to facilitate more flexible curving) and the toes. Depending on how you rig mesh footwear to these feet, like heels for example, you can create that fun little 'peel away' from the foot effect via animation. Of course the implications of something like this would be minor convenience to the end user, bigger convenience to the creators as we'd only have to rig to a single foot shape/mesh. Possible offshoot things like fun animations and what not. The downside being that these would mostly invalidate existing footwear products. One other pseudo-benefit I've observed is that, by making my own standing/walk/run animations, I can effectively 'bake' my foot shape height differences into the animation, thereby removing the need to ever mess with hover height (you can see this at play in the gifs too, 0 hover height setting on both). This also invalidates that awkward state you can find yourself in if you have non flat fleet and you sit on some furniture, requiring possibly an ankle lock and hover height adjustments. Because it's all animation driven, the bare minimum needed would be to detect that you've sat down and enforce a high priority animation to keep your foot posed in whatever non flat shape its in. (Just in case you find a nude foot NSFW.. don't look 😄) https://imgur.com/a/5ZS2Bfw (Switching between different shapes) https://imgur.com/a/dDAgpsS (Walking anim at 0.5x speed to make it easier to see the heel peel effect)

Wanted to get peoples thoughts on this: https://imgur.com/a/hP5gGFl Note, the lack of explanation or description is deliberate 🙂

Would be helpful to know what exactly you need from a script.

The best way I've found to achieve this when you have the freedom to use the control event is to completely override the movement inputs and set the velocity manually. You can go as deep as you want with this avenue, adding your own ramping/lerping etc. Generally I use the 3.5m/s avatar walk speed as a basis to generate my velocities and then scale down (or up) from there depending on my needs.

@Quistess Alpha I finally got around to trying out that possible solution and to my surprise it didn't work. I actually observed the attachment detach itself while the detach=n restriction was still active. My test case was to enable the restriction (separate call), attach the object. Then try reattaching a few times, still able to repro the issue, while the detach restriction was enabled. Very odd, I'll likely have to find a way to debug the attachment itself (going to take me ages ha) and figure out what's causing the issue.

Having an issue with the RLVa API (Firestorm viewer) whereby I have a script that runs the following command via llOwnerSay; "@attachallover:/~MyCustomBody/1.0.0=force". This is a pretty standard attach command and it does work, but for this attachment specifically, it very often attaches and then the object detaches itself almost immediately. Once I reattach it following this bug, the script state inside the object (MyCustomBody) is totally borked. It uses a number of states and some complex HTTP calls but I'm unsure what could result in this behaviour. Have any RLV/a scripters encountered this before? TL:DR RLV Attach command doesn't work correctly for a very specific attachment, detaching itself immediately when attached which results in broken script states within the target object. Some Notes: This issue doesn't happen all the time, I'd say 70-80% of the time when I call the attach command. The script/s inside the target object do not have any logic to self detach. I can only assume that some x logic in lsl does not play well with the RLV attachallover process and is intermittently resulting in a detach.

You probably want muscle definition materials, quick search on the marketplace of muscle in the avatar component section should do for these.