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

Oops, a bug…

arno

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
33,929
Country
netherlands
In the latest development release of ModelConverterX I have fixed a bug with the export of the metallic, roughness and AO texture (the comp texture) to MSFS models. That there are bugs in my tools now and then is something I am used to (bug free software is hard to find). But for this bug I was a bit shocked that it has been in ModelConverterX for about 9 months and it only got reported to me by two users in the last few weeks. And with the bug present the comp texture in glTF models would not work in MSFS at all.

I introduced this bug while adding support for MSFS 2024 materials at the end of last year. But to be honest I am still not really a MSFS guy. The way of working of FS2004 and FSX is still more in my system. So personally I don’t really notice if the materials are working right, I more look at them from the coding point of view (glTF file format, OpenGL shaders to render them). I would not even know how to make a comp texture from scratch myself.

And the fact that MSFS takes so long to just startup and test a simple object (something that takes very little time in FSX), also means that personally I don’t really enjoy if I have to test something in that sim. I really miss the old SDK tools that you can just run from the command prompt, instead of having to fire up the whole simulator to just compile a project. And then I don’t even mention the fact that each time I start up MSFS I first have to download a few GB of updates before it will run.

Sorry for ranting a bit about MSFS here :). Let’s summarize this post by saying that I am very happy to get feedback from developers who are more into MSFS on things that are broken or could be improved in my tools. I’m sure that together we can fix them and maybe one day I will get more used to the MSFS way of doing things…

Continue reading...
 
I share your pain with the time it takes to start MSFS every time I want to test my scenery objects, but your post has given me an idea, namely test objects by importing my .gltf file into MCX. I have no idea why I did not think of this before, so thanks for your inspiration. And Thank You for your work on MCX which is invaluable.
 
Hi,

Since we are talking about MSFS and MCX, I noticed from last week (already with the previous release of today’s one) that when I loaded my planes just compiled for MSFS, the textures appeared modified (I didn’t test any further to see if they were simply returned).
Here is an example with one of my Canso PBY that I just compiled, with a Calypso repaint: the good rendering on the left and the current rendering on the right.

1758891430081.png


Some precision: this is an aircraft compiled for MSFS 2020 with the SDK 2020.
 
Last edited:
Looks like the texture is flipped or so. Let me see if I can reproduce it.
 
The latest dev-build seems to export P3D v4.4 bgl files as non PBR P3D4 bgl files.
During export it logs warnings like 'Material XXX is a PBR material, this is only supported for P3D v4.4' although I have definetely selected P3D v4.4 format for scenery export.
 
Also suspicious... The exporter asks for the P3D v4 XtoMdl path (which I currently have not set) although I want to export in v4.4. If I set the path for v4 the export runs but gives you a v4 file.
Btw. the export of mdl files works without that problem.
 
Last edited:
Sounds like a bug that the selection of the format is having an offset or so. I'll check.
 
I have just tried to reproduce the issue, but I do not see it on my machine. I do get the warning about the PBR material when I export as v2 or v4 P3D MDL file, but if I select P3D v4.4 MDL from the list it does export fine.

Did you do a clean install of MCX? And what OS are you running?
 
Mdl export is working perfectly fine. It's the bgl export that has problems.
I used the 'Reset all to default' function in the options menu, deleted all content in 'AppData\Local\SceneryDesign.org' and freshly unzipped mcx. I guess that should be a 'clean' install then (although the SDK paths seem to be stored somewhere else).
I'm using the latest build of Windows 11.
 
Sorry, my mistake, I checked the wrong one. Let me double check the bgl.
 
I have found the bug (I encountered a similar one while testing with exporting objects, but forgot to fix it for the scenario export as well). Will be fixed in the next development release.
 
I have released a new version with the bug fix now.
 
Just found another similar bug while using the batch converter. That tool now exports in dsf format although P3D 4.4 bgl scenery export was selected.
 
Oops, I did not test the batch converter intensively, probably it has a similar offset issue. I'll check.
 
I have not forgotten about this, issue, was just a bit busy the last days. I have started coding a fix last evening, but I decided to do a thorough fix, which means I have to change more code (but it will be more robust for the future). Hope to have it ready somewhere this weekend.
 
Your rant is very valid - working in the MSFS system is slow and quirky at times. But here are two things that might help (don't know if you are aware of these):
1) you do not need to start the sim to build a project - it can be done from the command prompt using the fspackagetool. I have a set of simple batch files to do that for all my projects. The batch file contains only one line:
Code: 
"c:\MSFS SDK\Tools\bin\fspackagetool.exe" F:FS2020_projects\XXXX\XXXX.xml -rebuild -mirroring
where XXXX is the name of my project (my projects are all under F:\FS2020_projects).
2) When you are in the sim and in dev mode and your project is open, then changes to existing 3D models are updated as soon as you manually change and re-save the gltf file! No need to rebuild or restart. I am doing my 3D models in Blender, and re-exporting the model from Blender after a change is not enough - I then have to open the gltf in Notepad++ and make some minor change to it (add a space and remove it is enough) and then save it. The model will then update in MSFS within a few seconds. You need to rebuild only if you are adding a completely new 3D model or if the model recieves some completely new texture files.
 
WildLynxPilot said:
Your rant is very valid - working in the MSFS system is slow and quirky at times. But here are two things that might help (don't know if you are aware of these):
1) you do not need to start the sim to build a project - it can be done from the command prompt using the fspackagetool. I have a set of simple batch files to do that for all my projects. The batch file contains only one line:
Code: 
"c:\MSFS SDK\Tools\bin\fspackagetool.exe" F:FS2020_projects\XXXX\XXXX.xml -rebuild -mirroring
where XXXX is the name of my project (my projects are all under F:\FS2020_projects).
2) When you are in the sim and in dev mode and your project is open, then changes to existing 3D models are updated as soon as you manually change and re-save the gltf file! No need to rebuild or restart. I am doing my 3D models in Blender, and re-exporting the model from Blender after a change is not enough - I then have to open the gltf in Notepad++ and make some minor change to it (add a space and remove it is enough) and then save it. The model will then update in MSFS within a few seconds. You need to rebuild only if you are adding a completely new 3D model or if the model recieves some completely new texture files.
Click to expand...
Presumably that hack requires one to retain the original GUID. I assume that a built (?compiled ) package makes a call to a model GUID and so if a modified model has a new GUID it will not be found.
 
You must log in or register to reply here.
Back
Top