Flexi-prims as joints?

While flexi-prims are pretty cool, the uses for them that I can think of are fairly limited, and most of those I likely won't bother with anyway.
My original hope was to use them for a tail, however these will only be suited for rat tails I think (ie a cone flexi-prim).

I was just thinking though, if it were possible to linksolid objects to a flexi-prim root, we could have an client-side replacement for joints, allowing us to get the behaviour of a flexi-prim, but with any design we could want!
My tail is a fox tail you see, so it's a whole load of prims to get the sort of 'bushy' dimensions for it. But flexi-prims are no good for it at all which is a shame

How hard would it be to have non-flexi objects, that are linked to a flexi-root prim, mimicking the movement at the nearest point. e.g, I would link my tail so that the base is the root, I would then link it to the flexi-prim (say a cylinder), my tail would mimick the behaviour of the flexi-prim segment nearest to it's root (the tail base).

It's getting hard to explain, but say that the flexi-prim has four segments, my tail base centres around segment 2, each movement of segment 2 would therefore be applied to the tail base, and thus the rest of the tail?

It would also be interesting for some weird rides and stuff, but would also allow for the creation of shapes that flexi-prims currently don't do. If we could have have prims attached to multiple points on a flexi-prim (e.g I could replace my tail by having a long flexi-prim and attaching spheres along its length, each one attaching to a different segment), then it would really make this something to be excited about!

It would be nice to at least be able to link to the end of a flexiprim.

But I can see why they don't do it. It would bring back all the joint issues, unless they were able to severely restrict what the "end" prim could do.

If they would at least make flexi spheres it would really increase the options.

Hmm, I think the problem with joints is because they were physical, so they had to calculate things like object collisions and stuff which they didn't do very well and broke as a result.

Flex-prims seem to be exhibiting much the same result as joints but are client-side only (and phantom) so shouldn't suffer the same troubles, in theory at least, as any movement they make (and cause attached objects to make) wouldn't have any lasting effect, just like target omega.

Indeed, the major issue with the joints was the ability to crash sims or seriously slow them down with even simple builds. As was debated in the General forum, there's really only three or four successfully created joint base objects being used in SL (granted, that's three or four objects that were sold to and used by a non-trivial number of people), largely because joints were difficult to understand and even harder to get to work properly. Much of the population would tell new residents, "Don't use joints, they don't work (or don't work well)." And they were right.

However flexiprims only lag the client side, not the sims. The worst an improper implementation could do is seriously lag or crash clients who view flexi-"joints" and that's easily dealt with by detatching the offending prim (I can't really see a use for flexies on flexies off of an avatar's body, except perhaps realistic fish?) or turning off flexies completely in its presense. Unlike joints though, which were bound to a physics engine, flexies follow a lack of physics. Or rather an implied physics through the use of a vector force setting and gravity setting (gravity being, I suspect, just a value to apply to the Z axis of the force). The individual vertex positions and rotations are already being calculated along the body of the flexiprim, including (and most importantly) the free end of the flexiprim, so sending those updates to linked prims should be an easy task.

Mostly it was because there was "joint code" all through the system. But you're right, it wouldn't bring back all the problems, and it would be neat... but they'd still have to have some way of specifying that a prim was attached to a specific point on another prim, and that's unlikely to happen soon.

Oh, and hopefully NOT just like targetOmega. Have you ever set that on a physical object?