Unknown Animation Error

We have our player character which has animations applied to it, it was made and animated in 3ds max then imported over. On of the aniamted features of our chracter is a catapult which is animated to move from +90 degrees counter clockwise to about 10 degrees. The problem we are having is during play our chracter's animation will start to go haywire at a random point. The catapult, instead of acting like previously specified, decided that it will rotate through about 1180 degrees and end up in an unkeyframed position.

Another animated part of the chracter is it's roof, this has an animation that when activate makes the roof wobble like a pan with a lid on boiling over. Again whilst playing our animations randomly go haywire and if this one is activated before/during the animations going nuts then the roof floats off into the air, still playing it's animation but moving up on the y value endlessly. Which isn't keyframed.

Our question is why. Why does it act in such a way? It seems impossible as they have not been animated to be able to that nor do we think we have set them to do it in the script. Here is a script for two of the animations as discribed above. They are RPC'd to synchronise animations for online play and the crazy animations fault happens from everyones view. The only answer we can think is to submit an error report, but we don't want to do that till some Pros on this site have taken a look at our problem.

@RPC
function animCatapult()
{
    var catapult : AnimationState;
    catapult = animation["catapult"];
    catapult.layer = 11;
    catapult.wrapMode = WrapMode.Once;
    catapult.blendMode = AnimationBlendMode.Additive;
    animation.Play("catapult");
}

@RPC
function pickupTrupt()
{
    var havetearuption : AnimationState;
    havetearuption = animation["tearuptionready"];
    havetearuption.layer = 12;
    //set to loop
    havetearuption.wrapMode = WrapMode.Loop;
    havetearuption.blendMode = AnimationBlendMode.Additive;
    //lower speed
    havetearuption.speed = 0.7;
    animation.Play("tearuptionready");
}

EDIT

The player is a series of meshes (all one object) parented individually to an overall gameObject which contains it's character controller, scripts and animations. It does not have a rigidbody or ANY colliders (except character controller) It is not using bones it's just the transforms being animated. It is NEVER consistenet so there is no way of telling what sets off this behaviour.

I want the bounty! :)

My guess is that you're playing only additive animation. In that case what you get that additive animation is added on and on on the transforms, but transforms are never reset to the rest/idle pose. It's the part in Unity design that confuses a lot of people.

A workaround: try playing a regular (non-additive) animation at the same. You can use just simple static animation. See if that works.

Look at larger scale: do you really need to play additive animation - I rarely see someone who needs to play only additive animation. Additive animations are mostly used to play something on top of other animatoins.

Apparently, the base, non-additive animation needs to use all of the bones, even the ones it won't move.

I saw a project last week where the additive animation over a looping base was going all spinny crazy. We got it to work with a dummy base animation. The animator eventually asked if it might be because the arm-bones (he was manually aiming a gun) deliberately hadn't been keyframed (some word like that, I'm not an animator) in his walk cycle.

If you have ONE base animation which you always play, it should give a very consistant error. But, if you have variously blended base animations, I could see this being an intermittant problem, only when that one incomplete base animation happens to be alone.

Okay thank you everyone for your help. We have tried everything stated here and non of these have fixed the errors. What people seem to be overlooking is the fact that it works PERFECTLY up until a random point online. We cannot figure out exactly what happens at that point in time to make the additive animations go crazy. Anyway I'l keep this updated to inform others of the fix we applied to stop or atleast minimise the problem somehow.