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

Modifying model.xml Causing LOD Issues (2024)

Messages
5
Country
unitedstates
So I have an addon that modifies some of the lights in the iFly 737 Max8. I need to add a small little something into the iFly737Max8_INTERIOR_178.xml file. What I'm adding is kind of irrelevant right now and I'll explain. Here is my main issue: when my package overwrites the iFly737Max8_INTERIOR_178.xml, the LODs get all messed up. In the exterior view, the cabin becomes invisible unless the camera is pretty close to the airplane. To be more accurate, the interior isn't being rendered at all. It is not an issue with LOD2 not being loaded correctly or something. All LOD models are being loaded. When the camera is far enough (which isn't that far) the interior gets culled completely and isn't rendered whatsoever, there is no LOD at all. Here is why what I'm adding to the xml file is irrelevant. This behavior occurs even if I do not change the xml file at all. It occurs just because it is being loaded from my package.

Here is the folder structure of some of the iFly 737 Max8 and some of the files I mention. Keep in mind this is not everything, just what I talk about. The only file listed here that I overwrite in my package is the iFly737Max8_INTERIOR_178.xml file.
Code:
SimObjects/Airplanes/iFly 737-MAX8/
├─ model/
│  ├─ iFly737Max.bin
│  ├─ iFly737Max.gltf
│  ├─ iFly737Max.xml
│  ├─ iFly737Max_INTERIOR_178.bin
│  ├─ iFly737Max_INTERIOR_178.gltf
│  ├─ iFly737Max_INTERIOR_178_LOD1.bin
│  ├─ iFly737Max_INTERIOR_178_LOD1.gltf
│  ├─ iFly737Max_INTERIOR_LOD2.bin
│  ├─ iFly737Max_INTERIOR_LOD2.gltf
├─ model.178Seat/
│  ├─ iFly737Max_INTERIOR_178.xml
│  ├─ model.CFG
├─ aircraft.cfg

At first, I assumed it had to do with the relative file paths in the iFly737Max8_INTERIOR_178.xml file here:
XML:
<LODS>
    <!-- Highest LOD -->
    <!-- minimum display size in % (should be bounding sphere vertical screen size, sphere will often be slightly larger than you expect) -->
    <!-- default minSize is 0 -->
    <LOD minSize="200" ModelFile="..\model\iFly737Max_INTERIOR_178.gltf"></LOD>
    <LOD minSize="170" ModelFile="..\model\iFly737Max_INTERIOR_178_LOD1.gltf"/>
    <LOD minSize="10" ModelFile="..\model\iFly737Max_INTERIOR_LOD2.gltf"/>
</LODS>
But that is not the case. Every LOD model is being loaded just fine and each one is actually being used. But the minSize when the LOD changes is completely different than what is in the xml file.

To give some more context, the aircraft.cfg has this line: model="178Seat" hence why the model.CFG is in the model.178Seat folder. In the model.CFG we have this:
Code:
; Reference LOD implementation, please keep these comments (for now).

[model.options]
; if true, when showing the exterior, also show the interior model (default false)
withExterior_showInterior=true
; if true, when showing the interior with the exterior, exclude interior.lod.0 (default false); only has an effect when withExterior_showInterior is true
withExterior_showInterior_hideFirstLod=true
; when showing the interior, force showing lod0 (default true)
withInterior_forceFirstLod=true
; when showing the interior, also show the exterior model (default false)
withInterior_showExterior=false


; animation definitions are shared by all LODs
; duplicate animations will use the animation definition from the first file it was encountered in (starting at 0)
; MULTIPLE BEHAVIOR FILES NOT YET SUPPORTED
[models]
normal=..\model\iFly737Max.xml
interior=iFly737Max_INTERIOR_178.xml
So given this model.CFG, while in exterior view the interior LODs that should be visible correspond to LOD1 (iFly737Max8_INTERIOR_178_LOD1.gltf) and LOD2 (iFly737Max8_INTERIOR_LOD2.gltf)

Anyways, to get to the root of the problem... For whatever reason, when the iFly737Max8_INTERIOR_178.xml is loaded from my package, the Min Size for each LOD completely changes. As you can see in the code above, LOD0 should have a Min Size of 200%, LOD1 should have a Min Size of 170%, and LOD2 should have a Min Size of 10%. Without my addon/when it is working as it should, those values are correct and I'll attach some images of some debug info to show it, but the last LOD changes to a Min Size of 0.1% for both the exterior and interior. I assume this is something that MSFS does on its own to make sure the last LOD is always shown but I'm not 100% sure. With my addon/when it is broken, the interior LODs Min Sizes change to this: LOD0 has a Min Size of 425.1%, LOD1 has a Min Size of 395.7%, and LOD2 has a Min Size of 180.8%. And indeed, when the size of the LOD drops below 180.8, the interior disappears completely.

Again, the iFly737Max8_INTERIOR_178.xml file in my package is completely untouched. It is an exact copy of the original. And I know it has something to do with this file because when I add it to my package I get this broken behavior, and when it isn't in my package, it works just as it should.

If anyone has some insight or could help me with this, I would greatly appreciate it!

Thank you,
xhvxuvx

In the last picture, I moved the camera back just a slight amount so the size would drop below 180 so you could see the interior model disappears completely.
 

Attachments

  • Screenshot 2025-12-02 010502.png
    Screenshot 2025-12-02 010502.png
    1.6 MB · Views: 117
  • Screenshot 2025-12-02 020034.png
    Screenshot 2025-12-02 020034.png
    128.1 KB · Views: 100
  • Screenshot 2025-12-02 020056.png
    Screenshot 2025-12-02 020056.png
    2 MB · Views: 112
  • Screenshot 2025-12-02 020116.png
    Screenshot 2025-12-02 020116.png
    1.9 MB · Views: 101
some things to consider
2024 is hard on lod's, it culls by size (per attachment or part) as well as the xml number there
so no matter what you write in that xml it wont get there if its too complex

is the third lod named coeectly? it appears to be missing the "_178" the other 2 have

im curious about this comment also
; if true, when showing the interior with the exterior, exclude interior.lod.0 (default false); only has an effect when withExterior_showInterior is true
withExterior_showInterior_hideFirstLod=true

wouldnt that just cull the first interior lod from ext view no matter the lod limits ?
doubt thats the issue your seeing though

here is what some defaults have and what i use
[model.options]
withExterior_showInterior=true
withExterior_showInterior_hideFirstLod=false (if this is true only interior LOD1+ will be used when in exterior view)
withInterior_forceFirstLod=false (this one is just for performance, it could be true if you dont want them seeing lod1 from interior- forces only lod0 in int)
withInterior_showExterior=true
 
Last edited:
some things to consider
2024 is hard on lod's, it culls by size (per attachment or part) as well as the xml number there
so no matter what you write in that xml it wont get there if its too complex

is the third lod named coeectly? it appears to be missing the "_178" the other 2 have

im curious about this comment also
; if true, when showing the interior with the exterior, exclude interior.lod.0 (default false); only has an effect when withExterior_showInterior is true
withExterior_showInterior_hideFirstLod=true

wouldnt that just cull the first interior lod from ext view no matter the lod limits ?
doubt thats the issue your seeing though

here is what some defaults have and what i use
[model.options]
withExterior_showInterior=true
withExterior_showInterior_hideFirstLod=false (if this is true only interior LOD1+ will be used when in exterior view)
withInterior_forceFirstLod=false (this one is just for performance, it could be true if you dont want them seeing lod1 from interior- forces only lod0 in int)
withInterior_showExterior=true
Yes 2024 may be hard on the LODs, but as you can see from my photos, when the xml file is loaded from the original package, the sim respects the minSize values in it. And I’m not editing the mesh at all. Out of all the files I listed, the only one I add to my package is the iFly737Max_INTERIOR_178.xml, and I get this broken LODs without even making any changes to the xml file. It breaks purely bc it’s loaded from my package.

withExterior_showInterior_hideFirstLod=true
Yes this “culls” LOD0 from the exterior view. Or more accurately, the first LOD in the exterior view is LOD1 not LOD0. LOD0 is only used from the VC view/inside the airplane. This is the default behavior that the iFly package uses. Like I said, out of those files, the only one in my package is the interior xml.

And yes LOD2 is named correctly. That is the name iFly used for whatever reason. Regardless of its name, it works while the interior xml is loaded from the original package.

As you said, if I change “withExterior_showInterior_hideFirstLod=true” to false. Then the first interior LOD used in the exterior view will be LOD0. But the way iFly designed their plane/package, LOD0 is truly only to be used in the interior view. When this value is set to false and the LOD0 loads in exterior view, some of the interior model clips through the exterior skin. ifly modeled it with the intention that it only be viewed from the inside, not the outside.
 
Yes 2024 may be hard on the LODs, but as you can see from my photos, when the xml file is loaded from the original package, the sim respects the minSize values in it. And I’m not editing the mesh at all. Out of all the files I listed, the only one I add to my package is the iFly737Max_INTERIOR_178.xml, and I get this broken LODs without even making any changes to the xml file. It breaks purely bc it’s loaded from my package.

withExterior_showInterior_hideFirstLod=true
Yes this “culls” LOD0 from the exterior view. Or more accurately, the first LOD in the exterior view is LOD1 not LOD0. LOD0 is only used from the VC view/inside the airplane. This is the default behavior that the iFly package uses. Like I said, out of those files, the only one in my package is the interior xml.

And yes LOD2 is named correctly. That is the name iFly used for whatever reason. Regardless of its name, it works while the interior xml is loaded from the original package.

As you said, if I change “withExterior_showInterior_hideFirstLod=true” to false. Then the first interior LOD used in the exterior view will be LOD0. But the way iFly designed their plane/package, LOD0 is truly only to be used in the interior view. When this value is set to false and the LOD0 loads in exterior view, some of the interior model clips through the exterior skin. ifly modeled it with the intention that it only be viewed from the inside, not the outside.
ok one other thing i noticed, is you show your model loader xml, but without the required <ModelInfo> container ?
<ModelInfo>
<LODS>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD00.gltf"/>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD01.gltf"/>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD02.gltf"/>
</LODS>
</ModelInfo>

that would be an example of a minimal <model>.xml
optionally you would have a Behavious container as well
<ModelInfo>
<LODS>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD00.gltf"/>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD01.gltf"/>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD02.gltf"/>
</LODS>
<Behaviors Compiled="False" Version="2" Revision="0">
<!-- code goes here -->
</Behaviors>
</ModelInfo>
 
ok one other thing i noticed, is you show your model loader xml, but without the required <ModelInfo> container ?
<ModelInfo>
<LODS>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD00.gltf"/>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD01.gltf"/>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD02.gltf"/>
</LODS>
</ModelInfo>

that would be an example of a minimal <model>.xml
optionally you would have a Behavious container as well
<ModelInfo>
<LODS>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD00.gltf"/>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD01.gltf"/>
<LOD minSize="0" ModelFile="..\..\Part_Exterior\model\xxx_Ext_LOD02.gltf"/>
</LODS>
<Behaviors Compiled="False" Version="2" Revision="0">
<!-- code goes here -->
</Behaviors>
</ModelInfo>
Yeah, I left that out because it’s a lot and most if not all is irrelevant.

Even in the 2024 version, the iFly 737 doesn’t use the <CompileBehaviors>, but just the regular <Behaviors> tag. Honestly the 2024 version is pretty much the 2020 version with a few fixes here and there in some of the cfg’s, and I’m sure elsewhere too. But it doesn’t use the 2024 folder structure.at all.
 
Yeah, I left that out because it’s a lot and most if not all is irrelevant.

Even in the 2024 version, the iFly 737 doesn’t use the <CompileBehaviors>, but just the regular <Behaviors> tag. Honestly the 2024 version is pretty much the 2020 version with a few fixes here and there in some of the cfg’s, and I’m sure elsewhere too. But it doesn’t use the 2024 folder structure.at all.
gotcha
so .. its a legacy aircraft then, even the 'Simple_Aircraft' sample in the 2024 docs use the new folder structure with common, presets and liveries folders (minimal) inside the base aircraft folder (i missed that from your diagram)
pretty sure that wont change anything for what your doing

but it does eliminates the LOD concern, 2020 aircraft in 2024 use legacy lod rules as well

something i dont see .... (probably nothing)
for 2020 you may need to specify that custom model folder in the aircraft.cfg (kinda like the old style liveries, only the suffix part after the decimal)
[FLTSIM.x]
title = "some unique name" ; Variation name
model = "178Seat" ; model folder
panel = "" ; panel folder
 
Last edited:
gotcha
so .. its a legacy aircraft then, even the 'Simple_Aircraft' sample in the 2024 docs use the new folder structure with common, presets and liveries folders (minimal) inside the base aircraft folder (i missed that from your diagram)
pretty sure that wont change anything for what your doing

but it does eliminates the LOD concern, 2020 aircraft in 2024 use legacy lod rules as well

something i dont see .... (probably nothing)
for 2020 you may need to specify that custom model folder in the aircraft.cfg (kinda like the old style liveries, only the suffix part after the decimal)
[FLTSIM.x]
title = "some unique name" ; Variation name
model = "178Seat" ; model folder
panel = "" ; panel folder
Like my original post says:
To give some more context, the aircraft.cfg has this line: model="178Seat" hence why the model.CFG is in the model.178Seat folder.
Also this isn't a custom model folder. The folder structure I listed is how the iFly 737 comes out the box. I'm not adding a iFly737Max8_INTERIOR_178.xml file, I'm merely overwriting it (through the VFS of course).
 
then im at a loss
[sorry i guess i should have reread the OP, ive slept since my first reading :)]

what your telling me is, this is a default file that works outside your package, so ...
if your not editing this file and it doesnt work in your package .... then it must be something in the package (loading order, folder structure, layout not updated or something, maybe you need a Dependency in the manifest ?)
if you are editing this file it could be those edits Or the package (maybe try with no edits?), there really isnt any other possibilities i can see from here

as i said you can eliminate any lod or 2024 specific 'problems' since its a Legacy aircraft
in fact you could probably test in 2020, but i wouldnt
many devs make specific edits so the product works better in 2024 that may break stuff in 2020
iFly has 2 separate products so im guessing thats what they did or your just using the 2020 product in 2024

i can say the Legacy support isnt all they advertised originally
its getting better but there are issues with using some 2020 code that ive run into
thats with native 2024 aircraft though, ive not really worked much with legacy stuff
 
Last edited:
then im at a loss
[sorry i guess i should have reread the OP, ive slept since my first reading :)]

what your telling me is, this is a default file that works outside your package, so ...
if your not editing this file and it doesnt work in your package .... then it must be something in the package (loading order, folder structure, layout not updated or something, maybe you need a Dependency in the manifest ?)
if you are editing this file it could be those edits Or the package (maybe try with no edits?), there really isnt any other possibilities i can see from here

as i said you can eliminate any lod or 2024 specific 'problems' since its a Legacy aircraft
in fact you could probably test in 2020, but i wouldnt
many devs make specific edits so the product works better in 2024 that may break stuff in 2020
iFly has 2 separate products so im guessing thats what they did or your just using the 2020 product in 2024

i can say the Legacy support isnt all they advertised originally
its getting better but there are issues with using some 2020 code that ive run into
thats with native 2024 aircraft though, ive not really worked much with legacy stuff
I wouldn’t say it works outside my package but rather it works in the original (iFly 737) package. It doesn’t matter if I modify it or if it’s an exact copy of the original, placing it in my package breaks the LODs. I know the layout and the folder structure are just fine because I checked the VFS browser for the interior xml file, it showed that both my package and the original iFly package had this file and that mine had priority.

One thing that just came to mind, although I’m not exactly confident this could be the issue. But as we have discussed, the original iFly package is a 2020 style package, from the manifest to the folder structure. Although my package has the same 2020 folder structure, it is using a 2024 manifest, using the CUSTOM_SIMOBJECT_PATCH load order hint. I don’t know, maybe it being a 2024 package, patching a 2020 package is confusing the engine? I’m really just grasping at straws.

Thankfully I did think of a solution where I just don’t use this interior xml file in my package so I’m not needing a solution, but I would love to know why it’s doing what it’s doing.
 
I wouldn’t say it works outside my package but rather it works in the original (iFly 737) package. It doesn’t matter if I modify it or if it’s an exact copy of the original, placing it in my package breaks the LODs. I know the layout and the folder structure are just fine because I checked the VFS browser for the interior xml file, it showed that both my package and the original iFly package had this file and that mine had priority.

One thing that just came to mind, although I’m not exactly confident this could be the issue. But as we have discussed, the original iFly package is a 2020 style package, from the manifest to the folder structure. Although my package has the same 2020 folder structure, it is using a 2024 manifest, using the CUSTOM_SIMOBJECT_PATCH load order hint. I don’t know, maybe it being a 2024 package, patching a 2020 package is confusing the engine? I’m really just grasping at straws.

Thankfully I did think of a solution where I just don’t use this interior xml file in my package so I’m not needing a solution, but I would love to know why it’s doing what it’s doing.
glad you got it sorted, but yea it wont merge files if its legacy and any mods for it would also need be legacy (2020) im pretty sure

anyway, good luck :)
 
Back
Top