FSDreamTeam forum
Products Support => GSX Support MSFS => Topic started by: davidcherrie on July 29, 2024, 01:05:08 pm
-
Seated passengers causes the external model to disappear with the MD80. Running latest GSX and Maddog and have unchecked and rechecked the seated passengers option.
-
Doesn't happen here. If you are noticing this with a particular livery, please provide a link or a reference to which livery is, exactly.
Also, if you just updated the airplane, it might be better if you disabled the Seated passengers on it before performing the update. If you lost the chance of doing it, it's probably best to uninstall and reinstall the airplane and all its liveries.
-
It happened with all liveries including the Leonardo house when I enabled it. Will try reinstalling the plane.
-
Doesn't happen here. If you are noticing this with a particular livery, please provide a link or a reference to which livery is, exactly.
Also, if you just updated the airplane, it might be better if you disabled the Seated passengers on it before performing the update. If you lost the chance of doing it, it's probably best to uninstall and reinstall the airplane and all its liveries.
Have reinstalled the plane with Seated Passengers turned off. Works fine, then when turning seated passengers on, the house livery for all 3 aircraft turn to this:
-
Any updates...?
-
It's happening here too. Someone posted on the Leonardo website of the issue as well. I've attached the CFG files related to one of my add-on skins.
It's worth noting, all my MD-82 skins are the same as I use PowerShell to programmatically modify every skin to get the CFGs the way they need to be to work in the sim. It'll even create the "Model" folder and drop the latest version of the "model.cfg" file in a correct folder if a "Model" folder does not exist for the skin. I did this because the "GSX Pro Config" didn't always create a model folder as needed for each of the 340+ skins I have. Then when enabling GSX Pro for the aircraft, I can literally watch the changes to the model.cfg file take place. All aliases in those files look correct to me. As I said above, I've attached them for your review.
From what I know about file manipulation on 2020 skins, this may be an issue with the Leonardo aircraft itself. All references to the model appear to be correct in the original and modified files as far as I can tell.
-
I have same problem, looking for solution on Leonardo forum also. For this moment I just disabled seated passengers because this conflict with all my liveries. I was hoping last GSX update will resolve this problem...
-
With a fresh install and no add-on liveries, this issue happens. Glad to see I'm not the only one affected.
-
Same problem for me - no exterior with seated pax on. No seated pax and the exterior is back! In this case i use the MD-88 SAS Livery
-
OK - it seems it was a problem with certain liveries. When i checked - that some livery was working and others not - i had a look in the folder and files. GSX is modifying the MaddogX_exterior.xml. I found a wrong path for ModelFile="..\..\MaddogX\Model\MaddogX_exterior.gltf" - which was reading: ModelFile="MaddogX_exterior.gltf" instead. After i changed it - everything was working.
Maybe this can help you - if you have the same problem.
-
That's not going to fix it. Aliasing directly to the model file skips the xml file needed to configure the plane for passengers. This is the correct entry you should have in your "model.cfg" file. Note the alias for the interior model (which still works) is still there after GSX modifies the "model.cfg" file. IF you change the exterior call back to "exterior = ..\..\maddogx\model\maddogx_exterior.xml" the external model works again. This indicates something is wrong in the "MaddogX_exterior.xml" file that GSX created in the skin/livery folder.
[models]
exterior = MaddogX_exterior.xml
interior = ..\..\maddogx\model\maddogx_interior.xml
-
it seems it was a problem with certain liveries.
That's why I asked which ones:
If you are noticing this with a particular livery, please provide a link or a reference to which livery is, exactly.
-
In my case, it's all liveries including the defaults.
-
In my case, it's all liveries including the defaults.
Default liveries works fine here, I suggest uninstalling and reinstalling the MaddogX and be sure it's the latest version.
-
Did that already. Results are the same. I'm well, well versed in files related to getting liveries working in the sim. I have over 4TB of skins all managed with PS scripting. So, there is definitely something wrong when the default install and default skins fail to load the external model with no custom skins installed. Remove GSX and the default skins go back to working. That tells me there is a potential issue in the XML file that GSX writes to the model.cfg file for the aircraft/skin.
-
If there was an issue with that, it would happen to everybody and of course I could replicate it, which I couldn't. You said it happens even with no liveries installed, in this case, the ONLY file modified by GSX is this one:
lsh-maddogx-aircraft\SimObjects\Airplanes\MaddogX\model\MaddogX_exterior.xml
Can you post it before and after enabling passengers in GSX ?
-
Just for giggles. I did a Rip/Replace of the aircraft. On first run, the default MD-82 was fine, the default MD-83 was missing the external model and then the default MD-88 was fine. Without restarting the sim, I loaded the MD-83 again after having just loaded the MD-88 and this time it was fine. So, even though I'd done this before and it didn't work then, it did this time.
Here are the steps for livery additions if you are using add-on linker like I am:
1. Enable the skins in Add-on Linker
2. Open the Fly the MaddogX Load Manager.
3. Within the load manager, select the aircraft you have added skins you enabled in Add-on Linker and then click the Liver Manager Button. You should see all your liveries in the Added column.
4. Click the Apply button in the liveries manager.
5. Open GSX and enable the MaddogX
That should work. It's working on my end, although I think I'm running into a skin number limitation for the MD-82 in the load manager. It appears it doesn't like more that 332 skins for some reason. Still trying to figure that one out, but for this model issue, the recommended rip/replace has worked and the steps above allow for the seated passengers.
Sorry I didn't get a chance to post this earlier.
-
it seems it was a problem with certain liveries.
That's why I asked which ones:
If you are noticing this with a particular livery, please provide a link or a reference to which livery is, exactly.
here are some screenshots - when activating the seated pax - a new folder model is made - not in all liveries but in many - and the model.cfg - which is made in this folder, has the wrong path - so the exterior model gets destroyed!
-
to my post before - this are the affected liveries in my case:
lsh-maddogx-aircraft\SimObjects\Airplanes\MaddogX83\model.AAL
lsh-maddogx-aircraft\SimObjects\Airplanes\MaddogX88\model.DAL
lsh-maddogx-livery-AAL_METAL\SimObjects\Airplanes\MaddogX-livery-AAL_METAL\model.AAL
lsh-maddogx-livery-AeroMexico\SimObjects\Airplanes\MaddogX-Livery-AeroMexico\model.AMX
lsh-maddogx-livery-ALITALIA\SimObjects\Airplanes\MaddogX-Livery-ALITALIA\model.AZA
lsh-maddogx-livery-AMERICAN AIRLINES N501AA\SimObjects\Airplanes\MaddogX-Livery-AMERICAN AIRLINES N501AA\model.AAL
lsh-maddogx-livery-AMX\SimObjects\Airplanes\MaddogX-Livery-AMX\model.AMX
lsh-maddogx-livery-ARG90\SimObjects\Airplanes\MaddogX-Livery-ARG90\model.ARG
lsh-maddogx-livery-CSN\SimObjects\Airplanes\MaddogX-Livery-CSN\model.CSN
lsh-maddogx-livery-DL7\SimObjects\Airplanes\MaddogX-Livery-DL7\model.DAL
lsh-maddogx-livery-GWI\SimObjects\Airplanes\MaddogX-Livery-GWI\model.GWI
lsh-maddogx-livery-HAWAIIAN\SimObjects\Airplanes\MaddogX-Livery-HAWAIIAN\model.HAL
lsh-maddogx-livery-HBIND\SimObjects\Airplanes\MaddogX-Livery-HBIND\model.SWR
lsh-maddogx-livery-laser-silver-bullet-new\SimObjects\Airplanes\MaddogX-Livery-laser-silver-bullet-new\model.SIL
lsh-maddogx-livery-LNRMN\SimObjects\Airplanes\MaddogX-Livery-LNRMN\model.SAS
lsh-maddogx-livery-N1003X\SimObjects\Airplanes\MaddogX-Livery-N1003X\model.AMX
lsh-maddogx-livery-OE-LDP\SimObjects\Airplanes\MaddogX-Livery-OE-LDP\model.AUA
lsh-maddogx-livery-OE-LDV\SimObjects\Airplanes\MaddogX-Livery-OE-LDV\model.AUA
lsh-maddogx-livery-OE-LDX\SimObjects\Airplanes\MaddogX-Livery-OE-LDX\model.AUA
lsh-maddogx-livery-OE-LMBM\SimObjects\Airplanes\MaddogX-Livery-OE-LMBM\model.AUA
lsh-maddogx-livery-OE-LMC\SimObjects\Airplanes\MaddogX-Livery-OE-LMC\model.AUA
lsh-maddogx-livery-Olympic\SimObjects\Airplanes\MaddogX-Livery-Olympic\model.OAL
lsh-maddogx-livery-Real_Madrid\SimObjects\Airplanes\MaddogX-Livery-RealMadrid\model.DLH
lsh-maddogx-livery-SAS\SimObjects\Airplanes\MaddogX-Livery-SAS\model.SAS
lsh-maddogx-livery-SaudiArabianHZAPM\SimObjects\Airplanes\MaddogX-Livery-SaudiArabianHZAPM\model.SVA
lsh-maddogx-livery-SEDMX\SimObjects\Airplanes\MaddogX-Livery-SEDMX\model.SAS
lsh-maddogx-livery-SWR\SimObjects\Airplanes\MaddogX-Livery-SWR\model.SWR
lsh-maddogx-livery-United-Airlines-Battleship\SimObjects\Airplanes\MaddogX-Livery-United-Airlines\model.UAL
lsh-maddogx-livery-XA-AMP\SimObjects\Airplanes\MaddogX-Livery-XA-AMP\model.AMX
the content which is new in the model folder (MaddogX-Livery-OE-LDP) can be found in the attachment.
-
Did that already. Results are the same. I'm well, well versed in files related to getting liveries working in the sim. I have over 4TB of skins all managed with PS scripting. So, there is definitely something wrong when the default install and default skins fail to load the external model with no custom skins installed. Remove GSX and the default skins go back to working. That tells me there is a potential issue in the XML file that GSX writes to the model.cfg file for the aircraft/skin.
Exactly the same with me. GSX causes the default aircraft with no liveries to disappear.
-
Please provide the precise, exact link to a livery that has this problem, so I can check that.
-
Did that already. Results are the same. I'm well, well versed in files related to getting liveries working in the sim. I have over 4TB of skins all managed with PS scripting. So, there is definitely something wrong when the default install and default skins fail to load the external model with no custom skins installed. Remove GSX and the default skins go back to working. That tells me there is a potential issue in the XML file that GSX writes to the model.cfg file for the aircraft/skin.
Am exactly the same. Reinstalled multiple times with no other liveries installed and the default aircraft disappears and just shows the cabin when I turn on Seated Passengers.
-
For me, it happen in livery which install in md88, if I install the livery in md82, exterior works normal.
The livery I use come from Maddog https://www.flythemaddog.com/forum/index.php?/topic/13445-delta-airlines-oc-n995dl-md-88/
-
Still an issue. Tried to fly the MD88 in 2024 and still getting the same issue 10 months ago.
-
Ooooooh !
I just discovered the model issue in FS24 comes from GSX ?
I was so annoyed at leonardo’s for having a bugged md80 with wheels disappearing after a while..
GSX with all it’s bugs is starting to annoy me, inbetween the fact that it’s disabled in cruise, even if the option is not checked, since last update couatl doesn’t even start, the boarding sequence is bugged, the gates stops are a mess.
Sigh
-
Ooooooh ! I just discovered the model issue in FS24 comes from GSX ?
Not exactly, it's a side effect of having enabled seated passengers in GSX, yes, but the REAL reason seems to be caused by an inconsistent (or not very logical) handling by the sim of upper/lower case in the various paths used in the config files, as I posted here after further testing:
https://www.fsdreamteam.com/forum/index.php/topic,33007.msg209001.html#msg209001
As I've said in the other thread, The problem begins with how the original model.cfg (before GSX modifications) is made:
[models]
exterior=..\..\MaddogX\Model\MaddogX_exterior.xml
interior=..\..\MaddogX\Model\MaddogX_interior.xml
But the model is installed into a folder called "model" in lower case. This shouldn't be a problem, because Windows is a case-insensitive filesystem, so a file located in a "model" or "Model" folder should always be found and, in fact, it works normally.
However, there must be *something* in the way MSFS 2020 loads the model (maybe while parsing the model.xml instead), where the case MATTERS and this causes a strange effect, at least this is what happened when I tested it just yesterday:
On MSFS 2020
On the initial loading, the cabin is missing. However, if you enter the HANGAR and select the Livery from the bottom scrollable list, the cabin loads normally and, if you enter a flight after doing this, it works and stay loaded for the rest of the session.
This seems to indicate, the Hangar has a different method of loading liveries than the normal loading, a method which makes more sense for Windows, being a case-insensitive filesystem.
On MSFS 2024
I tested with the SU3 Beta, and the livery that didn't work in MSFS 2020 unless you went to the Hangar first, worked at a first try. The other poster, who is the livery author, said it doesn't work with the regular SU2.
So, it's possible that, since it's very likely that using case-sensitive comparison on a case-insensitive filesystem like Windows would like have caused several other issues to all kind of airplanes (it's very easy to not notice a difference of case in path), it might have been reported to MS/Asobo and it was fixed in SU3, by making any file-loading check case-insensitive, which is the more logical choice in Windows.
That would be the only explanation I have why the livery that was reported as not working, worked for me at the first try.
GSX with all it’s bugs is starting to annoy me, inbetween the fact that it’s disabled in cruise, even if the option is not checked, since last update couatl doesn’t even start, the boarding sequence is bugged, the gates stops are a mess.Sigh
I don't know what this has to do with this thread.
Make a proper report of ALL these issues in their appropriate thread, with reproduction steps and description. That's the only way to have bug fixed: how can we fix bugs if we don't even know they exists ?
-
Ooooooh !
I just discovered the model issue in FS24 comes from GSX ?
Yep, but although it is caused entirely by GSX, Umberto as shown will blame Asobo in a massive post rather than fixing the issue with an if statement.
-
Yep, but although it is caused entirely by GSX, Umberto as shown will blame Asobo in a massive post rather than fixing the issue with an if statement.
And somehow, you managed to be wrong, again:
We are talking about a failure to LOAD A FILE. And why is failing to load ? Because somewhere in the MSFS code, there must be a comparison on that file name/path using case-sensitivity. Read this again a case-sensitive comparison to decide to LOAD a file, on a CASE-INSENSITIVE filesystem!.
Considering how easy for anyone, like a repainter/modder, not not notice a single upper/lower case change when changing a file, I'm sure this must have happened to others, without using GSX so no, it's NOT caused "entirely by GSX", you might say it's a side effect of the way GSX patches the model PATHS in the exterior.xml, which requires taking the relative path from the model.cfg, the original one made by Leonardo BEFORE any changes, I'll post it again so, maybe, you'll understand this time:
[models]
exterior=..\..\MaddogX\Model\MaddogX_exterior.xml
interior=..\..\MaddogX\Model\MaddogX_interior.xml
However, the actual name of the model folder is model, all lower case. This WORKS, and of course anybody would expect to, Windows filesystem is a case-insensitive, so any standard file opening routine will surely found the file, even if the name is not *exactly* the same so no, I'm not "blaming" Leonardo for this, it's entirely understandable that anybody wouldn't pay attention to this.
However, when it must patch a livery, GSX must copy the original exterior XML, which points to the .gltf model, and change the name without any path (because the xml is copied from the base model) and add a relative path. So where the relative path is coming from ? From that model.cfg ABOVE, the one before any modifications!
So this line in the exterior .xml
<LOD minSize="0" ModelFile="MaddogX_exterior.gltf" />
Had to be changed to this:
<LOD minSize="0" ModelFile="..\..\MaddogX\Model\MaddogX_exterior.gltf" />
With the new relative path obviously taken from the above MODEL.CFG, as it supplied with the airplane. This line LOADS the .gltf model, which is a file, so you would think it ..\..\MaddogX\Model\MaddogX_exterior.gltf on Windows is the same as ..\..\MaddogX\model\MaddogX_exterior.gltf as loading files are concerned.
In fact, considering the model.cfg with the "wrong" path WORKS, why one could possibly guess the same "wrong" path wouldn't work anymore, when is used in the exterior model ?
But apparently this is what is happening. Either somewhere in the MSFS code a string comparison is made using case-sensitivity, or it's related to the fact MSFS uses a Virtual Filesystem so they use custom loading routine that don't work like the normal Windows filesystem, those are the most likely causes, we just happened to have discovered this due to the way GSX works, but it should be clear to anybody that using case-sensitivity when handling file loading on a case-insensitive OS, would surely soon or later cause problems.
And, it seems the Hangar view in some way "fixes" this, perhaps the code the loads the exterior model in the Hanger is DIFFERENT than the one the does the normal loading, so it explains why entering the hangar to select the Livery would fix the problem and the livery worked for the rest of the session.
And with MSFS 2024 SU3 Beta it loads right away, so maybe somebody else must have reported this, or it's just Asobo themselves who have thought that yes, maybe it's not the best idea loading stuff using case-sensitivity on Windows.
But that's besides the point. The point is that now the real issue is finally clear, I was able to modify the installer to CHECK these cases where there's an incoherency in casing in the model.cfg compared to the real name of the folder. You think that was easy ? It took a lot of effort because, almost every standard Windows path handling routine IGNORE the case, as it should be! But in the end it worked so now, the current version of the installer, explicitly checks for this case.
And while doing the fix, I could check all the airplanes supported by the Seated Passengers and, of all of them, only TWO had a case of incoherent case in the path names:
- The Leonardo Maddog, with the relative path in the model.cfg not matching the case of the path the airplane is installed into ( "Model" instead of "model" )
- The FBW A380, which comes in a folder named "Simobjects\AirPlanes" instead of "Simobjects\Airplanes" which is the actual name in the sim. However, due to the different way the airplane files are structured, this wasn't a problem for GSX, since we didn't need to look at that path when patching the copied exterior xml.
And again no, I'm not "blaming" Leonardo for this! We just happened to find an unknown quirk of MSFS that surfaced because the way GSX needs to create a new path by taking the one from the model.cfg.
About your "a massive post rather than fixing", the updated installer is already online since yesterday (before you wrote this) because, as always, when issues are found, they are ALWAYS fixed.
-
It's only taken 10 months to fix... and I bet it took less time to fix than for you to write that entire post.
-
and I bet it took less time to fix than for you to write that entire post.
How you manage to be always wrong, no matter what ?
It took considerable effort to "fix" something I shouldn't even had to fix on Windows, because almost every Windows standard file-opening, path handling and file comparison routing that is normally used, REFUSE to consider folders like "Model" and "model" to be different because, of course, on Windows, they ARE for all kind and purposes, equivalent.
And this is even complicated more by the fact, since the installer *must* use UNC pathnames (to support extra-long filenames), there are even less ways to recognize the "real" case of a folder, so you need to find some specific API calls (outside of .NET) which can give you the real pathname, including casing.
Not to mention this "fix" has obviously made scanning for airplanes slower, since all these tests and extra API calls over each file involved are not free: the require extra processing, extra care. All of this would have been totally unnecessary, if MSFS applied the standard Windows filesystem rules when dealing with pathnames in all situations, not just the hangar view.
And guess what, in MSFS 2024 the problem seems to have been fixed.
-
How you manage to make something simple sound like rocket science is a real skill.
Yes, Windows is case-insensitive. No, MSFS isn’t Windows. That’s the problem. The sim’s own loading quirks break what should be basic file handling. You had to write extra code, dig into obscure APIs, and slow down the installer just to paper over that mess.
Meanwhile, the rest of us don’t care why it’s broken. We want it fixed. And it’s been broken for how long? Months? Nearly a year? Meanwhile, you’re busy defending your code like it’s flawless.
Your workaround is still the only reason it works right now. So spare me the “this shouldn’t be necessary” lecture and just own the fix you had to push.
-
Yes, Windows is case-insensitive. No, MSFS isn’t Windows. That’s the problem.
You just made my point. Since MSFS RUNS on Windows, it's not a very good idea to have an internal loading system that doesn't work with the same rules as Windows, when dealing with loading fileswhich ARE on the Windows filesystem.
The sim’s own loading quirks break what should be basic file handling. You had to write extra code, dig into obscure APIs, and slow down the installer just to paper over that mess.
Thank you for making my point even clearer now. This shouldn't even been required. It causes unnecessary complications in any app that would need to deal with such files. Let's say in a different way:
Suppose another app like some livery manager, or some add-on which places extra stuff in the exterior or interior model, like 3rd party instruments, EFBs, tools in the cockpit, anything that require modifying the exterior model in a similar way to the FSDT Installer. EACH and EVERY of those app should be coded around this, not even mentioning the SDK doesn't say ANYTHING about it, so how any developer can possibly know that ?
In fact, the SDK most of the time says that basically everything in the sim (SimVar Names, Animation names, etc.) is case-insensitive and while for aircraft they don't specifically say anything about case, the closest thing you can find is when they describe generic SimObjects:
https://docs.flightsimulator.com/msfs2024/html/5_Content_Configuration/Modular_SimObjects/SimObjects/SimObjects.htm
When creating any type of SimObject, except aircraft, the folders and files must all be formatted following the rules given below (note that filenames are case in-sensitive).
Of course one might point out they talk about non-aircraft here but, it's not as if they say in aircraft SimObjects filenames become case-sensitive instead and in the only one place when case MATTERS (the object GUID) they clearly say it must be all lower-case, so how one can possibly guess that a filename, on Windows, switched from being case sensitive or not, depending on the context?
Meanwhile, you’re busy defending your code like it’s flawless.
Of course! The code WAS flawless, the paths modified by the GSX installer looked perfectly fine to me, they were EXACTLY like the original one from Leonardo!
[models]
exterior=..\..\MaddogX\Model\MaddogX_exterior.xml
interior=..\..\MaddogX\Model\MaddogX_interior.xml
Is this looking like a WRONG path to you ? This is the original, unmodified file supplied with the airplane, and it WORKS, so you wouldn't say it's "wrong". It becomes "wrong" only when it's used from an .XML, as we just discovered so, when I looked at the files and how their were modified by the GSX installer, they look 100% correct to me:
<LOD minSize="0" ModelFile="..\..\MaddogX\Model\MaddogX_exterior.gltf" />
What you would say, if YOU wrote the code which created this ? You would say "I copied the path from the model.cfg EXACTLY!". Unfortunately, this didn't work, I shouldn't have copied the path exactly, that's the issue.
It took a long time to realize this because:
It doesn't happen with all liveries. It happens only with an external livery for which GSX must create a COPY of the exterior .xml, which happens only if GSX has a crew with a uniform matching that airline. If I tried some of them, if it didn't load, I went back to the menu, enter the Hangar to look at the livery, it then worked, I just dismissed as another MSFS quirk, because that's what it was in the end. I double checked the path in the XML, and it looked correct, because it WAS identical to the one taken from the original unmodified model.cfg, how you'd expect you had to CHANGE the path found in the model.cfg, because it was "wrong" even if it shouldn't ?
-
And since the problem is now FIXED, thanks to a workaround in the GSX Installer that now explicitly checks for case-sensitivity in case the model.cfg doesn't match the "real folder" name, there's no need to continue it, so it can be marked as solved and closed.