• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Experiences with FS2004 aircraft import/export

Arno,
Regarding shading, I reset MCX to defaults and shading is working properly. I have no idea what settings I had on to make an issue with shading in MCX and in Sim.
Thanks for checking and sorry for the distraction.
 
OK, thanks for the feedback. Glad to hear that it is working fine now.
 
Arno,
I was asked by Martin if I would like to contribute some testing.
Firstly I have ensured that I have the latest dev version installed, 7/1, I then decided to try relatively uncomplicated tests. I decided to try compiling from FSX mdls to FS9. I also decided to use two aircraft from different sources so as to experience different source and compilation methods.

The two I chose were an Il-38 by Krek26 (IL38\1) from his pack and one of John Young's Andovers (ETPS). I decided on these because of Tom's work on multi-props and didn't want time being wasted on known issues.

Both can be made available to you should it be necessary if you can't find them.

IL-38
Generally converts well in MCX. Two things become apparent in game though.
1. The Starboard outer spinner (prop0) becomes transparent when in prop0_blur mode. See MAIW_0661.jpg and also visible in MAIW_0660.jpg
2. No shadow formed with the exception of the 4 spinners and one unidentified item ( possibly starboard wingtip related). see MAIW_0660.jpg

Andover
Seems to convert well with one noticeable and obvious exception.
1. When the aircraft stops the props rotate around a point in the middle of the aircraft coming to rest at 90 degs realtive to their original position. See MAIW_0662.jpg.
This is recreate-able in MCX by using the animation slider.

All pics attached, hopefully.

Now I delved into the Andover issue a bit.
What I found was that the FSX mdl had 4x prop0_blurred and 3x prop0_slow anims, and the same for prop1.
The FS9 mdl has 3x prop0_blurred and 3x prop_slow and also a prop0_still anim.
When selecting the _still anims and moving the anim slider the entire rotate 360 degs horizontally around the centre point.

From my inexperienced view it seems that the conversion changes one blurred anim to a still anim but instead of rotating the prop around the mount point it rotates the whole thing around the centre point.
Hopefully this helps.

One last thing I should mention that my experience in FS work is related to fde's and error testing. I seemingly do not possess a creative gene in my body so textures and modelling are seemingly beyond me.
I will help in anyway I can. I can also provide the interim files should they be necessary.

One final issue that is common to both that I find perplexing. Both converted mdls show up as FSX mdls rather than FS9 in Martin's AIAE tool.
Now in itself if they work in game it is not a big thing but of course it means that you can't set the model radius. Not sure if it's an MCX conversion thing or an AIAE getting confused thing.
 

Attachments

  • MAIW_0660.jpg
    MAIW_0660.jpg
    2.2 MB · Views: 124
  • MAIW_0661.jpg
    MAIW_0661.jpg
    1.4 MB · Views: 122
  • MAIW_0662.jpg
    MAIW_0662.jpg
    1.8 MB · Views: 113
One final issue that is common to both that I find perplexing. Both converted mdls show up as FSX mdls rather than FS9 in Martin's AIAE tool.
Now in itself if they work in game it is not a big thing but of course it means that you can't set the model radius. Not sure if it's an MCX conversion thing or an AIAE getting confused thing.

Steve, I could just replicate this and it is definitely due to AIAE, not to MCX. I come back to you about this one.

I did not envision to have FS9 and FSX models in one aircraft setup. So this is not updated when you change models in AIAE, only the last model type is shown. I will correct this.
 
Last edited:
Hi Steve,
The two I chose were an Il-38 by Krek26 (IL38\1) from his pack and one of John Young's Andovers (ETPS). I decided on these because of Tom's work on multi-props and didn't want time being wasted on known issues.

Both can be made available to you should it be necessary if you can't find them.
Thanks, I have added the issues to my todo list to check. These are indeed new issues I have not seen before. I'll check them.

I'll see if I can easily find the models, but if you can just send their download link or the model directly to me that always helps.
 
Sure where would I look for that? Thanks
If you enable the Keep X file option in the settings it will be saved in the same folder where you exported the MDL file to.
 
I now see why the airstairs visibility condition is backwards. In my original MakeMDL.parts code there are two lines present that reverse the effect of the code:

<minvalue>-1</minvalue>
<maxvalue>0</maxvalue>

They have been removed when MCX converts the code to FSX format.

These lines basically say “if the code is false, then it is in range”.

I will try editing the MCX code to flip the true/false logic and get around this that way.

PS. This format was in a forum post and I used it since I was new to xml programming at the time. 😁

And thanks for finding those errors in my file, I will fix them. From now on I will use a default MakeMDL.parts file since that is what others will have.
 
Last edited:
Arno,
The IL-18 package is here Il-18 and the Andover package is here JYAI Andover .
As stated before but I will save you having to find them the particular mdls I am currently concentrating on are the 'IL38\1' and the 'ETPS' ones of those types.

In regards to the shadows one thing that I will mention is what Tom and yourself discussed with the IL38 having a black alpha instead of the normal white one. Your subsequent changes to MCX handled this successfully but I do wonder if the in game shadows issue is related to it.
 
Hi Tom,
I now see why the airstairs visibility condition is backwards. In my original MakeMDL.parts code there are two lines present that reverse the effect of the code:

<minvalue>-1</minvalue>
<maxvalue>0</maxvalue>

They have been removed when MCX converts the code to FSX format.
Let me check how I could represent that correctly in the FSX format. I am not sure there is a min/max value attribute there. But on the other hand, when you import the MDL file the condition is read from the MDL file and not from the XML code. So it seems also that path has an issue.
 
The IL-18 package is here Il-18 and the Andover package is here JYAI Andover .
As stated before but I will save you having to find them the particular mdls I am currently concentrating on are the 'IL38\1' and the 'ETPS' ones of those types.
Thanks, downloaded them and will use them to try to reproduce the issues you reported.
In regards to the shadows one thing that I will mention is what Tom and yourself discussed with the IL38 having a black alpha instead of the normal white one. Your subsequent changes to MCX handled this successfully but I do wonder if the in game shadows issue is related to it.
That's an interesting thought. I am sure what could influence the shadow, it's something to look into.
 
I can confirm that after switching to a default makemdl.parts file and MCX creating custom animation tags, the airstairs visibility is still backwards. Editing the plane's modeldef file in MCX to reverse the logic does fix this.

But it did add another thing to the list - the animated panel of the airstairs is not just not animated, it is displaced.

EDIT: I tried adding the min and max value lines to the MCX modeldef files (assuming they needed to be capitalized), but it made no difference to the visibility - still backwards.
 
Last edited:
Here you go! The I named the files according to the version of MCX used. The ones labeled 160 compiled correctly.. The ones labeled dev failed with the red messages...
I can reproduce the error with your X file here, so it's something in the file that causes it and not something on your system or so. Now need to figure out what it is.
 
I found two issues with the Animation Editor.

Load a plane.
Go to the Animation Editor and click Select None.
Close the animation editor.
Use the animation slider - nothing moves.
You have to re-select the tags in the Animation Editor to get anything moving again.

Also, there is an odd interaction between the exterior and interior models. Using Select None in the exterior model turns off some of the animations in the interior model as well.

Hope this helps,
 
Last edited:
Thanks Tom, let me check what happens there.
 
I found two issues with the Animation Editor.

Load a plane.
Go to the Animation Editor and click Select None.
Close the animation editor.
Use the animation slider - nothing moves.
You have to re-select the tags in the Animation Editor to get anything moving again.

Also, there is an odd interaction between the exterior and interior models. Using Select None in the exterior model turns off some of the animations in the interior model as well.

Hope this helps,

Isn't that how that is supposed to work???? That way you can turn off and view animations individually and know which ones to edit if necessary...
 
I guess you are right, older versions also worked that way, I never noticed!

It doesn't make a lot of sense to me that animations should be turned off once the editor is closed, though.

But the problem between exterior and interior animations does exist.
 
Last edited:
I would expect that when you close the editor all animations are enabled again. But sounds like I never implemented that :)
 
Back
Top