Hi,

I looked into the demo and the model - and I have a very dumb question (without calling your project and your requirements into question): why don't you just simply animate all operations on the vehicle in animated bone sequences and wire them together ingame? This would also lead to less code overhead that is specifically designed for each vehicle and also gives you the opportunity to encode subtle animations like rotating/moving bolts or so. Because: all I see are simple animations, encoded to some keys in horizontal and vertical direction (without knowing what other operations you have planned on e.g. other vehicles, though). So in your case, a sequence "HLeft" and a sequence "HRight" could cover horizontal rotation from -1..0..+1 and a sequence "VUp" could cover the up-animation. Inside the animations you could make sure, that your hydraulics are correct and beautiful!!

From a technical point of view, the Gamestudio bone system has a major disadvantage which makes it not THAT easy to realize a "entBonerotateTo"-function. I did a while ago (2 yrs?) a facial animation system for a Gamestudio game with high def characters, in which they should turn their head towards the camera when the player is approaching and when the character can't turn the head anymore, the eyes should follow according to the camera position. During development, I found out, that in the initial configuration of the model, MED (or Gamestudio in general) doesn't save the appropriate Euler-angles which were used in MED to orientate the bones. This way, every bone, regardless how orientated, has the rotation (0,0,0). This way, you CAN NOT rotate the bone sequence back and forth to gain a bone, orientated to a specific position!

To solve this issue and make the animation system work with the camera position I adviced the rigger to create bones from the Root to the Neck to the eye bones that way, that they are ALWAYS aligned to either the X, Y or Z axis, so that I knew apriori the initial bone rotations. This way, I was able to re-rotate the bones and rotate the head and the eyes according to arbitrary positions in space, regardless of the pan and position of the character.

I also tried to reconstruct the orientation of the bones by taking the positions of the bones, their difference vector and the vec_to_angle function, but the mathematical problem is, that you have only two positions which define an axis. And as long as you look along this axis, you -cannot- determine, which rotation angle around this axis you have - this was very problematic, especially with the eye bones. In YOUR case, you could do that, though, I believe, if and only if you use special restrictions, like having all bones on the XZ-axis (--> y = 0). This way, you could reconstruct your angles appropriately.

But nevertheless, this would also lead again to very much code overhead and if I were you, I would fear, that I would have to write special code for each vehicle. And if you change your rig, you will have to adapt it. Otherwise, if you just execute animations, you are loosely coupled in that domain and you can change your animated vehicle in your modeling app as you wish and it works directly if you keep your animation names.

I hope that gives you (and others) some insight into this problem.