- Joined
- Feb 6, 2008
- Messages
- 37,739
- Reaction score
- 2,482
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Both sounds like good ideas to me. Since it's all we have right now, how about putting it in work?
well, i still have some (boring) university work to do, before I resume coding, I will take a look at fixing this later.
But I doubt its the mesh order - the animations are defined correctly, it looks more like the initial state of the animation is redefined. When we first load the mesh, it has its initial state(0) = doors closed. After ET separation, it seems like the door animations have changed initial state(0) = doors open. On the first SetAnimation call to something close to 1, the doors state makes a jump, as the animation initially assumed the current state of the animation was 0.0.
As we use 180° as angle for the animation, both are correct end points of the animation, but when we make a 180° rotation from the open position instead of the closed position, it will look just like its observed: The doors jump to the closed position and rotate through the inside from the open position.
I remember that other people observed such bugs with the 2006 version of Orbiter, but I can't find any information on how it got solved.