I ran into a snag developing the FLM file loader related to the limitations of the existing anm_import script. One problem was animation files that contain more than one animation. I didn't see a way to make sure the right animation data was going to the right actor. So I decided to focus on the problem of animation files with more than one animation. These files are like little scenes in themselves and the old animation import scripts did not know how to use the origin and destination data.
The animation header contains a matrix that defines the "origin" of the animation and that matrix represents the origin of the first bone animation in the file, with respect to the external world. If there is a second animation, there will be a second origin matrix, but this matrix is defined with respect to the first origin, not with respect to the external world. So, you can get the orientation and location of the first bone animation from the first origin matrix (call it O1), but if there is a second origin (O2), the orientation of the second bone animation in world space is give by: O2*O1.
O1 and O2 are 4x4 matrices. The first 3 rows and columns give the rotation matrix for an object and the first 3 elements of the bottom row give the location of the object. The last column contains 3 zeros and a 1. The nice thing about this way of representing position and orientation is that you can multiply them together to compute the effect of a series of rotations and translations. And the great thing about Blender Python is that it has math utilities to perform all these operations (most of them anyway).
The third piece of information in the anm file that I had not been using is the "destination" data. The destination data is a position and an angle. The angle is a rotation about the Z axis. This allows the animator to apply a smooth linear movement to his animation as it plays. You can use this information to construct a 4x4 matrix (call it D for destination) which describes the orientation and position of the animation at the last frame relative to it's position in the first frame.
So, if the first animated object is at O1 in frame 1, and the destination is D1, then the final orientation and position is give by D1*O1. On the other hand, the second animation starts at O2*O1 and ends at D2*O2*O1. At least, that is the way I think it works.
In order to test this theory, I wrote a script to load the file wes_horse_rider_mount.anm. You start the script with an empty scene and it loads all the data into memory. If there bone_count is 30, it imports woody and applies the bone animation data to woody's armature. If the bone_count is 59, it imports a horse mesh and applies the bone animation data to its armature. Woody is the first character to be loaded, so the origin data (O1) applied to the container empty (00.woody) and a key frame is set in frame 1. The destination matrix (D1) is then constructed and the product D1*O1 is applied to the container empty at the end frame of the animation and a keyframe is set there.
The horse animation comes second, so the container empty for the horse (00.horse) is positioned to O2*O1 in frame 1 and key framed, and at the endframe it is positioned to D2*O2*O1 and key framed. The interpolation mode is set to linear for all Ipos in the scene, to insure linear interpolation between the first and last keyframes.
Here is a video showing the results of a test run using the wes_horse_rider_mount animation file.