Why do animations get broken during FS9 - FSX conversion?

#1
Hi,
Has anyone come up with a foolproof way of preventing working animations from suddenly breaking when converting models from FS9 to FSX / P3D.

I don't mean during the initial import of the model when MCX is trying to sort out the FS9 stuff, I mean later on when you have a perfectly good conversion and you do something seemingly simple that breaks all the animations.

Specifically I am doing conversions of AI aircraft from FS9 to FSX and P3D format. Some models have no problems, others are very fussy and require things being done in a strict order.
I have noticed that it is mostly assigning visibility conditions and or lights to a model that seems to be where the problem most commonly manifests itself. Although adding animations like nose wheel steering can also break the model.

The strangest part is that if the model is brought back into MCX all the animations look fine.
good.jpg
Broken.jpg


This is just an example. I know other models where you have to assign all the visibility tags to parts before any lights can added, otherwise the same thing happens.

Thanks
Gavin
 

=rk=

Resource contributor
#3
Gavin, the problem appears to arise in FS9 models that link all animations through parent dependencies to the tick18 visibility tag. Everything works as expected until you inadvertently break that chain. When the chain gets broken, all affected animated parts collapse to the center of the model. Your statement that "things have to be done in a strict order" demonstrates you have encountered this chain.
One tedious solution is to isolate every individual animation and then rebuild the model from those. It will work fine and you will have eliminated the tick18 dependency chain. Another trick is to parse the .xanim file using Notepad. Talk about strict, the fields are specific and well organized, making it easy to see and edit the pattern and experimental changes are a quick MCX compile away. Bear in mind that you can add animations freely so long as they are parented to something in the chain, or if they are unique to the model. As an example, you can add a waving flag but you must be careful about replacing a landing gear bogie.

Here is a FS2004 native model I edited to P3Dv4 standard. It was nearly complete when Arno started a development that in a few days made all my hard work obsolete. I'm waiting for him to perfect it before I do the model again using MCX. Here you can see all 3 propeller states working:


and here you can see I replaced the cargo load with my own model:



Finally, you really want to bookmark this thread.
 
#4
I’ll chime in here as well. I’ve also had this problem with the animations breaking when adding visibility conditions but for the most part, I have been able to recover the situation by removing the visibility tags, saving and then re-adding the visibility conditions. Generally, a second save has worked. I’ve compiled dozens of models this way over the past year or so.

This last week, I have attempted to convert two models and no matter how I proceed, the animations all break when I add any visibility conditions. There is nothing new in the parts I am adding visibility conditions to, just wheel chocks and warning tags in the main. If I remove the visibility tags and recompile, the animations are all fine, it is just the inclusion of the tags that creates the problem. It does appear the problem may be worse with the latest development release of MCX.

I’ll join all the others in looking forward to a solution to this very frustrating problem.

Graham
 
#5
So, if I might be so bold as to ask, if you compile a plane from FS9 to FSX, the animations 'should' work fine? But if you have visibilities or tags, then you are sunk?

I have just tried this, just wanted to see if I could export an FS9 model to FSX, and it worked, but none of the animations are correct, parts axis are way off, rudders off center (2 rudders), etc, etc. A mess.... But I have visibility tags.


Just curious. Can one delete parts in a model, like visibility parts? Also, is it possible to convert the materials to FSX class from inside MCX?
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#7
Hi Bill,

I'm working on the visibility conditions. At the moment they result in some broken animations. If you set the use conditions option to user defined you should have better results, but no visibility conditions at all.
 
#8
Bump!

Has anyone found a consistent work-around for the broken animations/visibility conditions issue yet ? Failing that, are older versions of MCX available anywhere ? I tried the link in the "Download ModelconverterX" thread stickied above, but pressing the link for past releases returns a "forbidden" tag.
 

Pyscen

Resource contributor
#9
What version are you wanting to go back to? The latest, if I recall correctly, is mid-June of this year. Is there a specific animation that isn't working?
 

tgibson

Resource contributor
#10
AFAIK, if you set the Use Conditions option to User Defined it should result in the same thing as an older version of MCX. Is this not working for you?
 
#11
Mr. Gibson is correct - my request was just my latest "Stupid Human Trick" - sorry all!

I'm mainly having trouble with Aileron and landing gear animations breaking after importing the various prop models.
 

tgibson

Resource contributor
#14
Hi,

When you add a visibility condition to a part without a separate SceneGraphNode in the Hierarchy Editor, many animations may be dislocated to the center of the plane, as Rick explains above. Graham mentions above that he was able to avoid this by reloading and saving the plane. I have been able to replicate this, even with the latest development version of MCX.

1. Import the plane.
2. Merge the part, if needed.
3. Open the Hierarchy Editor and find the part (turns red if the box is checked).
4. Add the visibility condition (click on the None below the Visibility Condition, and choose it from the drop down box).
5. Export Object.
6. Import the plane you just Exported.
7. Use Export Object again.

The visibility condition works fine, and the animated parts are back where they belong.

Hope this helps,
 
Top