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.htmWhen 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 ?
