Action Constraints can't pass Mesh Data?

I have been banging my head all morning trying to get an action constraint to auto apply some shape keys to a bone. I was able to make an action to do exactly what I wanted, but I was having trouble getting the action constraint to show my keyframed shapekeys. It works when you scrub the time line, but not when you hook up the action to a bone. It turns out that the action constraint ignores all data other then the transformations of an object

I found this in the documents:

“Note that even if the constraint accepts the Mesh action type, only the Object, Pose and Constraint types are really working, as constraints can only affect objects’ or bones’ transform properties, and not meshes’ shapes… . Also note that only the object transformation (location, rotation, scale) is affected by the action, if the action contains keyframes for other properties they are ignored, as constraints do not influence those.”

Why is this the case? I would think using an action constraint to automate the use of corrective keyshapes would be much more intuitive (especially for me) to work with. For me, setting up multiple drivers is a pain and if the action contraint would pass all of the keyframed data, it would make for a much simpler system.

Anyone have any thoughts on this?

Sorry for the bump but I feel like I need to take another stab at this topic.

As I stated above, Action Constraints currently only affect the transforms of an object (LocRotScale). It ignores all other keyframed properties within that action. But what if this was changed so any keyframed property could be controlled with an Action Constraint? In my example above, I was trying to create an action that would apply several shapekeys throughout the x rotation of the forearm. I had three shapekeys in my action. (A corrective shape for the elbow, a bicep bulge shape and a bicep squish shape for the extreme.)

You may ask, why use an action constraint for this instead of a driver? The main reason is, if you use a driver on a property, you lose control of that property because now it is driven by something else. (You can work around this by doing a parenting trick but that adds more complication to the rig, IMHO.) Action Constraints work in a different way, so in this instance, you would not loose control of the shapekey. You would still be able to set it’s value though out an animation.

Another reason is, it would be a great way to have drive multiple properties and have them all in one area for editing and fine tuning. My example uses shapekey values, but there is no reason you could not use this for any other property like the color or intensity of a light, or maybe a cameras focal distance. The possibilities are endless.

I’ll admit that I am not a coder and maybe I am simplifying this too much, but the framework for the Action Constraint to work this way already appears to be in place. It just need to be modified to include the other keyframed data in the action.

Hopefully my second explanation was a little more clear then my OP and you can all see the power this would add to the constraint.