• 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.

Unable to convert MCX.dll.issue


Resource contributor
With the Czech language selected, I also get the same error. It must be something buried inside the MCX .dll. I'll send a note to Arno.



Resource contributor
I have just heard back from Arno. He reports that the file XtoMdl.exe supplied in the FSX SDK and used by MCX to convert models to FSX format requires that the decimal separator be ".". Unfortunately, the problem doesn't show up until the MCX .dll fails to convert the model and, hence, it gets blamed.

I'm surprised that this issue has not been reported more frequently. I will put a note in the manual to the effect that conversion form one format to the other requires use of "." as the decimal separator. As well, should it be possible, future versions of SAMM will report the "real" source of the problem.

(Actually, I shouldn't be surprised. I've just checked and there's a sticky near the top of the forum highlighting the issue. I'd forgotten it was there.)