A short term fix would be to, at the very least, test the name of the root joint before conversion.

In the meantime, a full set of copy/trans animations that will "Fix" your avatar is available on SLExchange for free, just look up unDeform kit.

I am really STRONGLY against this capability being removed, but.

1. When an animation distorts shape, the distortion should be undone by resetting the bone position, if that animation is stoppped
2. Stop all Animations should reset bone position

What you should NOT do, is remove the capability to do this in the first place. Please. Consider it like megaprims. Those have thousands of excellent uses, even though they were never intended functionality. To remove those would be a bad thing for creativity, and so with this.

Think of the possibilities.

Tiny avatars without invisiprims
Extendablle limbs. Think for a moment, on the thought of a stretching tentacle arm. You can't say that wouldn't be cool.
Larger avatars wityh actual body parts.The stretched parts of the avatar mesh can be covered over with prims.

PLEASE do not remove this capability.

I'm advising caution in calling this a "feature", because of the history of getting "stuck" with legacy bugs like this. Examples: invisiprims, WarpPos.

With invisiprims, we have functionality that really doesn't work too well, but it DOES at least partially allow people to make portions of their avatar invisible, and so LL seems to feel no need to actually provide us with a decent, robust, fully-supported alternative. The only way to do it is with the invisiprim hack, which results in nasty rendering artifacts such as alpha and shiny rendering incorrectly behind the invisiprim.

With WarpPos, there's a piece of functionality that was widely used, but LL didn't really realize this. They fixed this bug in the process of providing new functionality, and that broke a lot of content that relied on it. Again, not a good situation.

I'd advise against relying on this buggy functionality or developing it into a "feature" that a lot of people rely on. I think it should be fixed ASAP to avoid situations like the above. If you still want joint repositioning, please enter it as a Feature Suggestion, which will allow the community and LL the chance to suggest a much more robust, featureful, and reliable way to reposition joints.

It'd really suck to force LL's hand to make them keep legacy buggy behavior around, at the expense of implementing something like this the Right Way.

scripted avatar rotation
scripted control of skins/clothing
object returning functions
more attach points
the ability to texture the head with clothing
havok 4 (cough)

Ideally, yes. A fully supported solution would be best. But History has shown that's really not going to happen anytime soon. In the meantime, and until that is made, (ie, NOT now) I'd definitely prefer a quick improvement to stop all animations. and/or resetting bone position when editing appearance, over removing this until the indeterminate point when we get a better alternative, which could be months, or years away.

LL is struggling enough with fixing stability issues, scaling the grid, etc. They don't seem to ahve the resources to spend on implementing such functionality at the moment. While this deformation is far from perfect, it's infinitely better than nothing, which is what we'll be left with if it's "fixed".

My plans for it don't involve deforrming the entire avatar. I only want to stretch the torso. 2-3 animations, at most.

Now if only we could add on to the existing animation set, we could have tails and tentacles too. >D

I can't stress this enough: please don't force LL NOT to fix this bizarre behavior by filling the world with content that relies on it.

The right way, surely. Would be to implement position support for all joints. If we made content relying on this now,. please explain how adding the function for positional data for all joints, would break that ? Seems like it would be an addition to this functionality.

I'm all for doing things the right eay whenever possible, but sometimes compromises have to be made. Thee are a lot of proposals for invisible vatar skin color, for example.And it will likely be implemented eventually. Once that comes, invisiprims will fall out of general use, most likely.

Positional data in animations is not a bug. It's a part of the BVH format. This is merely an LL oversight( or possibly intentional) that failed to close a loophole. I don't see how this is particularly buggy.

And there really is no "right" way for some things when it comes to content creation. Although the general consensus is for better shape controls, I have an idea for this, that will ONLY work with this. Better shape controls are mostly what's wanted, but positional data in animations has unique applications too.

So as long as the ones using this used it correctly (IE: Looped low priority) then yes, simply correcting the deformation on stopping the deform animation would fix the problem more or less, while allowing creative types to use it.

The looping would be required anyways for any kind of legit use of these anims, as joint offsets aren't actually seen by anyone who wasn't in visual range when the animations played on the avatar. The only way to garantee that is by using the deform anims in a loop.

One word of mention. The original deformation anims by Blue Backbite or whatever his name was. Some of them were looped, so the user would have to use Tools->Stop all anims to stop them anyways.

It should also be noted, that positional data in animations, is a standard thing, used in many 3d programs. Though it was not intended to be in SL, it's existence is not a bug. It is a standard feature of animations. The current situation is proof that SL is capoable of suppporting it. It has good uses for content creators. All we need is a simple way to stop such animations if need be.

I really think it would be a wrong choice to remove this feature.

Think about it: if you can write an animation to create this effect... it's possible to write one to reverse it.

http://jira.secondlife.com/browse/VWR-2374

You can reproduce, and starting any of the free un-deform animations.
(available here: https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=338968)
Its nicely visible for the joints lCollar and rCollar. You will see that the joint moves, even as it should be already at the normal position. The effect is very strong, if you set your shoulder width to 0 for your shape and after deforming setting it back to 50.

This is all based on my own experiments, observation, and testing. It may not be completely accurate, and I welcome anyone who has more information to throw their lot in as well.

Undeformers Aren't Exact - The hierarchy data in the BVH files provided by Linden Lab were used as the base when I created my undeformers. Unfortunately, these BVH files don't exactly reflect what the avatar looks like inworld. I haven't had time to make an exact undeformer, since existing ones work so well most people don't notice.

My method for fixing this will be to get two people with the same shape, put them both on posing stands in the same coordinates, and then work out an undeformer that overlays them exactly. When done, changing their shapes to something wildly different should show whether or not a true undeformer is possible. Once one is created, it should be announced as "The One True Undeformer" and propagated as widely as possible.

If anyone wants to take the torch up before me, go ahead, for my plate runneth over. I don't want the glory, I just want the tool.

Deformed Avatars Sink - There are two sides to this bug. 1) The easily reproducible one is this: deform the avatar, and apply a new shape. Instant height offset. 2) As mentioned above, when a deformed avatar enters your range of vision, they sometimes sink. This is because you're loading them, and what did you load first? Their shape, or their deformations? If the shape is loaded first, they don't sink. If the shape is loaded second, they do.

I believe (but an not certain) that the difference between the two is thus. The first method updates the avatar's hip offset on the server. The second method updates the avatar's hip offset only on the client – client meaning it can be different for everyone looking at them. By "deruthing" (leaving someone's visual range and returning) you should be able to fix the second – as it'll cause the race condition again with another chance of the shape winning. However, for the first it requires undeforming and then changing shape to fix.

As a note. The 1.23 clients seem to carrying around the avatar's information for longer, or not drop it properly if they're nearby, but out of the cone of vision. Deruths may need to keep avatars out of sight for longer to actually work.

Surefire Undeforming - Because deformations are an animation, and because the client doesn't play animations on people not in your field of vision, if someone isn't WATCHING you when you undeform, you may still be deformed on their screen. In 1.22, "deruthing," even if off the person's screen, seems to undeform on everyone's screen. But not so much in 1.23. More testing is required.

This same thing applies for deformers, by the way. Which is why playing them in an infinite loop (on a low priority, and with zero ease out) is probably a good idea.

Aaaand... that's everything that immediately comes to mind. Let me know if I missed anything.